Because each handoff can widen or drop the original user’s permissions. If identity and entitlement do not follow the task through retrieval, tool calls, and response generation, downstream agents may expose data that the initiating user should never see. That is why permission context must persist across the whole execution chain.
Why This Matters for Security Teams
Multi-agent workflows are not just larger versions of single-agent assistants. Each agent, tool call, retrieval step, and handoff creates a new chance for permissions to drift, context to be truncated, or sensitive data to be reintroduced in a different trust boundary. That matters because the original user intent can be diluted while the system still appears to be operating “on behalf of” that user. Guidance from the NIST Cybersecurity Framework 2.0 is useful here: security outcomes depend on governance, asset visibility, and access control working together, not as isolated checks.
The main risk is not only accidental overexposure. Multi-agent orchestration can also amplify prompt injection, tool misuse, and unauthorized retrieval when one agent trusts another agent’s output without revalidating scope. That becomes more serious when agents have access to email, ticketing, code repositories, data lakes, or customer records, because the system can leak data through summaries, logs, or generated actions even when the final answer looks harmless. The OWASP Agentic AI Top 10 treats insecure agent handoffs and excessive autonomy as core risk areas. In practice, many security teams encounter leakage only after an agent has already propagated a sensitive field into a downstream tool, rather than through intentional data governance.
How It Works in Practice
The leakage path usually starts with a legitimate request that is decomposed into subtasks. One agent may retrieve context, another may enrich it, and a third may generate the response or execute an action. If identity and entitlement are checked only at the first step, later agents may inherit broad context without re-confirming whether the user is allowed to see every object in that chain. This is where permission context has to travel with the task, not just with the session.
Operationally, teams should treat each agent transition as a control point:
- Preserve user, role, and purpose context across retrieval, tool use, and generation.
- Apply least privilege to each agent, tool, and connector separately.
- Redact or tokenize sensitive fields before they enter shared memory or logs.
- Validate outputs before they are forwarded to another agent or external system.
- Monitor for unexpected data amplification, especially across summarization steps.
Threat modeling guidance from the CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix both point to the same operational reality: once one agent can influence another, the attack surface expands from model behavior to orchestration behavior. That is especially true when a tool returns more data than the task required, because downstream agents often treat “available” as “permitted.” These controls tend to break down when agents share a common memory store across tenants or business functions because provenance and access boundaries are no longer enforced at each hop.
Common Variations and Edge Cases
Tighter per-agent controls often increase orchestration overhead, requiring organisations to balance leakage reduction against latency, engineering complexity, and operational friction. There is no universal standard for how much context each agent should retain, so current guidance suggests minimizing retained data while keeping enough provenance to support audit and recovery.
Some environments need special treatment. In customer support workflows, summarization can accidentally strip the very permission markers needed to enforce redaction. In software delivery pipelines, an agent that can read source code may not be allowed to expose secrets embedded in tickets or build logs. In regulated environments, the bar is higher: the NIST AI Risk Management Framework is useful for structuring governance, while the Anthropic first AI-orchestrated cyber espionage campaign report shows why agentic misuse can move from theory to incident response very quickly.
Best practice is evolving for cross-agent consent propagation, shared memory partitioning, and response-level filtering. Where the workflow crosses business units, legal entities, or data classes, a single “approved” agent is not enough if its downstream peers are not equally constrained. The practical test is simple: if one agent can learn something the user was not entitled to know, the workflow is already leaking.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN | Governance is needed to preserve context and accountability across agent handoffs. |
| OWASP Agentic AI Top 10 | Agent Handoffs | Agent handoffs can expand trust boundaries and leak data across chained workflows. |
| MITRE ATLAS | T1190 | Adversarial manipulation can exploit orchestration paths to expose or reroute data. |
| CSA MAESTRO | MAESTRO addresses threat modeling for multi-agent orchestration and shared context. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central to stopping overexposure in chained agent workflows. |
Define ownership, approval, and audit rules for every agent, tool, and shared memory path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
