Permissions, Toggles, and Caps: The Customer-Configured Control Plane on Meow

An AI agent with full access to a business bank account is a liability if the access is not bounded. Most fintechs say this and then ship guardrails at the model layer, where they do not hold.

This post is the structural answer to where the guardrails belong. The answer is the API gateway. The guardrails are server-side. The model and the client get tokens, not authority.

Model-Side Guardrails Do Not Hold

A guardrail in the system prompt is a request to the model to behave. An adversarially-trained jailbreak prompt is a request to the model to ignore the request to behave. The two requests live in the same context window and compete on equal terms.

A guardrail in the model fine-tune is harder to displace but still subject to the same competition.

A guardrail at the client (the agent's calling code) is a request to the agent to behave. The agent is what is being controlled. Asking the controlled entity to enforce its own constraint is asking for an honor system.

The pattern works for low-stakes operations where the cost of a bypass is small. The pattern fails for banking operations where the cost of a bypass is a wire to a counterparty the operator did not authorize.

The Server-Side Answer

The bounds on agent-initiated banking operations have to be enforced before the operation reaches the partner bank's rails. Server-side. Not model-side. Not client-side.

The Meow API gateway sits between the agent and the bank's payment rails. Every operation an agent initiates passes through the gateway. The gateway checks the operation against the customer-configured bounds. If the operation is within bounds, the gateway forwards it to the bank. If not, the gateway rejects it and returns the failure to the agent.

The agent cannot route around the gateway. The bank's rails are not directly callable from the model or the client. Every path to a wire, an ACH, a card transaction, or a payment initiation runs through the server.

The Four Control Layers

Per-operation caps. The customer sets a maximum dollar amount per operation per type. Wire above $X, ACH above $Y, card transaction above $Z. Anything above triggers either a rejection or a routing to dual approval.

Daily ceilings. The customer sets a maximum total volume per day across all agents on the account. The ceiling applies across operation types: wires, ACH, cards, payments. Resets at midnight in the customer's configured time zone.

Dual-approval thresholds. The customer sets a notional above which a second authorized user must approve the operation. Useful for high-value operations where the operator wants a human review checkpoint.

Per-agent ramp limits. The customer sets a maximum volume per AI agent. Different agents can have different limits. An agent operating one entity can have a $10,000 ramp limit; an agent operating another entity can have a $50,000 limit. The pattern was introduced in the free USDC ramps post and applies across all operation types. The agent's identifier is established at the OAuth token issuance and travels with every request.

The four layers compound. An operation has to pass all four to reach the partner bank's rails.

Capability Toggles

Capability toggles are the higher-level on-or-off switches that govern entire categories of operation.

Wire toggle. The customer can turn wire capability off at the account level. With the toggle off, the gateway rejects every wire initiation regardless of caps, ceilings, or approval status.

ACH toggle. Same pattern. Off means rejected at the gateway.

Card issuance toggle. Controls whether the agent can issue new corporate cards on the account.

Payment initiation toggle. Controls whether the agent can initiate any payment, including from invoices, even where caps would otherwise allow it.

The toggles default to off at account opening. The customer turns each one on explicitly. The default-off behavior is intentional. We have shipped accounts to customers who never opened the dashboard to turn on capabilities they did not need. Those accounts remain in a safe state by default.

The Audit Trail

Every operation that hits the gateway, whether it passes or fails the bound check, is logged. The log captures the agent identifier, the operation type, the operation parameters, the bound check result, the partner-bank response, and the timestamp.

The audit trail is queryable through the dashboard and through the API. Operators reviewing an unusual transaction can see exactly which agent initiated it, which bounds were checked, and which limits applied. Operators can also see the operations that were rejected at the gateway, which surface the cases where an agent attempted to exceed a configured bound.

A logging surface that captures the rejections is more useful than one that only captures the successes. The rejected operations show the customer where to tighten the bounds and where to investigate misbehaving agent configurations.

OAuth 2.1 Token Scoping

The OAuth token issued to an AI agent is scoped at issuance. The scope encodes the entity the agent operates against, the operation types the agent is permitted to call, and the per-agent caps that apply.

The OAuth 2.1 specification is the consolidation of OAuth 2.0 best practices that became canonical in the years after RFC 6749 shipped. The Meow implementation follows the OAuth 2.1 pattern for token scoping, refresh, and revocation.

A customer revoking an agent's authority does so by invalidating the agent's tokens. Revocation propagates through the gateway and takes effect for all subsequent operations on that agent's identifier. Operations in-flight at the time of revocation complete or fail according to the partner bank's settlement rules; subsequent operations are rejected at the gateway.

NIST Framework Alignment

The control surface described in this post maps to the NIST Cybersecurity Framework functions of Identify, Protect, Detect, Respond, and Recover.

Identify: the agent identifier in the OAuth token establishes who is acting on the account.

Protect: the four control layers and the capability toggles enforce the bounds on what the agent can do.

Detect: the audit trail logs every operation that hits the gateway, including the rejected ones.

Respond: revocation invalidates the agent's tokens at the gateway level.

Recover: the audit trail and the partner bank's transaction records support post-incident reconciliation.

The mapping is not a certification claim. It is a structural alignment. Customers building their own internal frameworks against NIST will find the Meow control surface fits the mapping without bespoke integration work.

Frequently Asked Questions

Can I set per-agent caps that are tighter than the account-level caps? Yes. The per-agent caps are independent of the account-level caps. An agent with a $10,000 ramp limit can operate on an account with a $100,000 daily ceiling; the per-agent limit applies before the account-level ceiling. Tighter constraints win.

What happens when an agent tries to exceed a configured bound? The Meow API gateway rejects the operation and returns the failure to the agent. The rejection is logged with the agent identifier, the operation parameters, and the specific bound that triggered the rejection. The agent cannot retry around the bound.

Can I revoke an agent's access without affecting other agents on the account? Yes. Each agent has its own OAuth token scope. Revoking an agent's token does not affect other agents on the same account. The agent identifier in the token is the unit of revocation.

Do the bounds apply to dashboard operations as well as agent operations? Some bounds (per-operation caps, daily ceilings, dual-approval thresholds) apply to both. Others (per-agent caps, capability toggles for agent-initiated operations) apply only to agent-initiated operations. The customer configures which bounds apply where.

How do dual-approval thresholds work in practice? The customer sets a notional above which a second authorized user must approve. When an agent initiates an operation above the threshold, the operation is held at the gateway and a notification routes to the configured second approver. The second approver acts in the dashboard or through the API to approve or reject. The operation proceeds only on approval.

Are the capability toggles on by default? No. Wire, ACH, card issuance, and payment initiation are off by default at account opening. The customer turns each one on explicitly. The default-off pattern keeps new accounts in a safe state regardless of operator inattention.

What does the OAuth 2.1 token scope actually contain? The token scope encodes the entity the agent operates against, the operation types the agent is permitted to call (wire, ACH, card, payment, balance check, invoice), and the per-agent caps. The scope is bound at token issuance and cannot be expanded by the agent at runtime.

Why This Matters

Banking is a domain where the cost of a bad operation is the size of the operation. A $50,000 wire to the wrong counterparty does not roll back. The constraints on agent-initiated operations have to be enforced where they cannot be bypassed.

Model-side guardrails are bypassable. Client-side guardrails are bypassable. Server-side enforcement at the API gateway is not.

Meow's control plane is built on this premise. The bounds are configured by the customer, enforced by the gateway, and audited at the operation level. The agent gets the work done. The bounds prevent the work the customer did not authorize.

That is the structural answer. Banking-grade controls live at the server.

Banking services are provided by Grasshopper Bank, N.A., Member FDIC.