标签：#mit

Kennedy Torkura discusses practical GenAI red teaming techniques to safeguard LLMs and knowledge bases against security threats like data poisoning and LLMjacking on AWS. He explains how engineering leaders and architects can bridge traditional cloud security with MITRE ATLAS frameworks to proactively identify vulnerabilities, implement guardrails, and secure production AI applications. By Kennedy Torkura

Ready for a fresh set of puzzles? Click here for the September/October 2026 Puzzle Corner, brought to you by Michael S. Branicky, ScD ’95, of the Puzzle Corner Puzzle Crew (aka PC2), which also includes Edward Faulkner ’03, MEng ’04, and Abe Kunin ’03. This column includes solutions to the May/June issue. Send problems, solutions (by October…

Want to tap into the energy of 1,100+ startup founders, investors, and tech leaders descending on Boston for the Founder Summit 2026 on June 9? Host your own Side Event during “Founder Summit Week,” happening June 4-10!

MIT Technology Review Explains: Let our writers untangle the complex, messy world of technology to help you understand what’s coming next. You can read more from the series here. When two OpenAI models hacked into the website Hugging Face in July, they weren’t trying to make money or commit sabotage—they were just looking for answers…

Arun Joseph shares real-world insights on scaling enterprise agentic platforms like Deutsche Telekom’s LMOS. He discusses bridging organizational fault lines, replacing tool sprawl with core platform abstractions, and moving beyond basic chatbots to operational intelligence systems through ephemeral agents and an Agent Definition Language (ADL). By Arun Joseph

Approval workflows do not fail only at the model layer. In a production agent, the more common failure is losing the exact paused state that a reviewer was supposed to approve. Why can a saver decide LangGraph approvals? A saver can decide LangGraph approvals because approvals depend on persisted graph state, not just a chat transcript. LangGraph interrupts pause execution inside a node, store the current state, wait until a human decision arrives, and resume the intended checkpoint with Command(resume=...) ; without a saver tied to the same thread_id , the reviewer handoff can resume the wrong point or fail to resume at all . Quick Answer: LangGraph approvals work only when the paused run is checkpointed and resumed through the same thread_id . LangSmith adds the audit layer: each trace is capped at 25,000 runs, and SaaS trace retention is documented as 400 days from ingestion . The practical rule is simple: put the checkpoint before the irreversible action. That means email sends, file writes, deploys, database mutations, support-ticket edits, purchases, payments, outbound messages, and code execution should pause before the side effect. LangChain's HumanInTheLoopMiddleware follows the same shape: inspect tool calls after model output but before execution, then allow an approve, edit, or reject decision against a checkpointed run . "Interrupts are designed to pause graph execution and resume from the saved point," according to the official LangGraph interrupts documentation . For developers, the important part is operational: the approval gate is only trustworthy if the persisted checkpoint and reviewer decision refer to the same run. LangSmith then gives the team evidence that the gate is behaving correctly. Its observability model groups execution into projects, traces, runs, and threads, which lets teams audit latency, rejection reasons, retry count, tool failures, and reviewer decisions instead of debugging from logs alone . The seed video is useful background

Three approaches to the issue of quantum results that can't be verified classically.

Handoffs are useful when a specialist agent needs to take over a task. They also make cost easier to hide, because the bill is spread across graph nodes instead of one visible chat turn. Why can LangGraph handoffs multiply tokens? LangGraph handoffs can multiply tokens because each model-calling node may resend instructions, prior messages, retrieved material, tool returns, summaries, and artifacts, then loops or handoffs repeat that payload for the next agent. Token amplification is the total prompt-plus-completion tokens across a trace divided by a simpler baseline for the same task; Anthropic reported in June 2025 that multi-agent systems used about 15x more tokens than chats while improving an internal research evaluation by 90.2% . Quick Answer: Handoffs raise the token bill when each agent receives copied context instead of a narrow task packet. Anthropic’s June 2025 research system showed the tradeoff clearly: multi-agent runs used about 15x more tokens than chats while scoring 90.2% higher on its internal research evaluation . In LangGraph, the practical issue is observability and budgeting, not whether graphs are bad. The LangGraph project describes the runtime as a way to build stateful, long-running agents with persistence, human control, memory, and debugging support; those same traits make it possible to measure where context grows instead of guessing. "Multi-agent systems are often highly effective at open-ended research tasks, but token usage can be substantial," — Anthropic engineering team at Anthropic The small verified demo below shows the arithmetic behind a 15x bill: a 100-token task becomes 1,500 billed tokens when 5 agents each receive 3 copies of the relevant context . """ Tiny token-accounting demo: handoffs multiply the same task context. """ task_tokens = 100 agents = 5 context_copies_per_handoff = 3 # instructions + task + summary/history direct_bill = task_tokens handoff_bill = task_tokens * agents * context_copies_per_handoff print ( f

Elena van Engelen discusses how to eliminate serverless vendor lock-in without sacrificing native cloud capabilities. She explains how to structure FaaS applications using Clean Architecture, Spring Cloud Function, and Gradle modules to isolate business logic. Finally, she shares a live demo deploying portable Kotlin services across AWS and Azure using Terraform CDK for multi-cloud IaC. By Elena van Engelen

How a face-customization puzzle at HackMIT went from clicking sliders by hand to reverse-engineering a hidden formula from 10,000 API calls. Face Value looked simple at first glance: ten sliders (Face, Skin, Hair, Brows, Eyes, Nose, Mouth, Glasses, Mole, Accessory), each 0-9, controlling a cartoon avatar. A hidden model scored every configuration, and the goal was to find one it would fully accept : Confidence ≥ 99.9% Edit distance from the starter config ≤ 5 (only half the sliders could move) Charm check: pass Sync check: pass The puzzle's own hint: "Not all features affect the model equally. Some are more sensitive than others, especially together. Single-feature sweeps can be misleading." That warning turned out to be the whole game. Phase 1: Brute Force by Hand The first instinct is the obvious one: click a slider, hit Query, read the result, adjust, repeat. Every query returned four numbers, shown together in a Reviewer panel: Probability, Charm, edit Distance, and Sync. All four had to align at once. This works, sort of. Over the first ~24 manual queries, real patterns emerged: certain Glasses values seemed to matter for Sync, Mole and Accessory nudged confidence up, some sliders had sharp peaks rather than smooth slopes. But progress plateaued hard around 60-77% confidence . Manual testing can only really explore one or two dimensions at a time, and the puzzle explicitly warned that the model cared about combinations ; you can't discover a 3-way interaction by changing one slider and squinting at the result. The first real breakthrough was small but important: after enough fiddling, one query came back with Sync: True for the first time, confidence still low (8.14%), but proof that the four conditions weren't mutually exclusive. Phase 2: Escaping the UI The turning point was popping open Chrome DevTools, clicking Query once, and grabbing the actual network request as a curl command. Underneath the slick UI was a plain JSON API: POST https://facevalue.hackmit.

When a new platform team set out on implementing their roadmap through forced workflows with poor documentation, developer experience declined. Success came from simplifying governance, prioritizing what matters, and rolling out compliance incrementally through prevention, detection, and communication. Empathy, focus, and shared purpose drove successful adoption. By Ben Linders

Max Korbacher explains why successful internal development platforms cannot be built on tech alone. He discusses the pitfalls of infrastructure-first thinking, the importance of a clear product mindset, and how to measure real value using DevEx and SPACE metrics. Learn how to align your team, manage tech debt, and foster a thriving community to ensure lasting platform adoption. By Max Körbächer

The trust proxy setting is an important concept in backend development, especially when implementing rate-limiting in our APIs. But deciding its accurate value depends heavily on our deployment topology. When we deploy our application in production, the client may not talk directly to our backend. There may be 1 or more proxies in between who forward the request to the next proxy or the backend server. Those proxies can be Load balancers, API gateways, reverse proxy like nginx or any custom service. So effectively, our request has to do some 'hops' over these proxies to reach backend. When we implement rate limiting in app to prevent the DOS attack, we generally intend this rate limit on the basis of client IP address. And this works fine when client request reaches our backend directly. But when we have multi-hop architecture, the simple setup won't work as expected. Because the most recent IP will be of the proxy and not the client. So all the traffic coming from different users will be considered from the single client(our own proxy) and thus there will be false positives as the rate limiting will trigger much often. In this scenario, we must tell our backend to ignore these extra hops(i.e. to trust our proxies). This is done by specifying trust proxy. If there is 1 proxy between client-server we set trust proxy to 1; if there are 2, or more, we set it accordingly. This will ensure our express app skips(trusts) these IPs, and accurately figures out actual client IP. The originating IP address of client is identified from 'X-Forwarded-For' header by the express app. But setting trust proxy is not that straightforward. The numerical value for trust proxy will not work in every case. If there are different paths from which our request reaches backend, there is a chance that the number of proxies may be different in each path. For example - internal vs external traffic: External(public) traffic: (Client -> Web Application Firewall -> Load balancer -> Reverse Proxy ->

FCC chairman claims power to repeal TV ownership limit set by Congress.

Davide de Paolis discusses the realities of rolling out cloud infrastructure compliance without fracturing developer relations. Drawing from a real-world platform team reboot at Sevdesk, he explains how to implement "minimum viable governance" on AWS, utilize event-driven Slack alerting to automate policy feedback, and shift from rigid enforcement to high-empathy, data-driven collaboration. By Davide de Paolis

Throttling: vì sao in-memory rate limit "biến mất" sau khi scale ngang, và chọn token bucket hay sliding window Throttling là cơ chế giới hạn số request một client (user, IP, API key, tenant) được xử lý trong một khoảng thời gian, để chống abuse, bảo vệ downstream, và phân bổ công bằng dung lượng service. Định nghĩa nghe đơn giản, nhưng lý do dev gặp nó trong việc thật lại rất cụ thể: sau khi scale service từ 1 pod lên 8 pod, cùng cấu hình "100 req/min mỗi user" đột nhiên trở thành 800 req/min thực tế — vì mỗi pod đếm riêng trong RAM, và load balancer rải request đều tám hướng. Rate limit vẫn "chạy", log không có lỗi, nhưng downstream vẫn bị flood. Đó là failure mode dẫn tới việc phải chuyển counter sang store phân tán, và kèm theo là câu hỏi chọn algorithm nào — token bucket, sliding window, hay leaky bucket — mỗi cái đánh đổi khác nhau. Cơ chế hoạt động Bốn thuật toán phổ biến, khác nhau ở cách đếm và cách xử lý burst. Fixed window counter. Chia thời gian thành khung cố định (mỗi phút bắt đầu tại giây 0). Mỗi request INCR một key rl:{user}:{minute} , nếu counter vượt limit thì reject. Đơn giản nhất, một INCR + EXPIRE trên Redis là xong. Nhược điểm cứng: tại biên khung có thể chịu gấp đôi limit trong một cửa sổ trượt — user gửi 100 req vào giây 59 của phút 12:00, rồi 100 req vào giây 01 của phút 12:01, tức 200 req trong 2 giây thật, trong khi limit là 100/phút. Sliding window log. Lưu timestamp của từng request trong sorted set, mỗi request ZADD + ZREMRANGEBYSCORE xoá các entry cũ hơn now - window , rồi ZCARD để đếm. Chính xác tuyệt đối nhưng tốn bộ nhớ tuyến tính theo số request. Sliding window counter. Cách Cloudflare mô tả trên engineering blog: giữ counter của khung hiện tại và khung trước, ước lượng lượng request trong cửa sổ trượt bằng nội suy có trọng số theo phần trăm khung trước còn nằm trong window. Chỉ tốn hai counter, sai số rất nhỏ so với log thuần, và không có failure mode biên như fixed window. Token bucket. Bucket có capacity B token, refill với tốc

Transaction lifecycle trong Postgres: BEGIN mở state machine, COMMIT đóng — quên đóng là dò mìn Một transaction trong Postgres không phải chỉ là cặp BEGIN ... COMMIT cú pháp; nó là một state machine sống cùng connection. BEGIN đẩy connection từ idle sang active , mỗi statement kết thúc đẩy nó về idle in transaction đợi statement kế tiếp, một statement lỗi đẩy sang idle in transaction (aborted) , và chỉ COMMIT / ROLLBACK mới trả connection về idle . Dev gặp lifecycle này trong việc thật không phải vì cú pháp khó mà vì một BEGIN quên COMMIT trong một code path lỗi: connection nằm trong pool ở idle in transaction vô thời hạn, giữ snapshot và lock, chặn autovacuum , kéo lock chain, làm bảng update-nóng bloat dần rồi cả service chậm chết. Cơ chế hoạt động Mặc định mỗi connection ở autocommit mode : mỗi statement là một transaction tự đóng. BEGIN (hoặc START TRANSACTION ) tắt autocommit cho tới khi gặp COMMIT / ROLLBACK . Trong khoảng đó connection có một xid (cấp khi cần ghi) và một snapshot, và lifecycle của nó đi qua các trạng thái mà Postgres phơi ra trong pg_stat_activity.state : idle — connection mở, không có transaction nào đang chạy. active — đang thực thi một statement (kể cả ngoài transaction block). idle in transaction — đang trong transaction block, vừa chạy xong một statement, đợi statement kế tiếp hoặc COMMIT / ROLLBACK . idle in transaction (aborted) — đang trong transaction, một statement đã ném lỗi, mọi statement tiếp theo trả ERROR: current transaction is aborted, commands ignored until end of transaction block cho tới khi ROLLBACK . fastpath function call / disabled — ít gặp, không phải mục tiêu của bài này. -- t0: state = 'idle' BEGIN ; -- t1: state = 'idle in transaction' (vừa thực thi xong BEGIN, đợi statement kế) INSERT INTO orders ( user_id , total ) VALUES ( 42 , 100 ); -- trong lúc chạy: state = 'active' -- sau khi statement xong: state = 'idle in transaction' lại INSERT INTO orders ( user_id , total ) VALUES ( NULL , 100 ); -- ERROR: null value

Read Committed: snapshot mỗi statement, và vì sao hai SELECT trong cùng transaction có thể trả khác nhau READ COMMITTED là isolation level mặc định của PostgreSQL, và là level mà phần lớn workload OLTP đang chạy mà không biết. Khác với mô hình "transaction lấy một snapshot rồi giữ nguyên" mà nhiều dev tưởng tượng từ MVCC, ở Read Committed mỗi statement lấy một snapshot mới tại thời điểm statement bắt đầu , không phải tại thời điểm BEGIN . Hậu quả thực tế: hai SELECT liên tiếp trong cùng một transaction có thể trả về dữ liệu khác nhau nếu giữa hai lần đó có transaction khác commit. Đây là non-repeatable read — đúng spec của Read Committed, không phải bug — và là nguồn của một class lỗi rất hay gặp: code đọc một giá trị, ra quyết định, rồi cập nhật dựa trên giá trị đã đọc, trong khi giá trị thực tế đã thay đổi. Cơ chế hoạt động Một transaction ở Read Committed không có transaction-level snapshot . Khi mỗi statement (mỗi SELECT , UPDATE , DELETE , INSERT ... SELECT ...) bắt đầu thực thi, backend lấy một snapshot mới gồm xmin , xmax và xip list — chính cái snapshot quyết định row version nào "visible" theo MVCC. Statement chỉ thấy: row có xmin đã commit trước thời điểm statement bắt đầu , và xmax chưa tồn tại hoặc thuộc một transaction chưa commit / đã abort. Ngay sau khi statement kết thúc, snapshot đó bị bỏ. Statement kế tiếp lấy snapshot mới — nếu trong khoảng giữa có transaction khác commit, statement này sẽ thấy dữ liệu mới đó. -- T1 BEGIN ; -- KHÔNG lấy snapshot ở đây SELECT balance FROM accounts WHERE id = 1 ; -- snapshot S1 -> trả 1000 -- ... T2 chạy: UPDATE accounts SET balance=500 WHERE id=1; COMMIT; SELECT balance FROM accounts WHERE id = 1 ; -- snapshot S2 -> trả 500 COMMIT ; Với UPDATE / DELETE / SELECT ... FOR UPDATE / FOR NO KEY UPDATE / FOR SHARE , Read Committed làm thêm một bước đặc biệt mà SELECT thường không làm: nếu target row bị một transaction khác đang lock (chưa commit), statement đợi transaction đó kết thúc. Khi unblock: nếu transaction kia ROL

Andy Brinkmeyer shares how engineering leaders and architects can use Rust to build failure-proof systems. Moving beyond memory safety, he explains how ownership, enums, and the typestate pattern embed complex runtime protocols into compile-time checks. Learn to eliminate entire classes of bugs, manage real-world resources safely, and maximize codebase robustness effortlessly. By Andy Brinkmeyer

Erik Steiger discusses the operational pain of legacy PDF generation in regulated banking and manufacturing. He explains how transitioning from resource-heavy engines like Puppeteer and LaTeX to a serverless Rust architecture powered by Typst can drop render latencies below 2ms. He shares how applying Git and Docker concepts to template registries ensures ironclad compliance and rapid debugging. By Erik Steiger