How do you prevent context leakage between agents?

Context leakage between agents happens when one agent receives information it should not have, such as another tenant's data, unnecessary secrets, hidden system instructions, or unrelated conversation history. Preventing leakage requires strict context boundaries, explicit sharing rules, and authorization checks at every handoff.

Beginner-friendly example: API test generation

Suppose your platform generates API tests for two customers:

• Tenant A: Banking APIs
• Tenant B: E-commerce APIs

A test-generation agent working for Tenant A should never receive Tenant B's requirements, credentials, logs, or generated test cases.

Even if both tenants use the same agent implementation, their workflow state, retrieved documents, artifacts, and message queues must remain isolated.

How does context leakage happen?

Common causes include:

• Reusing one shared memory store without tenant filtering
• Passing full conversation history to every agent
• Retrieving documents without access-control filters
• Sharing secrets inside prompts or handoff messages
• Reusing cached responses across users
• Writing multiple tenants' data into the same unscoped workflow state
• Letting agents access tools with broader permissions than their role requires

How do you prevent it?

1. Use tenant-scoped identifiers: Every workflow, message, artifact, and retrieval request should include a trusted tenant or user scope.
2. Enforce authorization at the data layer: Do not rely only on prompt instructions such as "only use Tenant A data." The database, retrieval layer, and tool gateway should enforce access.
3. Share minimum necessary context: Pass only the fields the receiving agent needs.
4. Separate secrets from prompts: Credentials should stay in secure secret stores and be injected only into approved tool calls.
5. Use explicit agent permissions: Each agent should have access only to the tools and data required for its role.
6. Validate every handoff: Confirm that the destination agent is allowed to receive the referenced data.
7. Isolate caches and memory: Include tenant/user scope in cache keys and persistent memory namespaces.
8. Audit access: Log which agent accessed which artifact or data source.

Example of safe handoff

Instead of sending an entire document, pass a scoped payload:

JSON
{
  "tenant_id": "tenant-a",
  "task_id": "payment-api-42",
  "endpoint": "POST /payments",
  "requirements_ref": "artifact:req-9382",
  "allowed_actions": ["generate_tests"]
}

The receiving agent can access requirements_ref only if the runtime verifies that the artifact belongs to tenant-a and the agent has permission to read it.

LangGraph considerations

In LangGraph:

• Keep tenant identity in trusted runtime configuration or validated state.
• Use separate thread/run identifiers per workflow.
• Do not merge state from unrelated runs.
• Store large artifacts outside graph state and pass scoped references.
• Validate state updates before routing them to another node.

The graph itself should not be the only security boundary. The underlying database and tools must also enforce isolation.

Supabase considerations

If Supabase stores workflow data or artifacts, use Row Level Security (RLS) to enforce tenant ownership where appropriate.

A secure design typically combines:

• authenticated user identity
• tenant membership stored in trusted authorization data
• RLS policies that check ownership or membership
• application-level validation

Never rely on user-editable metadata for authorization decisions.

Retrieval and vector-store leakage

RAG-based agents can leak context if retrieval is not scoped correctly.

For example, a query such as:

"How does the payment API handle refunds?"

must filter retrieval by the current tenant or project before similarity search results are returned.

The safe sequence is:

Authorize → Filter allowed corpus → Retrieve → Generate

not:

Retrieve everything → Ask the model to ignore unauthorized results

Common mistakes

• Using prompt instructions as the only security mechanism
• Storing tenant IDs supplied directly by the model without validation
• Passing service-role credentials to agents
• Sharing complete logs that contain secrets
• Forgetting tenant scope in background jobs
• Using a global vector index without metadata enforcement
• Reusing memory or cache keys across users

In short

Prevent context leakage by enforcing isolation outside the model: scope every workflow, retrieval, artifact, cache, and tool call to the correct identity and permissions. Prompts can guide behavior, but real protection must come from authorization, data-layer controls, and minimal context sharing.