Security model

Sandbox live. Create a free sandbox workspace at agentic-sandbox.pinkwallet.com (test credentials only; no money moves). Production is not yet available.

The question every finance team asks first: what happens when an agent is wrong, compromised, or simply over-eager? This page is the answer, in the order the system defends itself.

1. The agent never holds money

An agent holds one thing: a key. The key can ask. It cannot read a balance it is not attached to, see a company card, or reach a bank login. What comes back after an approved request is a credential for that one payment: a single-use virtual card locked to the payee and the amount, a bank transfer that is already submitted, or a platform refund reference. Each expires 15 minutes after issue.

2. A leaked key is a bounded problem

Someone who steals an agent key can do exactly what the agent could do: request payments inside that agent's budget, cap and vault, to the payees the policy allows, with the same rules asking a person for anything unusual. They cannot change the rules (that needs the admin key), cannot raise the budget, cannot pay a payee the policy blocks, and cannot make the company exceed its daily ceiling. Rotate the key in the console; the old one stops within minutes. Pause the agent; every request it makes is blocked immediately.

3. Circuit breakers run before any rule

• Unknown key: 401, no detail.
• Paused agent: blocked.
• Monthly budget: an agent whose budget is used up is stopped, not queued.
• Company daily ceiling: all agents together.
• Vault balance: the vault must hold the money.

Breakers have no approval path. They are the floor under the policy.

4. Rules that block without asking

Some rules are written with action: block and no approvers on purpose: gift cards and cash-like purchases, a supplier payment without a PO, a refund before the warehouse scan, API credits beyond a daily stop. A runaway process cannot talk its way through them, and neither can a persuasive agent. The 03:14 case in the startup template is the canonical example: a retry loop asked for $49,600 of API credits and met a $200-a-day rule.

5. Fraud signals before amount tiers

Two signals are checked on every request, regardless of amount: the payee changed bank details in the last seven days (invoice-redirection fraud), and the invoice number was already paid in the last ninety days (duplicate). Policies place these rules at the top so a $400 payment gets the same check as a $40,000 one.

6. People decide the exceptions, and silence is a no

An ask rule names people or a quorum of a group. The request waits as a hold with a timeout; the approver sees the amount, the payee, the rule that stopped it, the agent's stated reason and its evidence. If nobody answers before the timeout, the hold expires and the agent is told expired. Nothing is approved by default.

7. Idempotency

request_payment accepts an idempotency_key (or the Idempotency-Key header on REST). Repeating a key returns the original decision with replayed: true instead of creating a second payment. Agents that retry on timeouts should always send one.

8. Versioned policy, complete log

Every change to the rules publishes a new numbered version with the author. Every payment record stores the version that decided it, the rule, the decision trace, the approvers and the credential issued. Blocked and declined requests are kept too. The log exports for audit.

9. What the sandbox does not do

• No real money, cards or bank transfers: credentials are test values.
• Keys are static Bearer tokens; production adds OAuth for hosted clients and key rotation policies.
• Evidence flags are asserted by the agent; production verifies them against connected systems (ERP purchase orders, helpdesk tickets, warehouse scans, carrier statements).
• Workspaces are kept for 30 days of inactivity.

10. Responsibilities, stated plainly