Workspace/Lesson workspace
Loading progress
Acting & collaborating40 min

Authenticate collaborators and contain delegated authority

Lesson 3 of 3
How to study this lesson

Read one section, trace the worked example, and try the knowledge check. Bookmark saves a shortcut; notes appear in My notebook. Mark lesson complete is your own assessment and does not mark its lab passed.

By the end, you can

  • Separate transport authentication from task authorization.
  • Constrain delegated data and credentials.
  • Design safe retry and audit behavior across agent boundaries.

An agent identity is not the human identity

A request to a remote agent can involve several principals: the human requester, the local application, the client agent, and the remote service. Authentication establishes which principal presented a credential. Authorization decides which task and data that principal may access. A service credential proving that your application is trusted does not automatically authorize every human using that application to read every report.

Carry the minimum identity context required by the remote contract and retain a local mapping to the initiating user and tenant. Avoid trusting a user identifier inside a model-generated message as proof of identity. The authorization layer should obtain identity from a verified session or token context. This matters when two users share an agent backend: correct task identifiers and valid protocol messages are insufficient if the backend does not enforce ownership on status and artifact retrieval.

Acquire credentials through the declared scheme

A2A uses declared security schemes and conventional authentication mechanisms; credential acquisition occurs through processes outside the protocol, such as OAuth or secure key distribution. Credentials are transmitted through the required authentication channel, not hidden inside conversational task text. [A2A enterprise features](https://a2a-protocol.org/latest/topics/enterprise-ready/). Read the card's requirements, then apply the approved authentication configuration for that service.

Do not forward the caller's original token to every downstream agent. A token may be intended for a different audience or carry broader permissions than the delegated task needs. Use a credential appropriate to the target service and permitted scope. Store secret references separately from model context and redact them from traces. If authorization expires during a task, preserve progress and surface the authentication requirement rather than inventing a new credential path or broadening access automatically.

Delegate a bounded package of work

Construct a delegation envelope containing the objective, approved input artifacts, output contract, permitted operation categories, budget, and deadline. The remote agent may have powerful tools, but the client should send only the data needed for this assignment. A request to summarize one incident does not require an entire workspace export. Data minimization also reduces confusion by removing unrelated context from the remote reasoning problem.

Suppose a remote analyst can read sales data and a remote publisher can post reports. Give the analyst a bounded dataset and ask for an artifact. Have the local coordinator review and authorize the publication separately. This arrangement narrows the authority of each step and makes effects attributable. A protocol can transport requests between these services, but it does not decide that the analyst should inherit the publisher's authority merely because both participate in one task graph.

Retry according to operation semantics

HTTP method semantics help distinguish operations intended to be idempotent from those that may create new effects. RFC 9110 cautions against automatically retrying non-idempotent requests without knowledge that doing so is safe. [HTTP Semantics, RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html). A network timeout leaves uncertainty about whether the remote service accepted work; it is not evidence that nothing happened.

Use the remote service's supported request identity or task lookup mechanism to reconcile uncertain submissions. Keep a local record linking the logical delegation to any discovered remote task. If a service offers no way to deduplicate or query an uncertain creation, expose that limitation and choose a conservative recovery policy. A random new request ID on every retry may improve log uniqueness while making duplicate task creation more likely. Logical operation identity and transport attempt identity should be separate fields.

Audit boundaries instead of private reasoning

A useful audit trail records who requested the task, which approved service received it, which data references were sent, what authorization was checked, and which artifacts or effects resulted. It does not require collecting a remote model's hidden reasoning or private prompts. Evidence at the boundary is usually more actionable: request fingerprints, task transitions, schema validation results, and explicit uncertainty about external effects.

Test cross-tenant access denial, expired credentials, unsupported scopes, changed Agent Cards, and timeouts after acceptance. Include a remote artifact containing instructions that conflict with the user request; treat it as data to inspect, not a new source of authority. Successful interoperability means that independently operated systems can exchange work while each boundary retains its own controls and observable contract. It does not mean merging their trust domains into one unrestricted conversation.

Work through the code

This teaching simulation intersects a local service policy with supplied credential scopes and tenant access. It does not validate tokens, implement OAuth, or establish a production authorization system. A real verifier must authenticate issuer, audience, expiry, and relevant claims before this policy check.

m18_lesson3.py
python
policy = {
    'reporter': {'scopes': {'report:read'}, 'tenants': {'A'}},
    'publisher': {'scopes': {'report:publish'}, 'tenants': {'A'}},
}

def authorize(agent, tenant, required_scope, credential_scopes):
    grant = policy.get(agent)
    if grant is None:
        return False
    return (tenant in grant['tenants']
            and required_scope in grant['scopes']
            and required_scope in credential_scopes)

cases = [
    ('reporter', 'A', 'report:read', {'report:read'}),
    ('reporter', 'B', 'report:read', {'report:read'}),
    ('reporter', 'A', 'report:publish', {'report:publish'}),
]
for agent, tenant, scope, token_scopes in cases:
    print(agent, tenant, scope,
          authorize(agent, tenant, scope, token_scopes))
EXPECTED / ILLUSTRATIVE OUTPUT
reporter A report:read True
reporter B report:read False
reporter A report:publish False

Run Python snippets locally with the prerequisites named above. The module coding lab runs directly in your browser.

Pause and reason

A credential has report:publish, but the approved reporter service policy allows only report:read. Should publication proceed?

Check your understanding

A timeout occurs while creating a remote task. What does the timeout prove?

Your notes

Explain the mechanism in your own words. Add a failure you want to test.

Saved notes appear in your notebook

Go deeper with primary sources

Practice this module