Security Model
Five layers of control between an autonomous agent and your funds. Each layer fails safely without relying on the one below it.
Layer 1 — On-chain policy enforcement
Spending rules are enforced by the ClawdGo Solana program at the smart contract level. When an agent submits a transfer, the ClawdGo program validates the transfer against the policy state stored in the account's PDA before executing the SPL token instruction.
What this means in practice: a compromised ClawdGo API server, a rogue employee, or a configuration error cannot override on-chain spending limits. The program will reject the transaction regardless of what the API layer believes.
max_single_transfer: 500, that value is written to the PDA on Solana, not just stored in PostgreSQL. The API reads from the PDA to validate — the database is a cache and audit log, not the source of truth for policy enforcement.
Layer 2 — API key scoping
Agent API keys are scoped to a single account. A key issued for account acct_01j8... cannot read or write any other account — not other accounts belonging to the same operator, not other operators' accounts. The scoping is enforced server-side and cannot be overridden by the caller.
What this means in practice: a leaked agent API key is bounded damage. The attacker can only operate within the already-constrained policy of that single account.
Layer 3 — Operator multisig for high-value policy changes
Raising spending limits, removing counterparty restrictions, or performing other high-risk policy changes requires operator authentication via a separate auth flow (OAuth2 + MFA). Batch policy changes above a configurable threshold require a second operator confirmation.
This prevents a single compromised operator credential from instantly expanding agent spending power.
Layer 4 — Human pause switch
Operators can freeze any account immediately by setting paused: true in the spending policy. The pause takes effect for all subsequent transfer requests — no pending queue to drain, no in-flight transactions to wait for.
The pause flag is checked server-side before any transaction is signed or submitted to Solana. A paused account produces no on-chain activity.
# Emergency pause — one API call, instant effect
curl -X PUT https://api.clawdgo.com/v1/accounts/acct_01j8k4x9p2qrst7yz/policy \
-H "Authorization: Bearer $OPERATOR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"paused": true}'Layer 5 — Idempotency keys
Every transfer requires a unique idempotency key. This prevents:
- Duplicate submissions — a retry of the same transfer does not execute twice
- Replay attacks — a captured request cannot be re-submitted to produce a second payment
- Agent loop bugs — an agent caught in a retry loop will not drain the account
Audit trail
Every event in the ClawdGo system is logged immutably:
| Event type | Where it's stored |
|---|---|
| Settled transfers | Solana blockchain (permanent, public) + PostgreSQL |
| Policy rejections | PostgreSQL append-only audit log |
| Policy changes | PostgreSQL with operator identity and timestamp |
| Account pause/unpause | PostgreSQL with operator identity and timestamp |
| API key issuance and revocation | PostgreSQL with operator identity |
On-chain transactions are permanently verifiable on Solana Explorer using the tx_signature returned by the API. Off-chain policy events are stored in a tamper-evident append-only log — rows are never updated or deleted, only appended.
What ClawdGo does not do
- ClawdGo does not hold private keys on behalf of users. PDAs are controlled by the program, not by a ClawdGo-held key.
- ClawdGo does not commingle funds. Each agent account has its own isolated USDC SPL token account on-chain.
- ClawdGo does not perform yield strategies or protocol interactions with deposited USDC.