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 specialist may have access to more data than the work you delegated permits. Unless the service releasing data enforces those limits, an approved task can lead to unauthorized disclosure. Permission must remain bounded wherever delegated work can release your data.
What this means for your organization:
Data exposure: A provider’s existing access may exceed the task you approved.
Cumulative access: Parallel workers can collectively exceed an approved allowance.
Withdrawal: Ending permission may leave queued work and earlier access decisions in use.
What to tell your teams:
Identify every route through which a specialist can retrieve the data.
Keep permitted users, operations and time intervals in records the agent cannot change.
Apply one shared allowance across delegated workers and retries.
Agree when receivers must recheck permission and how withdrawal affects queued work.
Who authorized this? Enforcing authority across delegation
Accepting a caller does not authorize every operation
Your orchestrator delegates a log-reading task to an external specialist. The permitted read covers one user’s sign-in logs within a defined interval. The specialist has its own backend access, which may cover more records. I would keep that credential with the specialist and enforce the delegated limits at the component that releases the logs.
For that read, the component must establish who granted permission, whether the specialist may use it, and whether the requested records fall within its limits. Accepting the specialist’s identity leaves those decisions open. If the backend accepts its broader credential without checking the delegated limits, the specialist can retrieve records outside the permitted read.
The previous identity article established how the receiver could accept the caller and its provider. We can now use that accepted identity to decide what the caller may do. Who granted the access, which limits apply, and what happens if the task resumes after those limits change?
The standards define useful parts of that decision. They leave the task-specific permission rules to the deployment. The log read is a running example of those enforcement decisions. The design here is a proposal based on primary sources, with its end-to-end enforcement still unverified.
The receiver must bind the operation to its authorization
For the receiver to enforce a delegated limit, it needs a trusted record of the permission being exercised. My starting point is an approval record your organization controls, specifying the permitted user, interval, operation and specialist. The request refers to that record. Changing the task message cannot expand the recorded permission.
The record must distinguish the principal authorizing access, the user whose records may be read and the specialist performing the read. The receiver checks the authorizing principal’s authority to permit access, then whether that permission covers this specialist and these records. Conflating those identities could apply a valid permission to the wrong actor or data. The roles remain distinct even when the same principal occupies more than one of them.
The orchestrator and specialist also perform different operations. Your orchestrator invokes the specialist’s service; the specialist reads logs. Giving the orchestrator the specialist’s entire privilege set would create another route to the logs. Requiring identical scope names at both services could reject legitimate work. We need an explicit mapping between the authorized invocation and its permitted backend effects.
Your issuer can record that mapping and its limits in a server-side grant linking the tenant, task, accepted specialist, permitted read, approval revision and shared budget. It checks the protected approval and authenticates the specialist before issuing an opaque credential linked to that record under the accepted identity/key-binding policy. Your original parent credential stays local. The grant fields are custom application data. The wire-level issuance integration still needs selection.
Token exchange is one possible mechanism for issuing the specialist’s credential. The OAuth token exchange standard, RFC 8693, defines the exchange and subject/actor representation. The deployment decides which exchange is authorized and what the resulting token permits. Its nested actor claims record earlier actors, which are informational for access control. The token consumer uses the top-level claims and current actor when applying that policy.
The permitted read also needs a representation whose meaning the issuer and log service share. OAuth Rich Authorization Requests, RFC 9396, defines authorization_details, with fields interpreted according to the API’s authorization type. The standard explicitly leaves comparison of arbitrary authorization-detail requests to those semantics. A generic comparison of JSON objects cannot establish that a child request grants less access.
For our log API, a contained interval could be narrower access. An omitted user filter could mean every user, depending on the API. The issuer and receiver have to agree on those meanings before either can decide that a requested read fits the grant. Task binding, delegation depth and a shared task budget would be application-profile rules. Each needs an enforcement point that understands it.
When the specialist presents its credential at your log service, the receiver authenticates the presenter under the accepted identity/key-binding policy and validates the credential for the intended resource. The handler resolves the linked grant and verifies its caller, tenant and task associations. Using the agreed field meanings, it normalizes the requested user, interval and operation, then compares them with the grant’s limits. Before admitting the read, it checks current grant and approval status, verifies task access and reserves the required allowance.
After those checks, the approved user’s bounded read can proceed. A wildcard user or wider interval would be rejected unless new authority covers it. The service records the decision with the grant, approval and policy revisions and exact accepted arguments. Its executor uses that retained action. A later edit to the arguments requires another decision. This proposed behavior remains unverified.
Those checks only constrain reads that pass through them. If your specialist already has standing backend permissions, an unguarded endpoint accepting its broader credential would let it bypass the restriction. Your resource-facing checks have to cover those routes, or runtime isolation must prevent the alternate calls. Issuing a restricted credential leaves that coverage question open.
If the specialist asks another worker to perform the read, the issuer must apply the same permission comparison before granting that worker access. Under this proposal, further delegation requires permission in the approved plan. A requested child grant must remain within the permitted effects and recipients. An incoming message asking for another worker cannot change that ceiling.
To continue reading this article, please subscribe, it is free for all my subscribers.
Peace. Stay curious! End of transmission.
Fact-check appendix
Statement: The permitted read covers one user’s sign-in logs within a defined interval. | Source: Log-read example adapted from the illustrative scenario in the preceding article and the research brief. This is a proposed workflow, not a documented incident.
Statement: The OAuth token exchange standard, RFC 8693, defines the exchange and subject/actor representation. | Source: RFC 8693, sections 1 and 4. The approval-to-issuance flow and task constraints in the draft are proposed deployment choices.
Statement: Its nested actor claims record earlier actors, which are informational for access control. | Source: RFC 8693, section 4.1. That section restricts access-control consideration to top-level claims and the current actor.
Statement: OAuth Rich Authorization Requests, RFC 9396, defines
authorization_details, with fields interpreted according to the API’s authorization type. | Source: RFC 9396, sections 2 and 6.1. Generic permission comparison is not standardized.Statement: Pydantic AI’s deferred-tool documentation explicitly warns that client-submitted approvals do not replace authentication and authorization inside sensitive tools. | Source: Official deferred-tool documentation. This is the documented boundary for client-submitted histories/approvals, not a finding about every framework or deployment.
Statement: Its version 1.0.1 leaves the authorization model to the agent implementation. | Source: A2A v1.0.1 tagged source, section 13.1. The same section requires operation checks and caller-scoped results, including requests without context filters.
Statement: RFC 8693 states that exchange does not inherently create a continuing link between input and output tokens. | Source: RFC 8693, section 2.1. The stable root-status relationship and descendant checks described here are custom application policy for withdrawing the root grant for the delegated work. Selective intermediate-grant withdrawal remains a separate policy choice.
Statement: RFC 7009 acknowledges delay between servers learning about invalidation, and its treatment of related tokens depends partly on issuer policy. | Source: RFC 7009, section 2.1. The draft’s separate grant, identity and task responses are proposed integration policy.
Statement: RFC 7662 describes that tradeoff and forbids caching beyond a supplied expiration. | Source: RFC 7662, section 4. No cache duration or remote cancellation deadline is prescribed for this deployment.
Statement: The proposed accounting rule is that consumed allowance plus outstanding reservations stays within the approved limit. | Source: Author’s architectural proposal in 078-monograph.md. The server-side grant/credential linkage, retained execution arguments, root-status checks, outage rule, task binding, aggregate approval and correction behavior are likewise proposed. No measured enforcement result supports them.
References
OAuth 2.0 Token Exchange, RFC 8693, sections 1, 2.1 and 4.1: exchange semantics, subject/actor representation and token lifecycle relationships.
OAuth 2.0 Rich Authorization Requests, RFC 9396, sections 2 and 6.1: structured permission requests and API-defined comparison.
A2A v1.0.1 specification and tagged specification source, section 13.1: caller-scoped task operations and implementation responsibilities.
OAuth 2.0 Token Revocation, RFC 7009, section 2.1: withdrawal semantics, propagation limits and related-token policy.
OAuth 2.0 Token Introspection, RFC 7662, section 4: status queries, caching tradeoffs and expiration limits.
Pydantic AI: deferred tools, human-in-the-loop tool approval: authorization responsibilities when approvals are submitted by clients.
Who is calling? Establishing agent identity and trust: the preceding identity article in this series.
Securing agent delegation: what can we enforce?: the preceding delegation scenario.
078 research monograph: the proposed grant, approval, accounting and withdrawal design; research material without implementation results.
P.S. How AI was used in the creation of this piece:
The topic and direction are mine.
I supplied the voice guidance and editorial requirements.
AI helped with primary-source research and the argument’s structure.
AI generated an initial draft, and I directed revisions to its wording and reasoning.
I am responsible for validating the sources, technical claims and final wording before publication.