Operator pathway · foundation 02

The model is not the signer.

A payment-capable agent needs an identity that can be verified outside its own words. Signing turns delegated authority into an auditable request, but only if keys, scope, and revocation live outside model context.

Learning boundary. This lesson teaches an operating model. It is not a certification, security assessment, legal delegation, financial recommendation, or approval to use production funds.
Learning objective

Separate five identity controls.

By the end of this lesson, you should be able to inspect an agent signing design, identify where authority is bound to a specific agent and mandate, and explain why a prompt instruction is not an identity layer.

01 · Agent identifier

Which agent is acting?

Assign a stable identifier to the acting agent or service, not just the user session or application name. A signature with no distinct actor cannot support accountability.

02 · Key isolation

Where does signing material live?

Keep private keys and signing credentials outside model context and tool-visible scratchpads. The agent can request a signature; it should not be able to reveal or rewrite the signing material.

03 · Request binding

What exactly was authorized?

Bind the signature to destination, amount, asset, network, timestamp, nonce, and mandate reference so a valid signature cannot be replayed against a different action.

04 · Rotation policy

How does identity change safely?

Define key rotation before the first incident. If identity cannot be rotated without breaking the workflow, compromise recovery is only theoretical.

05 · Revocation owner

Who can stop the agent?

Name the human or system that can revoke signing authority and the condition that triggers it. A stop path without an owner is not a control.

Practice lab · evidence before confidence

Score an agent signing setup.

A purchasing agent calls a signing service after it decides to pay a vendor. The service signs any request from the application server. The private key is not in the model prompt, but the request contains only recipient and amount; it does not include a mandate identifier, nonce, expiry, or rotation policy. The team says revocation would be handled manually if needed.

  1. Score each dimension from 0: absent, 1: documented, or 2: tested.
  2. Name every claim that requires evidence before awarding a point.
  3. Identify which parts create replay or overbroad authority risk.
  4. Write the smallest safe next experiment.

Answer rationale

Key isolation may earn 1 if the signing service can be inspected, but not 2 without an exercised test. Agent identifier is weak because the application server is being trusted broadly rather than binding a specific agent and mandate. Request binding is 0 or 1 at best: recipient and amount are insufficient without nonce, expiry, asset, network, and mandate reference. Rotation and revocation are 0 while they remain manual assumptions with no owner, trigger, or measured procedure. The next step is to require a signed payload with mandate id, nonce, expiry, and allowlisted scope before any payment API accepts the request.

STOP → BIND

Continue the system