Agent governance on Base: from trust scores to transaction limits

You gave your agent a Coinbase Agentic Wallet. It can hold USDC, execute trades, pay for API calls via x402. It operates on Base with sub-cent transaction costs and instant finality.

Now: who decides how much it can spend? What happens when it fails? How do you know what it did?

This post walks through the governance stack we built into Agency-OS for agents operating onchain. Every mechanism described here ships as a default — you don't opt in, you opt out.

The trust score system

Not all agents deserve the same permissions. A newly deployed agent should not have the same spending authority as one that has successfully completed 500 tasks.

Agency-OS implements a 3-tier trust system:

Tier	Trust score	Permissions
Restricted	0.0 – 0.3	Low spend caps, mandatory human approval for transactions above threshold
Standard	0.3 – 0.7	Normal spend caps, autonomous operation within limits
Trusted	0.7 – 1.0	Higher spend caps, can delegate to other agents, reduced approval requirements

Trust scores update on a rolling window of task history. Every completed task, every successful transaction, every governance interaction contributes to the score. Trust is earned through demonstrated behavior, not granted by configuration.

How it works for Base agents

When an agent with a wallet attempts a transaction:

The governance layer checks the agent's current trust tier
It validates the transaction amount against the tier's spend cap
If the amount exceeds the cap, it either blocks the transaction or routes it to human approval
The transaction, the governance decision, and the outcome are all logged to the audit trail

This happens before the transaction hits the blockchain. The governance check is a pre-flight gate, not a post-mortem.

Spend caps: three layers deep

Spend caps in Agency-OS operate at three levels:

Per-transaction limits — No single transaction can exceed a configured ceiling. For a restricted agent, this might be $1 USDC. For a trusted agent, $100. The limits are configurable per deployment.

Per-agent limits — Cumulative spend over a rolling time window. Even if every individual transaction is under the cap, an agent that's burning through funds at an abnormal rate gets flagged and frozen.

Per-tenant limits — The total budget allocated to all agents under a single tenant. This is the hard ceiling that protects against systemic failure — even if multiple agents are individually within their limits, the tenant-level cap prevents aggregate overspend.

Why three layers matter in DeFi

Consider a DeFi agent managing a yield strategy on Base:

Per-transaction catches a single bad trade (agent tries to swap entire balance into a low-liquidity pool)
Per-agent catches a runaway loop (agent rebalances every block, burning gas and slippage)
Per-tenant catches correlated failure (three agents all respond to the same market signal and try to exit simultaneously)

Single-layer spend caps miss two of these three failure modes. Most agent frameworks don't have any of them.

x402: governed payments over HTTP

The x402 protocol (Coinbase + Cloudflare) enables machine-to-machine payments over HTTP. When an agent calls a paid API, the server responds with HTTP 402 and a payment requirement. The agent pays in USDC on Base, then retries the request with proof of payment.

Agency-OS implements x402 natively in agency_os.wallet.x402:

from agency_os.wallet.x402 import X402Protocol

# x402 is governed by the same trust + spend cap infrastructure
protocol = X402Protocol(wallet=agent_wallet, audit_logger=audit)

# When the agent hits a 402, it checks governance before paying
response = await protocol.handle_payment_required(
    amount_usdc=Decimal("0.01"),
    recipient_address="0x...",
    network="base"
)

The key design decision: x402 payments flow through the same governance pipeline as every other transaction. The spend caps, trust tier checks, and circuit breakers all apply. An agent can't circumvent governance by paying for an API call any more than it can by executing a trade.

Every x402 payment generates an audit event:

class AuditEventType(str, Enum):
    PAYMENT_VERIFIED = "payment_verified"
    PAYMENT_REJECTED = "payment_rejected"
    TRANSACTION_SENT = "transaction_sent"
    TRANSACTION_FAILED = "transaction_failed"

You get a full trail of what your agent paid for, how much, to whom, and whether governance intervened.

Circuit breakers for onchain agents

Circuit breakers are the single most effective governance mechanism we've tested (81% welfare increase, d = 1.64 across 70 simulation runs). For onchain agents, they serve a specific function: automatic freeze on anomalous behavior.

The trigger conditions are configurable per trust tier:

Consecutive failures — N failed transactions in a row triggers a freeze
Spend velocity — spending above a threshold rate triggers review
Error patterns — repeated identical errors (e.g., revert on the same contract call) trigger investigation

When a circuit breaker fires:

The agent is frozen — no new transactions, no new task assignments
A notification is sent to the tenant (human operator)
The agent's status transitions to suspended
All pending transactions are held, not cancelled

The freeze is recoverable. A human reviews the situation, adjusts parameters if needed, and unfreezes the agent. The agent resumes with its trust score adjusted based on the incident.

The audit trail

Every governance decision, every transaction, every circuit breaker trigger is logged with:

Timestamp (UTC)
Agent ID
Wallet ID
Transaction hash (when applicable)
Amount
Network
Event type
Governance outcome (approved / rejected / escalated)

This isn't optional logging you enable for debugging. It's the default behavior. If your agent touched a wallet, there's a record.

For Base agents, this means you can reconstruct the full decision chain: why the agent attempted a transaction, whether governance approved it, what the onchain result was, and how it affected the agent's trust score.

Putting it together

Here's the full governance flow for an onchain agent on Base:

Agent receives task
  → Evaluates strategy (may involve trade, payment, or API call)
  → Governance pre-flight:
      ✓ Check trust tier
      ✓ Check per-transaction spend cap
      ✓ Check per-agent cumulative spend
      ✓ Check per-tenant budget
      ✓ Check circuit breaker status
  → If all pass: execute transaction on Base
  → If any fail: block, escalate, or request human approval
  → Log audit event regardless of outcome
  → Update trust score based on result

Every agent, every transaction, every time. The governance layer doesn't care whether the agent is trading on Uniswap, paying for an API via x402, or sending USDC to another agent. The same pipeline applies.

Get started

Agency-OS is open source. The governance stack described here ships as default infrastructure — no enterprise tier, no feature flags.

pip install agency-os

Repo: github.com/swarm-ai-safety/agency-os

If you're building agents on Base and want governance that works before your first transaction, not after your first incident, this is what we built.

All governance mechanisms are backed by published simulation research. 146 runs, 43 agent types, 27 configurations. Reproducible.