Skip to main content
An agent signer is a per-user P-256 signing key, custodied in HSM-backed KMS, registered as an authorised signer on the user’s Safe smart account.

​
Why this exists

When an AI agent acts on a user’s behalf, the agent needs to produce a PINT signature that verifies as the user — without ever holding the user’s wallet key. The agent signer solves this by giving the user a second on-chain identity: a P-256 key that lives in Signing Services, is added as an owner on the user’s Safe, and produces signatures that verify through the Safe’s EIP-1271 isValidSignature path. The key never leaves the signing enclave. The user’s primary never signs an agent-initiated PINT. From a verifier’s point of view, the resulting JWT carries signer_type: "agent" but is otherwise indistinguishable from a user-signed credential — the same Safe, the same scopes, the same revocation surface.

​
Anatomy of an agent signer

Each user has one agent signer per chain. The record carries the cryptographic identity, the on-chain binding, and a lifecycle status.
FieldSourceDescription
key_idKMSShort name of the KMS key (agent-signer-{external_id}). The private half lives in HSM and never leaves.
curvep256Always P-256 (secp256r1). The default for new signers.
providergcp_kmsKey custodian. Today this is always Google Cloud KMS.
public_key_x, public_key_yKMSUncompressed P-256 public key coordinates, hex-encoded.
signer_contract_addressSigner Deployment WorkerAddress of the on-chain proxy that wraps the KMS-held P-256 key and exposes it as a Safe-compatible signer.
verifier_addressConstantAddress of the RIP-7212 precompile (0x0000000000000000000000000000000000000100) that the proxy calls to verify P-256 signatures on-chain.
chain_idProvisioningThe chain the signer proxy is deployed on. One signer per user per chain.
statusWorkflowLifecycle state — see below.

​
Lifecycle

The agent signer is provisioned automatically when the user finishes the prerequisite onboarding steps. The setup is a durable workflow because it spans a KMS write, an on-chain deployment, and a downstream Safe-creation trigger. The status field on the signer record reflects this state machine:
StatusMeaning
pendingInitial value; the workflow has not yet written the record.
key_createdThe KMS P-256 key exists; the signer proxy contract has not yet been deployed.
contract_deployedThe proxy contract is on-chain.
activeThe signer proxy is deployed and ready to be used as a Safe owner. The Safe creation workflow consumes this.
failedKMS write or on-chain deploy failed. The workflow leaves the record in this state and does not auto-retry.
A signer reaches active before the user’s Safe exists. The Safe-creation workflow then deploys the Safe with the signer proxy as its sole initial owner.

​
How the signer binds to a Safe

The KMS key cannot be a Safe owner directly — Safe owners must be Ethereum addresses, and a raw P-256 public key has no canonical address. The bridge is a small on-chain proxy contract:
  1. The Signer Deployment Worker deploys a proxy at a deterministic address derived from the P-256 public key coordinates.
  2. The proxy address is recorded as signer_contract_address on the agent signer record.
  3. When the Safe is created, the proxy address is added as the sole initial owner.
  4. When the Safe later receives a signature to verify, it calls isValidSignature on the proxy.
  5. The proxy reconstructs the P-256 verification call against the RIP-7212 precompile and returns the EIP-1271 magic value if the signature checks out.
This is what makes an agent-signed PINT verify as the user from a verifier’s perspective: the Safe is the verifyingContract, the Safe’s owner set authorises the signature, and EIP-1271 makes the contract-level verification observable to anyone reading the chain.

​
What signing actually looks like

Agent signing is initiated server-side during PINT exchange. You do not produce an agent signature in client code — that would defeat the custody model. Instead, your app submits an unsigned (or partially-prepared) PINT through the agent path and Signing Services produces the EIP-712 signature against the user’s bound key. For the verifier-facing signing flow (and a code example showing the EIP-712 hash agent and user signing share), see the Agent signing section of Signing a PINT.

​
Public exposure

The agent signer’s public material is intentionally narrow:
  • The signer proxy address appears in the user’s Safe owner set on-chain. Anyone reading the Safe sees it.
  • The P-256 public key coordinates are stored on the agent signer record so the proxy deployment is reproducible. They are not exposed through any partner-callable API today.
  • The private key never leaves KMS. There is no extract path.

​
Rotation, revocation, and scope

A few things are deliberately out of scope today and worth being explicit about:
  • Key rotation. Agent signing keys are not rotated as a routine operation. Rotation would require deploying a new signer proxy and updating the Safe owner set.
  • Per-signer revocation. There is no “revoke this agent signer” surface today. PINT-level revocation is the active control surface; revoking a PINT invalidates every JWT issued against it regardless of which signer produced the underlying signature.
  • Scope constraints on the signer. Scope enforcement happens on the PINT and via the scope registry, not on the signer. The agent signer can sign any well-formed PINT for its bound user; SIS enforces scope/tier rules at exchange and at verification.

​
See also