Agent identity
To PolicyArc, an agent is a client. It has its own client ID, it gets its own tokens, and every decision and audit row names it. Policy can treat two agents differently even when the same person runs both, because each one is a separate client.
How an agent gets a client ID
| How the agent registers | registration_type policy sees | Page |
|---|---|---|
It calls POST /register with no statement | DCR_PLAIN | Register a client |
It calls POST /register with a software statement from an issuer you trust | SOFTWARE_STATEMENT | Register with a software statement |
An operator creates it with POST /admin/api/clients | PRE_REGISTERED | Register a client |
| An MCP client such as Claude Code connects with a client ID metadata document | CIMD | Connect clients |
| A workload proves itself with a SPIFFE JWT-SVID | SPIFFE_SVID | SPIFFE workload identity |
What policy sees about the agent
Every decision gets the client in input.context.client.
| Field | What it holds |
|---|---|
client_id | The agent's client ID |
registration_type | One of the values in the table above |
client_type | confidential or public |
software_statement | The claims of the agent's software statement, or the grants an operator gave a pre-registered client. {} when there are none. |
A software statement can carry any claims its issuer chooses, such as the agent's vendor or a trust tier. Policy reads them there. Agent trust tiers shows a control that sorts agents by client ID instead, with the tiers in a data row you control.
Acting for a user or for itself
An agent that acts for a person signs them in. Claude Code connecting to the managed gateway is one. Its tokens come from the authorization code flow, and policy sees the person in input.subject. A decision can then depend on both, such as this agent for this person.
An agent that acts for itself uses client credentials. Its tokens have no user, and input.subject is null. Only the agent's own entitlements and the policy on its client decide what it gets.
When one agent hands work to another, the second agent can exchange the first one's token and record itself as the actor. Delegation and approval covers that, and when a person has to approve.
What the audit log records
Each audit row has a clientId and, when a user signed in, a subjectId. Search the log by clientId to see everything one agent asked for. Hold an agent's write for a person's approval ends with such a search.
Send feedback about this page