Secure AI agent handoffs without leaking context

Why Context Leaks at Handoff

The leak is rarely where teams expect it. Most assume the risk sits inside the model's reasoning loop, but the actual vector is the boundary where one agent compresses its state and hands a summary to the next. According to the Taskade agent documentation, an AI agent starts every session knowing nothing about the project except what is written down—the model is stateless, so the harness must rebuild the briefing from scratch on each request. That rebuild is the moment of exposure: whatever the receiving agent gets is whatever the sending agent chose to write, and that choice is made under token pressure, not security review.

State loss compounds because each agent compresses context to fit its window, silently dropping information at handoff boundaries. Multi-agent orchestration analyses from Ravoid and FlowCrews identify this compression as the primary leak vector—not a malicious exfiltration, but a systematic omission that looks like a summary and behaves like a data breach. When Agent A compresses a 40k-token conversation into a 4k-token summary for Agent B, the summary often contains the wrong details. Decisions, reasoning, and evidence get flattened into vague "we discussed X" statements, while raw artifacts—PII, internal identifiers, command outputs—survive the cut because they were easy to paste. The receiving agent never reads most of it, but it now sits in the context window, in the logs, and in any downstream trace.

Field threads on LangGraph production deployments describe the same failure mode: teams discover context drift only when the downstream agent produces confidently wrong output. There is no warning before the bad handoff. A concrete case: a three-agent pipeline with an extractor, an analyzer, and a formatter. The extractor passes raw PII-laden text to the analyzer because "it might need it." The analyzer never reads the PII—its task is structural—but the data is now in the analyzer's context, in the orchestration logs, and in any OpenTelemetry trace that captures input payloads. The leak is not an action; it is an artifact of over-provisioning context.

The decision rule that prevents this is simple and unforgiving: if you cannot name exactly which fields the receiving agent needs before the handoff, you are not ready to hand off. Go back and define the contract first. That contract is not a narrative summary; it is a receipt. The receipt pattern, implemented in the open-source project waggle, resolves a short token into a consumer-specific view with on-demand read or search, preventing automatic expansion of the full context artifact. The receipt includes input revision, issue state, files changed or inspected, commands and results, CI links, source-backed facts, decisions deferred, and redactions made. It is a ledger of what happened, not a story about what happened.

The tradeoff is real: receipts require more upfront design than dumping a summary. But the cost of the alternative is asymmetric. A narrative handoff leaks by inclusion—everything the sender thought was relevant, plus everything they did not bother to filter. A receipt leaks only if the token itself is compromised, and that token can be scoped, signed, and expiring. The frameworks support this: LangGraph, CrewAI, and Google ADK, the top open-source orchestration frameworks on GitHub as of August 2026, each offer different state-management models, and all of them allow you to gate transitions with human-in-the-loop approval nodes. The capability exists; the discipline is the missing piece.

Start today by auditing one existing handoff in your pipeline. Write down the exact fields the receiving agent consumes—not the fields you think it might need, but the fields its prompt actually references. If the list is shorter than the context you are passing, you have a leak. Replace the narrative with a receipt that resolves only those fields, and add a human approval node at that boundary. You will not eliminate all leakage, but you will make it a deliberate, reviewable act instead of an accident of compression.

The Canonical Rule: Receipts Over Narratives

The canonical rule for secure handoffs is to pass a receipt, not a narrative. A receipt is a short token that resolves into a consumer-specific view with on-demand read or search access, so the receiving agent fetches only what its role requires instead of inheriting a pre-digested story. This turns the handoff from a trust boundary into a verification boundary, and it is the single highest-leverage change most teams can make today.

Most articles tell you to write a good summary for the next agent. Field threads report the opposite: summaries are where context dies. The receiving agent reads the summary, trusts it, and never verifies against source, so errors compound silently across a pipeline. A summary is a compression artifact that hides the assumptions the writer made, and the next agent has no way to audit those assumptions without going back to the original data. The receipt pattern forces that audit by making the source the default, not the exception.

Concretely, instead of passing "user wants refund, order #12345, was unhappy with shipping delay," pass a receipt token that resolves to a view showing order status, refund policy, and the specific complaint. The receiving agent queries only what its role requires, and the full context artifact never expands automatically into the window. The open-source project waggle implements exactly this pattern, and it is worth reading its source before you build your own. The key mechanism is that the receipt is a pointer, not a payload, so the context window stays small and the log stays clean.

According to FlowCrews' 2026 analysis, most AI crew failures occur at transition points between agents, not inside individual agent logic. Identifying signals like context drift and out-of-memory errors allows a 40% reduction in failures via self-healing prompt patterns. The receipt pattern is the structural fix that makes those signals detectable in the first place, because it gives you a defined boundary where you can measure what was passed versus what was fetched.

Build the receipt with the Symphony context-engineering pattern: include input revision, issue state, files changed or inspected, commands and results, CI links, source-backed facts, decisions deferred, and redactions made. That last field is the one most teams skip, and it is the one that prevents leakage. If you redacted a field, say so explicitly in the receipt, because an implicit redaction is indistinguishable from an omission and the next agent will assume the data was never there.

One caveat: the receipt pattern only works if the receiving agent has a mechanism to fetch on demand. If your framework does not support tool calls at the handoff boundary, you are back to passing narratives. LangGraph, CrewAI, and Google ADK, the top open-source orchestration frameworks on GitHub as of August 2026, all support this differently, so check your framework's state-management model before committing. The OpenAI Agents SDK supports handoffs as delegation and also supports agents-as-tools, which gives you two ways to implement the fetch pattern, but the receipt itself is framework-agnostic.

Your next action today: take one handoff in your current pipeline and replace the narrative string with a receipt token that resolves to a filtered view. Test it with a property-based test that asserts the receiving agent only ever sees the allowed fields, using random inputs and shrinking to find the minimal counterexample. That single change will show you where your context is actually leaking, and it will give you a boundary you can monitor.

Context Budgets: Hard Limits That Save You

A context budget is the only handoff control that fails safe, and most teams skip it because it feels like bureaucracy until the first production incident. The mechanism is simple: set a hard limit on tokens or data fields that may cross each agent boundary, then define decision rules that trigger a refresh, rejection, or fallback to human-in-the-loop when the budget is exceeded. Ravoid's multi-agent orchestration analysis frames this as the difference between a handoff that degrades gracefully and one that silently corrupts downstream state.

Set the budget before writing any handoff code, not after. If the receiving agent's task can be done in 2k tokens, cap the handoff at 2.5k—anything larger is a signal that either the task is mis-scoped or the sender is over-sharing. The budget is not just a token count; it is a field allowlist. Define exactly which data fields may cross the boundary—order_id, status, timestamps, nothing else—and reject anything outside that schema at the validation layer. This is where the OpenAI Agents SDK's guardrails become useful: they support input and output validation as configurable checks, and you can apply them at handoff boundaries to enforce the allowlist mechanically rather than by convention.

The edge case that breaks most implementations is the truncation reflex. When a handoff exceeds its budget, the decision rule should not be "truncate"—it should be "reject and escalate." Truncation is how context drift starts: the receiving agent gets a partial view, fills the gaps with its own priors, and the error compounds silently across the pipeline. A rejection, by contrast, forces the sender to re-scope or a human to arbitrate. That is the difference between a contained leak and a full data exposure.

Field threads from CrewAI users describe the same arc: budgets feel restrictive in development, then become the difference between a contained incident and a breach in production. One practitioner on Reddit notes that their team removed budgets to speed up a demo, then spent a week tracing a hallucinated customer ID that had been truncated mid-handoff. The fix was not a bigger budget—it was a schema-level rejection that forced the sender to pass the full ID or fail loudly.

There is a concrete rule for when the budget itself is wrong. Raising the limit treats the symptom; the real problem is that one agent is doing two jobs. This aligns with the broader pattern that most AI crew failures occur at transition points; the failure signals that matter are context drift and out-of-memory errors, which surface only when you have a defined boundary to measure against.

One caveat worth naming: hard handoffs—where Agent A serializes state and Agent B deserializes it—give stronger compliance guarantees than soft handoffs where Agent B reads a shared log, but they cost latency. If your pipeline needs sub-second handoffs, a soft handoff with a strict field allowlist and OpenTelemetry spans as the interlock token is the pragmatic middle ground. The spans preserve trace context and data lineage across agent boundaries, which gives you auditability without the serialization overhead.

Today, pick one handoff in your pipeline and instrument it with a field allowlist and a rejection rule. Do not touch the token limit yet. Run it for a week and count how many handoffs get rejected—if the number is zero, your allowlist is too permissive. The rejection count becomes your leak metric, and the allowlist itself becomes the boundary you can monitor.

Guardrails at the Boundary

The most effective guardrail in a mainstream agent framework as of August 2026 is the OpenAI Agents SDK’s built-in input and output validation hooks, which you can attach directly to a handoff boundary. The non-obvious part is that these guardrails are not a security layer by default—they are configurable safety checks that only do work if you define what “safe” means for each transition. Most teams wire them up for input validation only, which is exactly backwards. The OpenAI Agents SDK documentation shows guardrails can run on both the incoming and outgoing payload, and the outgoing direction is where the leaks actually happen.

Consider the attack vector that Akto’s agentic AI security framework documents: a single crafted email hijacking Microsoft 365 Copilot to exfiltrate sensitive data. That is a zero-click scenario where the handoff boundary—not the model’s reasoning—is the point of compromise. The email arrives, the agent processes it, and the context that flows to the next stage carries the malicious payload. If you only validate what the receiving agent gets, you miss the moment where the sender over-shares. Field threads on practitioner forums consistently report that outgoing validation catches more leaks than incoming validation, because senders dump far more context than receivers ever mis-read.

The concrete pattern is bidirectional validation with a rejection rule. Before the handoff fires, run a regex and entity check on the outgoing payload for credit card numbers, API keys, and email addresses. If any of those appear outside an allowlisted field, reject the handoff entirely. After the handoff arrives, run the same check on the incoming context to catch anything that slipped through or was injected mid-transit. The OpenAI Agents SDK lets you implement this with guardrail hooks that execute synchronously at the transition point, and it supports explicit agent-to-agent handoffs with built-in approval and pause mechanisms—so you can halt the pipeline when a check fails instead of letting the next agent proceed with poisoned context.

The failure mode that breaks most naive implementations is obfuscation. A credit card number base64-encoded inside a JSON blob will pass a raw-text regex check every time. The same applies to API keys embedded in URL-encoded query strings or JWTs. Run detection on decoded values, not just the raw payload. That means your guardrail function needs to attempt base64 decode, URL decode, and JSON parse before it runs the entity check. This adds latency—typically a few milliseconds per handoff—but it is the difference between a guardrail that catches obvious leaks and one that catches the leaks that actually matter in an attack.

One edge case worth noting: guardrails that reject on any sensitive field will produce false positives when the receiving agent legitimately needs a customer email address to send a notification. The fix is an allowlist per handoff pair, not a global blocklist. Define which fields are permitted to cross each specific boundary, then reject anything outside that set. This is stricter than a deny-list approach and it forces you to document the data flow explicitly, which is the same discipline the receipt pattern described earlier enforces. As of August 2026, LangGraph, CrewAI, and Google ADK all have different handoff and state-management models, but none of them ship a bidirectional validation layer as close to production-ready as the OpenAI Agents SDK’s guardrail hooks.

Today, pick the handoff in your pipeline that carries the most sensitive data and add a guardrail that validates both directions with a field allowlist. Run it against a test payload that includes a base64-encoded API key to confirm the decoded check fires. Once the guardrail passes that test, extend it to the next most sensitive boundary in your pipeline.

Case Study: Three-Agent Pipeline With Receipts

Each option includes concrete costs and trade-offs so you can pick the one that fits your constraints.

The receipt token should include a version hash. When the analyzer produces a conflicting classification, the system detects the drift and re-fetches the source rather than trusting the stale summary. That is where the self-healing pattern from the earlier section pays off: the hash gives you a concrete signal that the receiving agent's view is out of date, and the re-fetch is a deterministic recovery path, not a guess. Without the hash, you are back to trusting a summary that may have been generated from a different version of the ticket.

For the redaction layer, Microsoft Presidio provides pre-built recognizers for credit card numbers and health records, with custom regex or LLM-based scrubbers as fallback. The field reports that matter here are the ones describing base64-encoded API keys inside JSON blobs passing raw-text regex checks—your redaction function needs to attempt base64 decode, URL decode, and JSON parse before it runs the entity recognizers. A central registry with row-level security, such as Postgres RLS, enforces that Agent B can only query the exact keys Agent A wrote for it; namespace-isolated vector stores do the same for embeddings.

Version your handoff contracts using JSON Schema or Protobuf with explicit backward and forward compatibility rules, so upgrading the extractor's output format does not break the analyzer. Implement a dead-letter queue for failed handoffs—Agent A's partial outputs must not be lost or exposed to Agent B before validation passes. LangGraph, CrewAI, and Google ADK each handle state differently, and the choice matters less than the contract you enforce at the boundary. Today, pick the handoff in your pipeline that carries the most sensitive data, add a receipt token with a version hash, and run a property-based test asserting the receiving agent only ever sees the allowed fields.

Lessons Learned: What Field Threads Actually Report

The most useful thing field threads actually report is that the handoff boundary is where secrets go to die, and it's rarely the model that leaks them. One r/sysadmin thread from May 2026 on agent orchestration failures puts it bluntly: teams discover leaked API keys in downstream logs weeks after the incident, and the handoff boundary is almost always the culprit. The model didn't hallucinate the key into the log—the orchestration code passed a context blob that contained it, and nobody checked the payload schema before it crossed the boundary.

According to Fiddler AI's tracing guide, handoff payload schemas and context diff tracking are the two most underused observability features in production agent systems. Most teams trace model calls obsessively—latency, token counts, tool invocations—but they do not trace the context passed between agents. That is a blind spot with a direct cost: when a downstream agent produces confidently wrong output, you cannot tell whether it was a model failure or a context failure, because you never recorded what context the receiver actually saw. Diff tracking closes that gap by showing you exactly which fields changed between the sender's state and the receiver's state, and it is the only way to audit a handoff after the fact.

The most common production failure is not a security breach but silent context drift. The receiving agent acts on stale or incomplete context and produces confidently wrong output, and the team only notices when a customer complains. This is more insidious than a leak because it looks like a model quality problem, so teams waste weeks tuning prompts on the wrong layer. The fix is not better prompting—it is versioning the context itself. HN threads on CrewAI and LangGraph report that teams who implement receipt-style handoffs see fewer "agent argued with itself" failures, because the receipt token forces a single source of truth instead of multiple competing context copies floating through the pipeline.

The open-source waggle project's receipt pattern is gaining traction for a specific reason: it solves the versioning question that nobody else addresses cleanly. Which version of the context did the receiver actually see? With receipts, the answer is always "the one the token resolves to, at the time of resolution." That matters more than it sounds, because context artifacts mutate as they pass through intermediate steps, and without a token you are comparing apples to oranges when you try to debug a bad handoff. The receipt gives you a stable reference point for both audit and rollback.

According to the waggle project's documentation, as of August 2026, that threshold is not a hard security limit—it is a smell test. Large context payloads are a symptom of the canonical receipts-over-narratives rule being violated: they almost always mean you are shipping the sender's entire working state instead of a distilled receipt, and that is exactly the pattern that leaks secrets and causes drift. Split the task, define a receipt, and set a budget before you build the handoff logic.

The caveat is that receipt-style handoffs require discipline on the sender side. A receipt only helps if the sender actually redacts sensitive fields and includes a version hash, and if the receiver validates the token before acting on it. Teams that skip the validation step get the worst of both worlds: they pay the overhead of a receipt system without the auditability. The concrete action for today is to pick the handoff in your pipeline that carries the most sensitive data, instrument it with a payload schema check and a context diff log, and run one test handoff with a deliberately over-shared payload to confirm the boundary rejects it.

What to do next

Securing agent handoffs is an ongoing discipline, not a one-time configuration. The steps below focus on verification, testing, and incremental adoption using widely available tools and standards.

Also worth reading: Audit and trace AI agent decision chains · Human-in-the-loop approvals for critical AI agent decisions · Managing API rate limits for multi-agent orchestration · Human-in-the-loop agent workflows: 7 best practices that scale

Sources: github, langchain, contextpatterns, codeguides, akto