require_auth tells you who called SendMessage. It does not mean that subject may run every task the executor knows how to do. The sample stops once the subject is known and replies with subject:<id>.
What the card scope does
The agent card advertises scope agent:invoke on the Authdog security scheme. That is how a client discovers the scope to request. The sample middleware does not read that scope. It admits the call when userinfo accepts the bearer and the payload has a subject.
If a task needs a scope, check it in the executor after authdog_subject is on the request. Reject there, before the executor performs the task. A 401 from the middleware means "no accepted bearer." A later refusal means "this subject may not do this."
What to check next
The Agents registry is the next check on that subject when the caller is an agent:
| Control | Effect |
|---|---|
| Allowed scopes and tools | Globs on the trust-store row. * allows every tool. |
| Trust-store enforce | Your server applies that row. This A2A sample does not. |
| Revoke | New tokens fail when the subject is the OIDC client id. Tokens already issued last until expires_in unless you enforce the trust store. |
Apply authorization in the executor when the task is yours: a role, a policy, or an AuthZEN decision. The public skill on the card (whoami, "Returns the Authdog subject of the caller") describes the sample. It is not an allow list.
A 200 that contains subject: means userinfo accepted the bearer. Treat a missing subject, or a task the subject is not allowed to run, as a refusal the caller can see. Do not run the task and hide the denial inside a model reply.
Related
| Read | To learn how to |
|---|---|
| Custom channel auth for A2A | Put require_auth in front of the executor |
| Enriching instructions for A2A | Return the subject without leaking the token |
| Agents | Set allowed tools and revoke the identity |
| Authorization | Choose the check that runs after identity |