Rules agents cannot cross.
Prompt injection can fool the model. It cannot cross a spending rule enforced on-chain.
Agent spend policy
Managed vault · Arc testnet
The Arc stack
The pieces teams already use to ship agents, settle payments, and prove who is spending on-chain.
From sign-in to proof
The finish line is one protected payment.
Peribolos keeps the setup visible. You always know what is ready, what needs your approval, and what evidence you will have at the end.
Start the path- 01
Sign in
Use email first, then register a passkey for this device.
- 02
Connect the owner wallet
Your injected browser wallet approves the actions that belong to you, including deployment and funding.
- 03
Create the boundary
Provision an agent, set caps, allow a payee, and deploy a live vault on Arc.
- 04
Verify one payment
Send a small test request and see the policy decision, transaction, and audit proof.
Arc-native by design
Stablecoin rails for autonomous spend.
Peribolos uses Arc as the settlement layer for agent wallets, so policy, identity, and USDC movement live in the same programmable environment.
USDC
native gas and balances
EVM
compatible smart contracts
Arc
settlement layer
Inside the control plane
See what your agents can spend before they spend it.
Peribolos turns wallet policy into a workspace your team can inspect: live caps, recipient rules, and an audit trail that does not disappear when the prompt changes.
See the enforcement modelPeribolos workspace
Arc testnet policies
Recipient rules
Allowlisted only
Budget checks
Per transaction + daily
Settlement
Blocked before funds move
Every payment request is checked against policy
Prompt injection already drains agent wallets.
An attacker doesn’t need the agent’s private key. A poisoned web page, a malicious tool response, or a crafted instruction is often enough to talk a model into sending funds somewhere it shouldn’t. A guardrail written into a prompt is a suggestion the same attacker can write around. A rule enforced by a smart contract is not.
- reason
- RECIPIENT_NOT_ALLOWLISTED
- moved
- 0.00 USDC
A blocked request records the policy reason and moves zero funds. A live transaction link appears only when an on-chain payment exists.
Two tiers, two enforcement models.
Rule-enforced, on-chain
Every domain gets its own PeribolosVault contract. The recipient allowlist, per-transaction cap, and daily cap live in contract state, not app logic. pay() never reverts: a blocked call still returns success and emits PaymentBlocked with the reason, on-chain and permanent.
Bounded by deposit
The SDK and demo-agent can pair paid APIs behind x402 with a small Circle Gateway nanopayment deposit. The deposit is the ceiling; this dashboard intentionally manages the separate vault tier and does not display Gateway balances.
What makes it hard to argue with.
On-chain enforcement
The allowlist and caps are contract state, not a prompt rule. A payment must satisfy them before value can move.
Limits that stay attached
Daily and per-transaction ceilings travel with the vault, so every agent works inside an intentional budget.
ERC-8004 identity
Vault creation requests an ERC-8004 identity registration when the registry is available. Registration is best-effort, so verify the identity record before relying on it.
Ten-line SDK
createPeribolosTools() drops three tools into an existing LangChain agent. No rewrite, no new infrastructure to run.
Ten lines, not a rewrite.
Wrap an existing LangChain agent with three tools: pay, buy, and status. Every payment call is checked by the vault contract before anything moves.
import { createPeribolosTools } from "@peribolos/langchain";
const tools = createPeribolosTools({
vaultAddress: process.env.PERIBOLOS_VAULT_ADDRESS,
// Primary path: PERIBOLOS_API_KEY (pb_live_...) keeps agent private keys server-side
apiKey: process.env.PERIBOLOS_API_KEY,
});
// peribolos_pay · peribolos_buy · peribolos_status
model.bindTools(tools);