Agent as HTTP resource / tool provider

Others call your agent. You are the resource server: publish how to authorize, then enforce it on every request. RFC 9728, an OAuth-protected resource, A2A Agent Card security schemes, or AAuth resource-managed if you run consent yourself.

When you see it

You shipped an HTTP API that is 'the agent.' You host an MCP server. You publish an A2A Agent Card so other agents can assign you tasks. Callers are other products, other agents, or a mesh sidecar — you do not get to assume a browser on their side.

Actors and trust

Calling agent / clientAgent instance
Must obtain whatever your metadata advertised. May be an OAuth client, an AAuth signer, or a mesh workload.
Your agent (resource)Resource
Publishes PRM and/or an Agent Card. Verifies the advertised scheme on the request. Signed Agent Cards prove the card was not tampered with; they do not authenticate the request.
Optional authorization serverOther
Present if you are an OAuth-protected resource. Absent if you are AAuth resource-managed and issue your own session.

Topology

Calling agentAgent Card / RFC 9728Optional ASYour agent (RS)

Calling agent→ GET well-known metadata →Agent Card / RFC 9728
Calling agent→ If the card/PRM says OAuth, obtain a token →Optional AS
Calling agent→ Authenticated task or API request →Your agent (RS)

Callers discover your advertised scheme (PRM or Agent Card), obtain credentials, then call you. You are the RS.

Primary

Protected Resource Metadata
RFC 9728.
OAuth 2.1
You are an OAuth-protected resource unless you chose AAuth instead.
A2A (Agent2Agent)
If you speak A2A, securitySchemes on the Agent Card are the advertisement.

Optional

AAuthdraft / churn
Resource-managed two-party: you run consent and issue a session. Individual draft.
mTLS sender-constrained tokens
SPIFFE / SPIRE
If callers are mesh workloads in your trust domain.
MCP authorization
If the thing you host is specifically an MCP server.

Do not use

Bearer tokens
API keys / unconstrained Bearer as the only scheme. Last resort, not a design.
Signed Agent Card as request authentication
Card JWS is tamper evidence for the card. Still require a request-level scheme.

Why these, and not those

The caller needs a machine-readable answer to 'how do I authenticate to you?' RFC 9728 is that answer in OAuth. A2A puts the same idea on the Agent Card as securitySchemes (OAuth, OIDC, mTLS, API key). If you do not want an AS, AAuth two-party / resource-managed lets you run your own interaction and issue an opaque session bound to the caller's key. Do not treat a signed Agent Card as request authentication. Do not make API keys the primary scheme if you can avoid it.

Related flows

Sequence diagrams, not this topology cut. All flows