> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sumvin.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent signers
> How an agent-signed Stamped Mandate verifies as the user, and what it looks like to a verifier.
An **agent signer** is a per-user P-256 key that Sumvin holds in KMS and registers as an authorised owner on the user's [Safe](/concepts/safes-and-identity), so an AI agent can sign a Stamped Mandate on the user's behalf. The user's wallet key is never exposed. A Stamped Mandate is delivered over the API as a `PINT` (header `x-sumvin-pint-token`).
## Agent signers and other Safe owners
An agent signer is not the only key that can own a Safe. A **CLI mandate key** is an externally owned account the Sumvin CLI generates and keeps on the developer's own machine, registered as an owner on the same Safe so that mandates signed locally still verify as the user. The two are different things, and the vocabulary is kept separate on purpose.
| | Agent signer | CLI mandate key |
| -------------------- | --------------------------------------------------------------------- | --------------------------------------------------------- |
| Key custody | Google Cloud KMS — the private half never leaves the HSM | The developer's machine, held by the CLI |
| Key type | P-256, reached on chain through a signer proxy contract | An externally owned account |
| Who signs with it | Sumvin's backend agent, on the user's behalf | The developer, locally |
| When it appears | Provisioned once per user per chain during onboarding | Registered on request, against a Safe that already exists |
| Where it is recorded | An agent signer record on the user | An address on the account, carrying a signer role |
| Status values | `key_created`, `active`, `failed` — see [below](#agent-signer-status) | `pending`, `active`, `failed` |
Both sit in the Safe's owner set on chain, and a mandate signed by either verifies as the user through the Safe's EIP-1271 path. What distinguishes them on a given mandate is its scopes: `sr:us:pint:cli:delegate_sign` marks a mandate the developer signed locally, and `sr:us:pint:cli:add_signer` marks one the agent signer produced to add to the Safe's owner set. Token exchange refuses any mandate whose marker disagrees with who signed it — see [Scopes](/identity/scopes#cli).
The two status vocabularies overlap but do not mean the same thing, and no API returns one where the other is expected. `key_created` describes an agent signer's key material and has no counterpart on a CLI mandate key, whose status tracks only whether the owner-add has landed on chain.
## What a verifier sees
An agent-signed Stamped Mandate **verifies as the user** through the Safe's [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) `isValidSignature` path. To a verifier it is otherwise indistinguishable from a user-signed mandate — the same Safe, the same scopes, the same revocation surface. The only difference is that the JWT carries `signer_type: "agent"`.
| Field | Source | Description |
| ------------------------------ | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `key_id` | KMS | Short name of the KMS key (`agent-signer-{external_id}`). The private half lives in HSM and never leaves. |
| `curve` | Constant | Always `p256`. |
| `provider` | Constant | Key custodian. Today this is always `gcp_kms`. |
| `public_key_x`, `public_key_y` | KMS | Uncompressed P-256 public key coordinates, hex-encoded. |
| `signer_contract_address` | Signer Deployment Worker | Address of the on-chain proxy that wraps the KMS-held P-256 key and exposes it as a Safe-compatible signer. |
| `verifier_address` | Constant | Address of the [RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md) precompile (`0x0000000000000000000000000000000000000100`) that the proxy calls to verify P-256 signatures on-chain. |
| `chain_id` | Provisioning | The chain the signer proxy is deployed on. One signer per user per chain. |
| `status` | Provisioning | Lifecycle state — see below. |
### Agent signer status
| Status | Meaning |
| ------------- | --------------------------------------------------------------------------------------------------------------- |
| `key_created` | The record's first state. The KMS P-256 key exists; the signer proxy contract has not yet been deployed. |
| `active` | The signer proxy is deployed and the signer is ready to be used as a Safe owner. Safe creation consumes this. |
| `failed` | The KMS write or the on-chain deploy failed. The record is left in this state and is not retried automatically. |
Treat any value other than `active` as not ready to sign. The field is also defined with `pending` and `contract_deployed`, which no provisioning path writes today; a signer that has not yet reached `active` reports `key_created`.
## See also
* [Signing a Stamped Mandate](/identity/signing#agent-signing-p-256) — the agent signing flow
* [Verify a PINT signature](/merchant/verify-pint-signature) — on-chain signature verification
* [Revocation](/merchant/revocation) — invalidating a mandate and every JWT issued against it