Policy Layer

Your AI agent just made its 47th Stripe charge of the day. Each one looked reasonable in isolation — $12 here, $35 there — but the cumulative total hit $4,200 before anyone noticed. The agent was doing exactly what it was told: processing orders. It just never stopped.

Adding spending controls to your MCP agent prevents exactly this scenario. MCP servers like Stripe, AWS, and Twilio give agents direct access to tools that cost real money. The agent doesn’t know it has a budget. The MCP server doesn’t enforce one. And thesystem prompt saying “don’t spend more than $500 per day”is a suggestion, not a constraint.

┌──────────┐ ┌─────────────┐ ┌────────────┐ │ LLM/AI │──────>│ PolicyLayer │──────>│ MCP Server │ │ Client │<──────│ (proxy) │<──────│ (upstream) │ └──────────┘ └─────────────┘ └────────────┘ │ ┌────┴────┐ │ Policy │ │ Engine │ └────┬────┘ ┌────┴────┐ │ State │ │ Store │ └─────────┘

version: "1" description: "Stripe spending controls" tools: create_charge: rules: - name: "max single charge" conditions: - path: "args.amount" op: "lte" value: 50000 on_deny: "Single charge cannot exceed $500.00"

The key detail: this check happens at the transport layer, before the request reaches Stripe. The charge is never created. There’s no refund to process, no failed payment to reconcile. This isdeterministic policy enforcement— the same input always produces the same result.

tools: create_charge: rules: - name: "max single charge" conditions: - path: "args.amount" op: "lte" value: 50000 on_deny: "Single charge cannot exceed $500.00" - name: "daily spend cap" conditions: - path: "state.create_charge.daily_spend" op: "lte" value: 1000000 on_deny: "Daily spending cap of $10,000.00 reached" state: counter: "daily_spend" window: "day" increment_from: "args.amount"

- name: "allowed currencies" conditions: - path: "args.currency" op: "in" value: ["usd", "eur"] on_deny: "Only USD and EUR charges are permitted"

This uses theinoperator to check against a whitelist. You can combine multiple conditions in a single rule — they’re ANDed together:

- name: "safe charge" conditions: - path: "args.amount" op: "lte" value: 50000 - path: "args.currency" op: "in" value: ["usd", "eur"] on_deny: "Charge must be under $500 and in USD or EUR"

Both conditions must pass. If either fails, the entire call is denied.

Some tools should never be called by an agent, regardless of arguments. Deleting customers, dropping databases, removing infrastructure — these are human-only operations:

hide: - delete_customer - delete_product - delete_invoice tools: delete_subscription: rules: - name: "block subscription deletion" action: "deny" on_deny: "Subscription deletion is not permitted via AI agents"

There are two approaches here. Thehidelist removes tools from the agent’s view entirely — they’re stripped fromtools/listresponses, so the agent never knows they exist. This saves context window tokens and prevents the agent from even attempting the call.

For tools you want the agent to see but not use, useaction: "deny". The tool shows up intools/list, but any call is unconditionally blocked with the denial message.

Even with per-tool spending controls, you want a backstop. A global rate limit caps the total number of tool calls per time window across all tools:

"": rules: - name: "global rate limit" rate_limit: 60/minute

The""wildcard applies to every tool call. This preventsrunaway loopswhere an agent calls tools hundreds of times per minute, regardless of whether each individual call passes its specific rules. For more onrate limiting strategies, see our practical guide.

{ "mcpServers": { "stripe": { "url": "https://proxy.policylayer.com/mcp/<server-uuid>/", "headers": { "Authorization": "Bearer <grant-token>" } } } }

You define and adjust the policy in thePolicyLayer dashboard— no local proxy to install or run.

version: "1" description: "Stripe MCP server spending controls" hide: - delete_customer - delete_product - delete_invoice tools: create_charge: rules: - name: "max single charge" conditions: - path: "args.amount" op: "lte" value: 50000 on_deny: "Single charge cannot exceed $500.00" - name: "daily spend cap" conditions: - path: "state.create_charge.daily_spend" op: "lte" value: 1000000 on_deny: "Daily spending cap of $10,000.00 reached" state: counter: "daily_spend" window: "day" increment_from: "args.amount" - name: "allowed currencies" conditions: - path: "args.currency" op: "in" value: ["usd", "eur"] on_deny: "Only USD and EUR charges are permitted" create_refund: rules: - name: "refund amount cap" conditions: - path: "args.amount" op: "lte" value: 10000 on_deny: "Refunds over $100.00 require manual processing" - name: "daily refund count" rate_limit: 10/day on_deny: "Daily refund limit (10) reached" "": rules: - name: "global rate limit" rate_limit: 60/minute

[POLICYLAYER POLICY DENIED] Daily spending cap of $10,000.00 reached

This is deliberate. The agent knowswhy*the call failed and can adapt its behaviour — inform the user, try a smaller amount, or wait until the window resets. It’s a feedback loop, not a silent failure.

The same pattern works for any MCP server that touches money or resources. AWS cost controls, Twilio message limits, database write caps, API call budgets — if the tool has arguments you can validate and calls you can count, PolicyLayer can enforce limits on it.

How do MCP spending controls persist across restarts?

PolicyLayer stores counter state in a persistent state store. When you restart PolicyLayer, daily spend totals, rate limit counters, and all other stateful tracking picks up exactly where it left off. No state is lost.

Not through PolicyLayer. Because spending controls are enforced at the transport layer — between the agent and the MCP server — the agent has no way to bypass them. The agent doesn’t even know PolicyLayer exists. It sees the same tools and schemas, but everytools/callrequest is evaluated against the policy before reaching the upstream server.

What happens when an MCP agent hits a spending limit?

The agent receives a denial message explaining why the call was blocked, e.g.[POLICYLAYER POLICY DENIED] Daily spending cap of $10,000.00 reached. The agent can then adapt — inform the user, try a smaller amount, or wait until the time window resets. The upstream MCP server never receives the blocked request.

Non-custodial spending controls for AI agent crypto wallets — enforce daily limits, per-tx caps, and recipient whitelists.

Pre-signature security suite for AI agents: flags wallet drains, permit-phishing, and risky actions before signing across EVM chains. Non-custodial.

Give AI agents spending power without giving them your wallet keys. Cloaked creates on-chain spending accounts with enforced constraints that agents cannot bypass - even if jailbroken or compromised.

AI-powered Solana token rug pull detection with ML ensemble scoring, honeypot detection, and temporal rug stage prediction.

Fight AI with AI. 6 adversarial AI agents debate crypto token risk before your agent trades.

Zen7 Payment Agent is the first implementation project of DePA (Decentralized Payment Agent), pioneers next-generation intelligent payment infrastructure.

MCP server for Aave — lending pool data, reserve info, user positions, and liquidation thresholds.

x402 payment gateway for AI agents — 12 crypto data tools (price, whale activity, gas, TVL, Fear & Greed, Dune queries) paid per-call in USDC on Stellar or Base. No API keys, no subscriptions.

Blockchain data across 100+ chains: token prices, NFTs, transfers, simulation, traces, Solana DAS

Trust infrastructure for AI agent commerce. Ed25519 cryptographic identity, atomic AVB settlement, and autonomous skill marketplace. 20 tools + 6 resources. OpenClaw SKILL.md compatible.