Security model and limits

What is enforced

• The SDK payment hook asks before the payment is signed, so a denied payment is never signed at all.
• The proxy URL sees the retry the client has already signed. On a deny it refuses to forward it, so the seller never receives the signature and there is nothing for anyone to submit.
• Neither one asks the agent for permission, so the agent cannot talk its way past them. Both enforce only while the agent is in enforce mode, below.
• A payment outside what you said the agent may buy waits for you.
• The guard decides and never pays. It holds no private key and signs nothing, so even a broken guard cannot move your money, and it cannot pull a payment back once it has settled.
• A decision belongs to the account whose key made it. Another account's key gets a 404, never someone else's decision.
• Your proxy token authorizes checks, not payments, so a leaked token cannot spend anything. Revoke or rotate it in the dashboard.

What is cooperative

The MCP tool and the skill that goes with it are cooperative. The agent has to call the tool. The skill makes the call a habit, not a rule, and an agent that ignores it can still pay. The same is true of any integration you write by hand against the API: it checks what you remember to send it.

If you need a check the agent cannot skip, put the traffic through the proxy URL or the SDK hook and keep the tool for the reasons it can quote to a person.

Content decisions

The content check reads what each path files. Through the SDK that is every page the agent fetched through the wrapped fetch, through the proxy the seller's 402 terms, and through the tool the text the agent passes. It reports one of three words: flagged, clear, or unavailable. A completed block denies the payment, and an unfinished check sends it to a person.

• It can miss a page written to look harmless, and it can flag a page that meant nothing by it. The decision log keeps the result, and observe mode records what enforcement would have done.
• When it is unavailable the rest of the rules still run, and a payment needing that check waits for a person.

Before you enforce

Mode is per key, not per account. Every key starts in enforce mode. Switch one to observe on the Agents page and almost nothing is blocked: the decision comes back allowed and shadowStatus carries what enforce would have said. Three denials are exempt: a network the policy does not allow, an asset the policy does not allow, and a payee other than the one the seller's own 402 named. Those three deny in every mode, whichever way in the key uses. Read a week of your own traffic that way, then switch the key back to enforce.

{
  "status": "allowed",
  "shadowStatus": "denied",
  "rules": [
    { "id": "amount_per_tx", "result": "deny",
      "sentence": "The amount 2.50 USDC is over the per-transaction limit of 0.10 USDC." }
  ]
}

The money

Every amount the demo shows is test USDC on Base Sepolia, where it and its shared wallet run, so anything you see it buy cost nobody anything. Your own agents can pay real USDC on Base or Solana Mainnet once you switch the policy's network. Solana Devnet uses test USDC. The guard still holds no funds, sees no key, and signs nothing: a denied payment is discarded, and an allowed one is signed by your agent's own wallet as before.

Known limits

• The guard decides only the payments routed through it. An agent that pays some other way is not stopped.
• The primary content check can deny a payment or hold it for a person. It never grants payment authority. It reads only what is filed, so a page the agent read some other way is not part of the decision.
• A request sent twice without an Idempotency-Key is decided twice. A retry after a timeout is a new decision, and when both are allowed or held, both count against the day's cap and the hour's count. The shipped SDK sends a key per attempt, so its retries read the first decision.
• A policy edit keeps no record of who changed it or when. Every decision keeps a copy of the rules it ran under, so the rules behind a past decision are always on its row.
• A settlement reported through the SDK, the MCP tool, or an EVM proxy payment is recorded as reported, so treat that row as a claim with a transaction identifier you can check. The Solana proxy confirms the approved transaction on chain before it records one.
• The per-minute meters are counted from requests already on record, without a lock, so requests in flight together can pass a per-minute ceiling by as many as are in flight. The daily cap and the hourly count are checked again once the decision is recorded, so payments in flight together never pass the cap together. Waiting payments already count, so approving a hold can never push the day over the cap.

What is not built yet

• No SMS and no phone call. A held payment is announced by webhook, email, or push, whichever you turned on under Settings. The webhook body and its signature are on the API page. A review nobody answers runs out and the payment does not happen.
• Other assets. On the Policy page the asset follows the network: USDC on Base Sepolia, Base, Solana Devnet, or Solana Mainnet. Other assets and raw Solana instructions are not supported by the dashboard. The hosted proxy also inspects standard sponsored Solana USDC transfers, but rejects arbitrary instructions, lookup tables, smart wallets and Token-2022.