Disclaimer
This article is intended for informational purposes and reflects the state of published research and industry practice as of its publication date. It is not professional security advice. Your specific environment, threat model and regulatory obligations will shape how these principles apply to your situation. The views and opinions expressed here are my own and do not represent the position of my employer, SAP or any other affiliated organization.
For Security Leaders
An external agent can ask your systems for more data than the task permits. If your systems honor that request, a one-user investigation can become tenant-wide disclosure. A partner’s explanation must not become permission to disclose your data.
What this means for your organization:
Access limits: Partner requests need checks against the work your organization approved.
Interrupted work: Permission may be withdrawn while a provider is still processing a task.
Released data: Stopping future access does not retrieve records a provider already received.
What to tell your teams:
Identify every route through which the external agent can obtain your data.
Keep the approved user, time interval and operation outside the agent’s control.
Test approved reads, expanded requests and resumed reads after permission is withdrawn.
Record access decisions and actual disclosures so recovery can establish what was released.
Securing agent delegation: what can we enforce?
Consider an incident-response agent asking an external service to help investigate a suspicious login. The approved work covers one user within a defined time interval. The external agent asks for the whole tenant’s login history because, it says, the wider context would improve the investigation. That might be a useful request. It also exceeds the approved access.
Who decides whether it gets those records?
In “Orchestrator-to-Orchestrator Is the Next Agentic Trust Boundary,” published May 12, 2026, I argued that a peer agent can ask your orchestrator to use authority across a boundary. I still think that is the right problem to investigate. Since then, the protocols have gained more explicit ways to manage access and continued work. We need to understand which part of this request they help us control.
I will use the same illustrative investigation to work through that question. The local organization owns the incident, the service that issues access tokens and the sign-in logs. An external provider runs the enrichment agent. This is a proposed design based on published specifications, with no execution results to show that it works.
Put the check where the data is
The local orchestrator may already have permission to read every user’s sign-in records. If it accepts the external agent’s explanation and uses that credential, the log service may see a valid request from an authorized caller. The analyst’s narrower approval has disappeared from the access decision. The problem starts when the task description is allowed to determine how much of the orchestrator’s permission gets used.
I would keep the approved user, interval and operation in a record the agent cannot rewrite. An analyst’s approval can establish that record. An existing organizational policy can also authorize the investigation without asking the analyst to approve every covered request. Either way, the service deciding access needs a trusted record of what was permitted.
That record has to reach an enforcement point. Before returning sign-in data, the log service or a service that reliably mediates access to it should compare the requested user and interval with the approved limits. Another user or a wider interval should be rejected unless a separate decision authorizes the change. Writing “only investigate this user” in the agent’s instructions leaves that decision to the model.
Where you implement the check depends on how the agents reach the data. Two agents inside one application may share a service credential. A remote agent may call your log service with its own restricted token. An agent exposed as a tool may perform the read somewhere else entirely. Follow the credential to the component that reads the records, then check whether there is a route around your permission check.
A local tool wrapper can be enough if every relevant operation goes through it and the agent cannot use a broader credential elsewhere. If several applications can reach the logs, the restriction belongs at the resource-facing service they all have to use. The useful question is whether a disallowed read can reach the data. The names of the agents and the choice of development framework do not answer it.
For the proposed investigation, I would let the external participant request the approved slice directly from the organization’s log service. It obtains its own restricted token and that service checks the read. Any incident read made through the local orchestrator must pass the same approval check. Otherwise, the provider could ask the orchestrator to use its broader credential and bypass the restriction we just established.
To continue reading this article, please subscribe, the entire article is available for free for all subscribers (free or paid).
Fact-check appendix
Statement: “In ‘Orchestrator-to-Orchestrator Is the Next Agentic Trust Boundary,’ published May 12, 2026, I argued that a peer agent can ask your orchestrator to use authority across a boundary.” | Source: Fernando Lucktemberg, Next Kick Labs.
Statement: “Agent2Agent (A2A), the protocol for remote agent collaboration, requires production encryption, request authentication and authorization checks for task operations.” | Source: A2A v1.0.1 specification, section 7. The specification leaves authorization logic to the implementation.
Statement: “When that flow is used, a server must accept only tokens intended for its own resources.” | Source: MCP authorization specification. Authorization is optional at the protocol level; audience validation applies when this flow is supported.
Statement: “MCP’s Enterprise-Managed Authorization extension was announced stable on June 18, 2026.” | Sources: Paul Carleton, official MCP announcement, stable extension specification. The dependency is identity-assertion authorization grant revision 04, an Internet-Draft.
Statement: “MCP’s stable July 28, 2026 revision removes protocol-level sessions and the initialization handshake.” | Sources: MCP release record, revision changelog. The changelog also establishes per-request version and capability metadata.
Statement: “A2A’s version 1.0 was released on March 12, 2026, before O2O.” | Sources: A2A release record.
Statement: “Version 1.0.1 was published on May 28, 2026 and contains protocol fixes.” | Source: A2A release record. The changelog is dated May 26; release publication is May 28. The maintenance characterization is author judgment based on the listed fixes.
Statement: “It defines how to request another token and leaves the token’s security properties and trust policy to the deployment.” | Source: RFC 8693, section 1. The proposed user/interval comparison and further-delegation rule are application policy.
Statement: “The issuer validates that proof and binds the access token to its key.” | Source: RFC 9449, sections 3-5. The key comes from the external participant’s token-request proof. DPoP’s token-leakage objective and limits when signing keys can be used are described in sections 2 and 11.4.
Statement: “The log service validates the token and proof, checks that both refer to the same key and confirms that the proof matches the presented token and current request.” | Source: RFC 9449, sections 4.3, 6.2 and 7 establishes proof validation and token binding. The subsequent one-user and interval comparison is the proposed resource policy.
Statement: “DPoP also leaves general request-body integrity outside its protection and excludes query parameters from its target-address claim.” | Source: RFC 9449, sections 4.2, 4.3 and 11.7. The target-address claim also excludes fragments.
Statement: “Caching that answer reduces validation traffic but can preserve an earlier active decision after revocation.” | Source: RFC 7662, section 4. Cached responses must not be used beyond the supplied expiration; freshness settings are deployment choices.
Statement: “Introspection can also return a DPoP token’s key binding; the log service still performs the request’s proof verification itself.” | Source: RFC 9449, section 6.2. The introspection endpoint supplies binding information; the resource server validates that binding locally.
Statement: “The server must treat that returned state as attacker-controlled input and check its integrity when it affects authorization, resource access or business logic.” | Source: MCP multi-round-trip request specification. Exact state echo is required; principal, expiry and originating-request binding are recommended.
Statement: “MCP’s task extension describes cancellation as cooperative: the server acknowledges the request but is not obliged to stop the work.” | Source: MCP tasks extension. The proposed stop-issuance, access-invalidation and reconciliation procedure is author synthesis.
Statement: “Identity checks and evidence about its deployment support particular trust decisions; they cannot establish how its next decision will treat the data.” | Source: Author analysis informed by the scope and freshness limits of evidence in the Remote Attestation Procedures architecture, RFC 9334.
Statement: “Article 077 will address identity and trust, 078 will define delegated permission and its lifecycle and 079 will address state, execution and recovery.” | Source: Author’s series plan. These are planned articles, not completed implementation results.
Top 5 sources
A2A v1.0.1 specification. Official A2A project specification, maintained by project contributors. Normative text establishes collaboration and task-access requirements.
MCP 2026-07-28 specification. Official MCP specification, maintained by project contributors. Changelog and continuation requirements establish the revised request model and state checks.
OAuth token exchange, RFC 8693. Internet Engineering Task Force (IETF), RFC Editor. Authors: M. Jones, A. Nadalin, B. Campbell (editor), J. Bradley and C. Mortimore. Published standard defines exchange and its policy boundaries.
OAuth DPoP, RFC 9449. IETF, RFC Editor. Authors: D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones and D. Waite. Published standard defines possession proofs, token binding and their limits.
OAuth token introspection, RFC 7662. IETF, RFC Editor. Author: J. Richer (editor). Published standard establishes active-state responses and caching constraints.
P.S. How AI was used in the creation of this piece:
I set the scope and writing rules.
AI helped organize the argument and structure.
AI assisted with research and source checks.
AI helped draft and revise the text.
I am responsible for validating the claims, citations and final wording before publication.