Teams should split read permission from forward permission and enforce a destination policy at the point of use. A user may be allowed to inspect a record, but the same data may still be blocked from entering an external API, a sub-agent, or a different workflow step.
Separate Read From Forward for Agentic Access
The core control is to treat inspection and onward disclosure as different permissions. An agent can be allowed to fetch or view a record while still being denied the ability to pass that record into an external API, a sub-agent, or a later workflow step unless policy says the destination is allowed. That separation is what keeps “can see” from becoming “can relay.”
In practice, this means the decision must happen at the handoff point, not only at login or initial retrieval. The system should evaluate the destination, the data class, and the current task before allowing the transfer, because the same value may be safe to read in one context and unsafe to export in another.
For agents that operate across tools, policy should be applied on each action boundary, not just once per session. AI Agent Authorisation Guide is the right place to anchor that model: task-scoped access, per-action decisions, and human approval gates are all part of preventing unnecessary propagation.
Where Destination Control Has to Sit
The most reliable pattern is destination-aware enforcement at the point of use. If the next hop is an external service, another agent, a different workflow lane, or a human-visible export, the policy engine should decide whether that specific destination may receive the data. This is more precise than broad data-access rules because it preserves legitimate review while blocking unintended redistribution.
This is especially important when the workflow includes tool calls or message passing. If the agent can copy payloads freely between components, the organisation loses the ability to distinguish local use from exfiltration-like forwarding. A destination policy turns those transfers into explicit, auditable decisions instead of side effects of normal orchestration.
Teams should also treat delegation chains as separate trust decisions. When one step can invoke another, the receiving step should not inherit broader forwarding rights than the originating step actually needs. MCP Security Guide is useful here because it addresses tool access, OAuth-based authorisation and token passthrough, all of which shape whether data can move beyond the original intent.
For multi-hop or multi-agent workflows, Multi-Agent and A2A Security Guide reinforces the need to control inter-agent communication and delegation chains so that one agent’s visibility does not automatically become another agent’s entitlement to reuse the same data elsewhere.
What Teams Should Verify Before Trusting the Workflow
Teams should verify that the control is enforced where data is actually moved, not only where the request begins. A useful test is to ask whether a permitted read can still be prevented from reaching each downstream destination class, including external APIs, shared memory, logs, prompts, tickets, and sibling workflows.
They should also verify that the policy is evaluated on the current request context, not on a stale role or static allowlist. If the agent can change destination without re-authorisation, then the control is really a read permission with a weak afterthought attached, not a true forwarding restriction.
Zero Trust for AI Agents is the clearest internal reference for this model, because it ties verification to the principal, the request and per-action policy rather than assuming standing privilege after initial access.
At the external level, the relevant standards and frameworks also support this separation of duties. OWASP Agentic AI Top 10 captures identity and privilege abuse in agentic systems, while RFC 8693: OAuth 2.0 Token Exchange is relevant where forwarding depends on explicit delegation rather than blind reuse of the original credential.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Forwarding rights beyond needed destinations create overprivilege risk. |
| Recommendation — Constrain agent destinations to the minimum approved set. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents can misuse read access to relay data into unapproved tools or workflows. |
| Recommendation — Enforce per-action authorisation before any downstream handoff. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Destination policy is an access-enforcement decision at the use point. |
| AC-6 — Least Privilege | Read permission and forwarding permission should be separated by least privilege. | |
| Recommendation — Apply destination-specific access checks at each transfer boundary. Grant only the permissions needed for inspection, not reuse or export. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege Access Principles | Zero trust requires verified, bounded actions before any data leaves the task boundary. |
| Recommendation — Verify each request and reauthorise downstream movement explicitly. | ||
Practitioner Guidance
What to prioritise: Start by identifying every destination the agent can reach, then mark which ones are allowed to receive copied or derived data. The highest-value control is usually not the read itself, but the first uncontrolled handoff.
Decision rule: If the data can influence an external side effect, another agent, or a persistent store outside the originating task, require a separate policy decision for that transfer. If no destination policy exists, treat forwarding as blocked by default.
What to verify: Confirm that the agent cannot bypass policy by reformatting, chunking, or relaying the same content through an intermediate step. The control should hold even when the transfer is indirect.
Practitioner takeaway: The safest design is to let agents inspect data only inside a bounded task, then require explicit destination approval before any reuse outside that boundary.