The A2A card is public. The model reply can include the subject. Neither one should include the access token or the client secret.
What the sample publishes
The card lists one skill:
| Field | Value |
|---|---|
| id | whoami |
| name | Who am I |
| description | Returns the Authdog subject of the caller. |
| tags | identity |
That description is discovery. Write it as if anyone can read /.well-known/agent-card.json, because they can. Leave issuer secrets, client secrets, and example bearer tokens off the card.
The executor replies with the text subject:<id> taken from request state. It does not look at the Authorization header, so the token is not in the message the caller gets back.
If you add a model
Pass authdog_subject into the task context the model is allowed to see. Ask it to use that subject and to stop when the executor refused the task.
Keep these out of the prompt, the skill description, and the message text:
AUTHDOG_CLIENT_SECRET- the raw access token
PK_AUTHDOG, which belongs on the server, not in a prompt
Instructions that say "you are whoever the user claims" undo the gate. The subject comes from require_auth. The model does not choose it.
Related
| Read | To learn how to |
|---|---|
| Authorizing tool calls for A2A | Refuse a task after the subject is known |
| A2A | See the executor return subject:<id> |
| API keys and M2M for A2A | Keep the secret on the client process |
| Agent Sign-In | Let an agent sign into your product UI |