StableOps
FAQ

Does the Agent or StableOps get access to my wallet key?

Understand where payment keys and credentials run, what the signer can authorize, and why the Agent runtime never needs unrestricted wallet access.

No. The Agent runtime does not receive the wallet private key, and StableOps does not custody it. A customer-hosted signer keeps the private key or AWS KMS signing permission inside your environment and signs only payment data that exactly matches a short-lived StableOps execution grant.

The trust boundary

The payment path deliberately separates four kinds of authority:

Secret or permissionWhere it belongsWhat it can do
Management API KeyTrusted operator serviceConfigure Agents, wallets, policies, budgets, and read operational records
Agent KeyOne server-side Agent runtimeRead that Agent's budget and create, resume, or inspect only its own payment Intents
Sidecar TokenAgent runtime and its local signer connectionAuthenticate a call to the constrained signer endpoint
Wallet private key or KMS permissionCustomer-hosted signer onlySign the exact authorized payment after validating the execution grant

Do not put any of these credentials in a Prompt, browser bundle, source repository, analytics payload, or application log. The Agent Key plaintext is returned only when the key is created; if it is lost, revoke it and issue a replacement.

What StableOps receives

Wallet registration proves that you control an address by asking trusted operator code to sign a one-time pairing challenge. StableOps verifies the signature and records the public address, network, signer type, and wallet binding. The private key does not leave your environment.

For a payment, the control plane evaluates the resource origin, recipient, network, asset, amount, policy, and budgets. It then issues a short-lived execution grant bound to those exact fields. StableOps does not:

  • receive or store the wallet private key;
  • expose a general wallet-signing API to the Agent;
  • proxy the paid business request or read its response body; or
  • broadcast the supported x402 payment transaction.

The x402 Facilitator verifies and submits the supported payment, while StableOps tracks authorization, resource outcome, and settlement evidence for reconciliation.

What the signer accepts

The signer validates the grant issuer and then checks the Agent, wallet, environment, network, asset contract, recipient, amount, nonce, and validity window. A mismatch, expired grant, unknown issuer key, or replay conflict is rejected before the wallet key is used.

Its signing endpoint accepts only StableOps execution grants. It cannot sign arbitrary messages, arbitrary typed data, wallet-pairing challenges, or general transactions. Do not add a generic signing method as a convenience wrapper around the same key.

For Sandbox EVM testing, LocalTestSigner holds a local test key. For Live EVM payments, AwsKmsSigner asks AWS KMS to sign without exporting the private key. Solana uses a customer-hosted LocalSvmSigner. The current combinations are listed in the supported scope.

If a credential is exposed

The response depends on which boundary was compromised:

  • Agent Key: pause the Agent, revoke the key, inspect its recent Intents and audit history, then issue a replacement only after the runtime is clean. Revoking an Agent Key does not require moving the wallet.
  • Sidecar Token: stop access to the signer, rotate the token, inspect its durable authorization records, and verify that the signer remained bound to loopback.
  • Wallet key or KMS signing permission: treat this as a wallet incident. Disable or remove the wallet binding, restrict the KMS policy or key, inspect onchain activity, and follow your treasury recovery procedure.

Pausing or revoking prevents new work at that credential boundary. It cannot retract a short-lived authorization that may already have been submitted, so continue reconciling every outstanding Intent.

How is this guide?

Last updated

On this page