Agents
The agent is an identity of its own, registered in Xokepoint and verified on every call.
The agent is the software that decides which tools to call: an assistant, a copilot, an automation worker. In Xokepoint it has an identity of its own, separate from the subject it acts for.
A token issued by the customer IdP sometimes carries a client_id or an azp. That looks like enough to know which agent is calling, but these fields only say which application requested the token. They do not prove that the agent is authorized by the person to act for them. Xokepoint does not use these fields to decide access.
Two modes
An agent gets its Xokepoint token in one of two modes. One agent can use both, and the token says which one issued it (presence).
| Mode | Who runs the agent | How it gets a token | Presence |
|---|---|---|---|
| Headless | A service, with no person at the keyboard | It proves itself with its key and exchanges the subject token (Token exchange) | headless |
| Interactive | A person, from a coding harness such as Claude Code | The harness is identified by its client metadata URL, the person signs in with the company IdP and consents, and each login is a grant of one machine (Connect a coding harness) | interactive |
In the interactive mode, the harness is not the agent. The administrator creates the agent (for example "Claude Code — Developers"), with its tools and rules, and allows the client metadata URL of the harness for it. Each person who logs in is a grant of that agent, and the rules stay the same for all of them. The same harness can be allowed for several agents, chosen at login by the groups of the person.
The agent proves who it is
This section is the headless mode.
Each agent has a client registration in the Xokepoint authorization server, with a public key. The private key stays with the agent, and Xokepoint never receives it. To authenticate, the agent signs a short JWT, the client assertion, and the AS checks the signature with the registered key. This is the private_key_jwt method of RFC 7523. There is no shared secret that can leak from either side.
An agent has one key at a time: an EC P-256 key (ES256) or an RSA key of 2048 bits or more (RS256). The Admin can generate the pair in the browser, so the private key only ever exists in the file the administrator downloads, or register a public key that the customer already keeps in a vault. Replacing the key invalidates the old one at once. There is no overlap window: tokens already issued keep working until they expire, which takes at most 5 minutes.
The agent on every call
The token that the agent uses for tool calls carries the agent in the act claim, defined in RFC 8693. On every call the PEP checks that the agent still exists in the same workspace and environment and that its status is active. For a headless token, the agent must still have a key. For an interactive token, the grant of the machine and the consent of the person must still be active.
The status is the kill switch. Disabling an agent refuses its next token exchange, harness login or refresh and its next tool call, even with a token that still has minutes to live. Nothing else changes: delegations, permissions and the key stay as they were, so enabling the agent again restores it exactly. It is the fastest way to stop an agent that misbehaves while the team works out why.
The agent also has an enforcement mode. In Enforce, the default, every deny of its policy blocks the call. In Report-only, a deny of its policy (a tool without a grant, a resource outside the granted ones, a false call rule) lets the call run and is recorded as Would deny; delegation, the token, the identity connection, the kill switch and every evaluation error still block. Like the status, the mode is read at each call, so a change applies to the next call also with an unexpired token. Report-only shows how to use it.