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](/docs/ai/a2a/authorize-tool-calls) | Refuse a task after the subject is known |
| [A2A](/docs/agent-frameworks/a2a) | See the executor return `subject:<id>` |
| [API keys and M2M for A2A](/docs/ai/a2a/api-keys-and-m2m) | Keep the secret on the client process |
| [Agent Sign-In](/docs/agent-sign-in) | Let an agent sign into your product UI |