A Technical blog series on where sensitive data moves in an AI workflow, what decisions Protecto makes at each point, and what enterprises get from enforcing policy once instead of everywhere.
Contents
Introduction The Six Places Enterprise AI Touches Sensitive Data
Pattern 4 · MCP Gateway Your Agents’ Tools See More Than Your Agents Do: Protecto as the MCP Gateway
Pattern 5 · Agent Gateway When One Agent Hands a Case to Another: Protecto as the Agent Gateway ← You are here
Pattern 6 · RAG PipelineThe Archive That Answers Back: Protecto in the RAG Pipeline
PATTERN 5 · AGENT GATEWAY
When One Agent Hands a Case to Another: Protecto as the Agent Gateway
The riskiest moment in a multi-agent system isn’t a model call or an API lookup. It’s the handoff: one agent passing an entire work product to another agent with a different job, different access needs, and a different audience. This article follows one escalation between two agents and shows what changes when Protecto governs the handoff, in both directions.
Part of a series on the six places Protecto fits into an AI workflow. Each article stands alone: a real-world style use case, where Protecto sits, what changes, and what the business gets out of it.
The situation
Atlas Insurance runs two AI agents that work together. Claire is the claims agent: customer-facing, answering policyholders about their claims. Sentinel is the fraud-review agent: internal, examining suspicious claims and recommending action. The story here is an insurer’s, but swap in a support agent escalating to a security agent, or a sales agent handing a deal to a finance agent, and the mechanics are identical: two agents, different roles, and a case that has to move between them.
When Claire spots something off, a repair invoice that doesn’t match the damage description, she escalates. And an escalation isn’t a field lookup. It’s a package: the claim, the policy history, the case notes, everything Claire has. The natural way to build this is to hand Sentinel the whole package, because who knows what the fraud review might need?
Then the review finishes, and Sentinel’s findings travel back: a fraud risk assessment, the indicators that fired, notes about which patterns this claim matched. That return package lands in Claire’s context. Claire talks to customers.
Why handoffs are where exposure hides
Each agent on its own can be well-governed. Claire’s context is protected, Sentinel’s access is scoped, and both passed security review individually. The handoff is what nobody reviewed, because it isn’t an API with a schema or a prompt with a policy. It’s one agent’s entire working state moving to another agent, in whatever shape the developer chose.
Two things go wrong quietly. Outbound, Sentinel receives far more than fraud review needs: the policyholder’s SSN, bank details, and health and medical information ride along inside the case package, then settle into Sentinel’s memory and logs. Each additional hop in a delegation chain is another system that may retain what it received, so the exposure grows with the length of the chain even though no single hop looks unreasonable.
Inbound is subtler and worse: Sentinel’s return package carries internal fraud indicators and investigation methods into a customer-facing agent’s context. One well-phrased customer question later, Claire is explaining which fraud patterns her company screens for. Confidential business data leaking through a return path is the handoff risk almost every team forgets.
Fixing this inside the agents means every agent pair maintains its own filtering logic for both directions, and every new agent multiplies the pairs. In a fully connected topology, n agents produce n(n-1) directed paths: three agents make six, six agents make thirty. Real topologies are usually sparser than that, but the direction of the curve is the point, and it grows faster than any team’s diligence.
What changes with Protecto
Multi-agent frameworks route handoffs through an agent gateway, the layer that delivers messages between agents. Attach Protecto there, and every handoff is evaluated on delivery, in both directions, under rules defined per sending agent, receiving agent, and task.
The decisions, concretely
Claire escalates claim CL-2291. Here’s what she holds:
Maria Torres · SSN 543-88-1201 · bank acct #88-4392 · Claim CL-2291, rear-end collision · repair invoice $9,850 from Apex Auto Body · 2 prior claims (2023, 2025) · Notes: "Physical therapy ongoing. Invoice itemization doesn't match damage photos."
The outbound decision. Fraud review needs the claim facts, the history, and the anomaly. It does not need banking details or the medical context. Here’s what Sentinel receives:
[NAME_2c88] · SSN [SSN_c419] · bank acct [ACCT_7d20] · Claim CL-2291, rear-end collision · repair invoice $9,850 from Apex Auto Body · 2 prior claims (2023, 2025) · Notes: "Invoice itemization doesn't match damage photos."
Notice what the placeholders make possible. Sentinel can still do real fraud work, because [NAME_2c88] is the same placeholder across every claim this person ever filed and Apex Auto Body stays in the clear. Sentinel can discover that [NAME_2c88] has three claims with the same repair shop without ever holding a name. Cross-case pattern detection survives; identity exposure doesn’t. That consistency is a deliberate policy choice, scoped to the fraud-review workflow rather than shared universally. The medical line was removed outright, because treatment status is health and medical information with no role in an invoice review.
The return decision. Sentinel finishes and produces:
Risk: HIGH. Indicators fired: repeat-shop pattern (3 claims via Apex), invoice-to-damage mismatch score 0.87, prior claim velocity. Recommend: hold payment, route to SIU.
What reaches Claire:
Claim CL-2291 is under review. Hold payment. Expected review time: 5 to 7 business days. Customer may be told: "Your claim requires additional review."
Claire gets exactly what a customer-facing agent needs: the status, the action, and approved language. The indicators, scores, and methods stay on the internal side of the gateway. If a customer probes, Claire cannot leak what she never received.
Unmasking follows the same discipline as everything else. When the SIU investigator’s own tooling later needs the real identity to act on the referral, unmasking isn’t a privilege the agent owns. It is controlled by policies defined for the user and the task, and Protecto applies the appropriate policy, ensuring that each agent receives only the level of access to sensitive data it needs.
What customers get
| Advantage | What it means in practice |
| Both directions governed | Outbound handoffs carry the minimum the receiving agent’s role needs; return paths can’t carry internal analysis into customer-facing contexts |
| Less accumulation across chains | Each hop re-applies policy instead of forwarding whatever it received, so a longer chain doesn’t automatically mean a wider spread |
| Pattern detection without identity exposure | Scoped consistent placeholders let analytical agents link records across cases while identities stay protected |
| Rules per pair, managed centrally | Handoff policies live at the gateway, not in agent code, so adding an agent means adding rules, not rewriting neighbors |
| A clean audit story | “What did the fraud agent actually receive?” has a logged, specific answer for every escalation |
What this doesn’t do
The agent gateway governs what moves between agents. It doesn’t govern what an agent does internally with data it legitimately received; that’s the in-agent pattern. It doesn’t cover the agents’ own model calls or tool calls, which the AI gateway and MCP gateway patterns handle. Policy design here is real work: someone has to decide what each agent pair’s handoffs should carry, and that conversation, between the agent owners and security, is the actual cost of the pattern. Latency applies per handoff, and multi-agent workflows can chain several.
When this pattern is the right one
Reach for the agent gateway when agents with different roles and audiences exchange work products, especially when one side is customer-facing and the other is internal, or when delegation chains run more than one hop. The moment you notice a return path carrying internal analysis toward an external audience, this is the pattern that fixes it.
Look elsewhere when the flow you’re worried about isn’t agent-to-agent: shared internal APIs point to the API gateway pattern, model traffic points to the AI gateway, and tool calls point to the MCP gateway.
