The shared credential problem
Today's AI agents typically get access to paid services the same way a developer does: an API key in an environment variable, a shared billing account, or a service account attached to the company's credit card. This works fine for a single agent running one task. It breaks down quickly as your agent infrastructure scales.
Consider what happens when you have ten agents running in parallel — a research agent, a trading agent, a customer service agent, a code review agent. They all share the same billing account. One misbehaving agent can exhaust the budget for all of them. You have no per-agent spending visibility. You can't rotate one agent's credentials without rotating them all. And if you want to grant a sub-agent access to a specific paid service, you have no way to scope that access.
| Shared credentials | Agent-owned wallet |
|---|---|
| One agent can spend the entire budget | Per-agent spending limits enforced at the protocol level |
| No per-agent audit trail | Every payment cryptographically linked to the agent identity |
| Credential rotation affects all agents | Each agent's wallet is independently managed |
| Can't scope access to specific services | Spending policies whitelist allowed recipients and amounts |
| Custodial: the API key is the credential | Non-custodial: agent controls its own wallet address |
What an agent wallet actually is
An agent wallet in Proco is a non-custodial wallet address deterministically derived from an agent ID — a cryptographic identifier that represents the agent's identity independent of any particular session or deployment. The agent signs payment authorizations with its private key; Proco validates the signature and executes settlement.
This is meaningfully different from an API key. An API key is a bearer token: whoever holds it can spend. A wallet address is an identity: only the agent holding the private key can authorize payments. You can publish an agent's wallet address publicly without enabling anyone to spend from it.
Non-custodial by design: Proco never holds your agents' private keys. Keys are generated locally and stored in your environment. Proco provides the payment infrastructure — validation, settlement, policy enforcement — but has no ability to move funds without an agent-signed authorization.
Setting up an agent wallet
Provisioning a wallet for a new agent takes three lines:
Defining spending policies
Spending policies are the guardrails that make agent autonomy safe. They're evaluated locally before any payment request reaches the network, so they can't be bypassed by a compromised agent attempting to spend beyond its limits:
Topping up an agent's balance
Agents receive funds via transfer from your treasury account. You can set up automatic top-ups triggered when the balance falls below a threshold, or fund manually from your dashboard:
Audit trail and observability
Every payment made by an agent is recorded with the agent ID, wallet address, recipient, amount, purpose memo, and a cryptographic receipt. Your dashboard gives you per-agent spend breakdowns, policy violation alerts, and a full transaction history you can export for accounting.
When something goes wrong — an agent spending more than expected, a payment to an unexpected recipient — you have the data to investigate. The audit trail is immutable and doesn't depend on your own logging infrastructure working correctly.
What to read next
- x402 Explained — the HTTP protocol that lets agents pay for APIs natively
- Agent-to-Agent Payments — the orchestrator pattern for multi-agent pipelines
- Wallet provisioning reference — full SDK docs for agent identity and policy setup