The AI Handed Work to Another Agent. Did Its Authority Travel Too?

By Jared Mastroianni

• October 18, 2026
• 52
• Business Storage, Guides, Self Storage

Agent-to-agent delegation needs an explicit operating review: the child receives a bounded task, not a copy of every upstream credential and permission.

A portfolio AI agent is asked to compare unresolved gate alerts across three self-storage facilities. It delegates the maintenance analysis to a specialist agent. The specialist discovers an open vendor-scheduling tool and a portfolio service credential in its environment. It could book a technician. The parent wanted analysis, however, not dispatch.

This is where multi-agent architecture can turn a sensible division of labor into an authority failure. The task moved. The authority did not necessarily move with it.

An agent can receive enough context to investigate a question without receiving permission to change a work order, contact a vendor, alter access, message a customer, or expose data from another facility. Treating delegation as an automatic transfer of credentials, approvals, and business authority collapses distinctions that operators depend on.

The safer rule is direct: delegate the task through a narrower authority envelope, then require a return receipt that proves what the child agent did, did not do, and still needs.

A task and an authorization are different objects

Multi-agent systems usually make task movement visible. A parent task creates a child task; the child reports a status; an artifact comes back. That is useful orchestration. It is not enough governance.

The A2A Protocol specification, for example, defines a task as a stateful unit of work with a unique identifier and an artifact as an output generated from a task.[^1] It also defines an interrupted TASK_STATE_AUTH_REQUIRED state when authentication is needed to continue.[^2] Those mechanics give architects a useful vocabulary. They do not decide whether a particular self-storage action is authorized.

An operator still needs separate answers to five questions:

1. Who initiated the parent task?
2. Which agent is performing this child task?
3. What data may the child inspect?
4. What operations may it attempt?
5. What must return to a human, governing system, or parent agent before work can continue?

If those answers live only in natural-language instructions, they are too easy to broaden, lose, or reinterpret. Put them in a machine-enforced delegation record.

Build a delegation envelope, not a copied session

The delegation envelope should be a first-class control object. It binds one child task to one purpose, one resource boundary, one time window, and one permitted result.

At minimum, record:

• parent task, child task, and context identifiers;
• initiating subject, parent actor, and child-agent identities;
• exact portfolio, facility, account, asset, and tenant boundary;
• stated purpose and consequence class;
• source references and evidence cutoff time;
• data the child may receive and data it must not receive;
• allowed operations and prohibited operations;
• tool allowlist and exact resource scope;
• audience and destination for the result;
• authorization basis, scope, issue time, and expiration;
• maximum delegation depth;
• expected artifact and return schema;
• authorization-request, failure, and handback conditions; and
• the correction or revocation reference.

The envelope should be evaluated by infrastructure before the child runs and again before each consequential tool call. A prompt that says “read only” is not a permission boundary if the child still holds a credential that can write.

OWASP’s current AI security guidance applies the same principle to oversight: risk-tier agent actions, place approval checkpoints in infrastructure rather than model instructions, and bind high-risk approval signals to the specific parameters and expiration.[^3] That guidance is not a self-storage standard. Its architectural value is that the agent cannot talk its way around a control the runtime enforces.

Attenuate authority instead of cloning it

The child should receive the least authority needed to produce the expected artifact. Do not clone the parent’s session, credential set, data window, or portfolio reach.

For a gate-alert comparison, the child may need:

• three stable facility IDs;
• the named gate asset at each property;
• time-bounded alert summaries;
• current work-order status; and
• an approved taxonomy for comparing unresolved conditions.

It may not need tenant names, payment history, unit contents, administrator credentials, customer-message tools, or authority to schedule service. Keeping those fields out of context reduces both exposure and semantic confusion. The child cannot accidentally use a detail it never received.

OAuth token exchange offers a relevant implementation analogy. RFC 8693 distinguishes a subject token from an actor token and supports audience and target-resource parameters.[^4] An authorization server can reject an invalid subject or actor token or a target it will not serve. That can help issue a narrower, audience-bound credential for a downstream service.

But a token is not the whole operating decision. RFC 8693 does not determine whether a maintenance agent should contact a gate vendor, whether an approval is still current, or whether a facility manager may authorize the expense. The application must bind technical scope to the operator’s policy and retain the actor chain.

Make “authorization required” a valid result

A child agent will sometimes discover that the next useful step sits outside its envelope. The correct result is not improvisation. It is an explicit authorization request.

The request should state:

• the blocked operation;
• the target resource and facility;
• why it appears necessary;
• the evidence supporting the request;
• the exact additional scope sought;
• the consequence and reversibility class;
• the qualified decision owner;
• what will happen if the request is denied or expires; and
• whether any side effect has already occurred.

The A2A specification’s in-task authorization pattern is helpful here. It permits an agent to interrupt a task, explain the required authorization, and let the client negotiate, correct, reject, or fulfill the request.[^2] It also warns that passing credentials through chains of agents can expose those credentials and recommends binding credentials to the agent that originated the request.

For an operator, the important behavior is the stop. The child returns authorization_required; the parent does not silently substitute a broader credential; and the authorization owner receives a bounded question instead of an open-ended request to “let the agent finish.”

A returned artifact is not proof of an operational effect

Suppose the child returns a comparison table with three gate-alert cases. The artifact may be complete even though no work order changed and no vendor was contacted. That distinction should remain visible.

The parent should validate:

• child-task identity and terminal state;
• artifact type and schema version;
• artifact hash and storage reference;
• source references and evidence cutoff;
• child-agent and model/build identity;
• tools called and resources addressed;
• authorization requests or rejected calls;
• provider receipts, if any;
• governing readbacks, if any; and
• unresolved limitations.

Then classify the return. Useful dispositions include analysis_accepted, authorization_required, rejected_scope, failed_no_effect, side_effect_unverified, and reconciliation_required.

Do not let completed carry more meaning than it has. It can mean the child finished its assigned analysis. It does not prove the facility condition, vendor acceptance, customer notification, safe operation, or a change in the governing system.

Preserve the actor chain without forwarding the whole conversation

Auditability does not require copying every parent message and every sensitive record into the child context. It requires a controlled chain of references.

The parent should retain the initiating subject, parent actor, authorizer, delegation ID, child actor, artifact identity, and return disposition. The child should receive only the references and claims needed for its job. Sensitive source records can remain behind approved retrieval interfaces that recheck facility, tenant, audience, and purpose on every call.

NIST SP 800-53 Revision 5.1 is a broad, customizable catalog of security and privacy controls, not an agent protocol. Its least-privilege, access-control, and accountability concepts are still useful design constraints for processes acting on behalf of users.[^5] The portfolio implementation has to translate those concepts into exact facilities, actions, data classes, and approval paths.

This approach also helps with correction. If a source record changes, the operator can identify which child artifacts depended on it without searching an undifferentiated transcript. The correction link can invalidate a pending artifact, trigger re-analysis, or warn a reviewer that the evidence cutoff is no longer current.

Limit delegation depth and lifetime

An agent chain should not expand indefinitely. Every delegation adds another place where context, policy, credentials, and state can drift.

Set a maximum depth and require each child to create a still-narrower envelope before it delegates again. The grandchild must not inherit the union of every upstream permission. It should receive the intersection of:

• the original authorized purpose;
• the parent’s remaining authority;
• the new subtask’s minimum need;
• the target service’s accepted scope; and
• the current policy at call time.

Add an expiration short enough to match the work. Recheck authorization if the facility, source, policy, actor, model, tool contract, requested operation, or consequence class changes. Revocation should stop new calls and mark unfinished child work for reconciliation. Do not assume that canceling a parent task reversed a side effect a child may already have produced.

A fictional portfolio example

The following scenario and all names, records, identifiers, times, and results are fictional teaching material.

At Cinder Vale Storage Group, a portfolio coordination agent receives parent task CV-P-104: compare unresolved gate alerts at CV-011, CV-024, and CV-037 before the regional maintenance review.

It creates child task CV-C-104A for a maintenance-analysis agent. The delegation envelope permits read-only retrieval of the three facility IDs, named gate assets, alert summaries from the prior 24 hours, and governing work-order states. It prohibits customer data, credential material, access changes, vendor contact, alert-rule changes, and work-order writes. The expected artifact is a structured comparison with source references and unresolved conditions.

The child finds that CV-024 has a repeated controller-disconnect alert and an open work order. It also detects an available vendor-scheduling tool. Because scheduling is outside the envelope, it returns authorization_required with the facility, asset, evidence references, proposed operation, requested scope, qualified owner, and expiration. It does not call the vendor.

For CV-011 and CV-037, it completes the read-only comparison and returns artifact CV-A-104A, its SHA-256 hash, the evidence cutoff, two read-only tool receipts, and side_effect_claim=none. The parent verifies the schema and references, then marks the artifact analysis_accepted. The separate scheduling question remains unresolved.

A second proposed child task is rejected before execution because it requests a portfolio administrator credential and full customer histories. Those inputs are unnecessary for the stated purpose. The rejected request remains in the delegation register so the design team can correct the planner.

Nothing in the scenario establishes a real facility event, system capability, vendor interaction, deployment, performance result, or business outcome.

Use the receipt as an operating test

The accompanying Agent Delegation and Return Receipt turns the architecture into a reviewable record. The template and fictional example force the team to show both sides of the exchange: what the parent granted and what the child returned.

Before release, test at least these cases:

1. The child attempts a tool outside the allowlist.
2. The child asks for a different facility.
3. The evidence cutoff expires during execution.
4. A source correction arrives before return.
5. A credential is technically valid but has the wrong audience.
6. The child requests authorization for a consequential action.
7. The parent is canceled after a child side effect.
8. The child returns an artifact with an unknown schema.
9. A grandchild would exceed maximum delegation depth.
10. The child reports completion without a governing readback.

The expected outcome is not that every task completes. It is that the system refuses unsupported authority, records the reason, and returns enough evidence for the next legitimate decision.

Multi-agent architecture should make specialization safer, not make accountability harder to find. When work passes from one agent to another, move only the purpose, evidence, data, and authority that the child actually needs. Everything else stays behind the boundary.

The return receipt closes the loop: this was the task, this was the authority, this was the actor, this was the artifact, these were the side effects, and this is what remains unresolved.

Editorial disclosure and claim boundary: This article was prepared with AI-assisted research, drafting, and editorial QA under Jared Mastroianni’s byline. It proposes a product-neutral architecture and reports no customer, facility, agent, system, vendor, deployment, capability, certification, performance, revenue, occupancy, safety, legal-compliance, award, coverage, or recognition result. The Cinder Vale scenario and all accompanying data are explicitly fictional. Operators must apply their own current policies, access controls, privacy and security review, contracts, system documentation, qualified technical judgment, and applicable law.

[^1]: A2A Protocol, Specification v1.0.0, core concepts for tasks and artifacts; accessed October 8, 2026.
[^2]: A2A Protocol, Specification v1.0.0, task states and in-task authorization; accessed October 8, 2026.
[^3]: OWASP AI Exchange, General Controls, least-model-privilege and human-oversight guidance; accessed October 8, 2026.
[^4]: Internet Engineering Task Force, RFC 8693: OAuth 2.0 Token Exchange, January 2020; accessed October 8, 2026.
[^5]: National Institute of Standards and Technology, SP 800-53 Rev. 5, Update 1, security and privacy control catalog; accessed October 8, 2026.