The Permissions Model for Agentic Banking: A Technical Primer

Every claim about agentic banking eventually reduces to a single technical question: how do you let an AI agent move money without giving it the keys to the kingdom? The marketing answer is "we have a permissions model." The technical answer needs to hold up to a SOC 2 review, an internal red-team exercise, and the kind of skeptical due-diligence question that comes from a CFO who reads your security architecture before signing a contract.

This is the technical answer.

The Threat Model

Before the permissions model is interesting, the threat model has to be clear. We design against five concrete threats.

1. Compromised agent prompt. A user, or someone impersonating a user, sends a malicious prompt that tries to drain the account.
2. Compromised LLM session. The LLM session itself is hijacked through a prompt injection from a tool the agent is connected to (a malicious email, a poisoned web page, a manipulated invoice).
3. Compromised agent credentials. The agent's authentication token is stolen and replayed by an attacker.
4. Lateral movement. A legitimate agent for one user attempts to access another user's account.
5. Insider error. A legitimate agent, operating within its scope, makes an honest mistake (wrong amount, wrong vendor, duplicate payment).

The permissions model has to defend against all five. Not three. Not four. All five. The model below was designed against this threat enumeration explicitly, and every primitive in it can be mapped back to one or more threats it closes.

How Traditional Bank Permissions are Built (And Why Agents Broke Them)

Traditional commercial bank permissions inherit a model from the 1980s. A single human user logs into a dashboard. The user has a role (Owner, Controller, Bookkeeper, Read-only). Each role gates access to features. ACH origination, wire approval, and card issuance are gated behind the role plus, for high-value actions, dual-control requirements.

This model has held up reasonably well for human users. It does not hold up for AI agents, for three reasons:

• Identity granularity. A role is too coarse for an agent. You do not want your AP agent to have the same scope as your CFO. The traditional role model gives you four to six predefined roles. An agentic banking deployment routinely needs ten to thirty distinct identity classes per customer, each with its own scope.
• Token lifetime. Traditional bank sessions are tied to browser cookies that expire on logout or after a fixed window (typically 8 hours). Agents run continuously, often for days. A naive port to agent contexts gives you 30-day tokens with too much trust.
• Action enumeration. Traditional bank dashboards expose a fixed set of buttons. Each button maps to a backend action. Agents construct arbitrary tool calls that may or may not match a button. The backend cannot rely on "the user clicked the right button" as a permission gate.

The agentic permissions model has to solve all three problems without breaking the existing dual-control and SOC 2 affordances that auditors and finance teams already understand. The Meow model below is the result.

The Primitives

The Meow permissions model is built on four primitives. Each primitive maps to a defense against the threats above.

Per-agent scoped tokens

Every agent gets its own short-lived bearer token, scoped to a specific user and a specific capability set. The token is generated through OAuth 2.1 with a custom scope grammar (described below), and rotated automatically on a configurable schedule (default: 24 hours).

The token itself is a JWT with a custom claim structure. Simplified shape:

The scope grammar is capability-based. Examples:

read:transactions

read:balance

issue:card[cap=2000,mcc=5734]

send:ach[cap_per_payment=10000,cap_per_day=25000]

send:wire[cap_per_payment=50000,whitelist=vendor_master]

approve:above_threshold[notify=sms:+15555555555]

A token is the union of the scopes granted to its agent. An agent can hold a single token with five scopes, or five tokens with one scope each, depending on the deployment. The choice is the customer's. The default is the latter, which gives finer revocation granularity.

Scope grammar evaluation is at action time, not at token issuance time. When an agent calls the Meow API to send a wire, the wire request is evaluated against the live scope (which may have been revoked or modified since the token was issued). This closes the lateral movement and credential-replay vectors. A token granted at 9:00 AM with a $50K cap, then reduced to $10K at 11:00 AM, has the $10K cap when an action arrives at 11:01 AM. The token does not need to be re-issued.

Capability-based authorization

Every action an agent can take is defined as a capability with a fixed schema. Capabilities cannot be composed at request time. An agent that holds send:ach cannot construct a send:wire request and have it executed; the API rejects it at the schema layer.

Capabilities are also bounded. The cap_per_payment and cap_per_day fields are hard limits, evaluated at the API gateway before the request reaches the payment engine. An agent that tries to send $25,001 on a token with cap_per_payment=10000 is rejected at the gateway with a 403 capability_exceeded response. The payment engine never sees the request.

The bounds compose. An agent with cap_per_payment=10000 and cap_per_day=25000 can send three $9,000 ACHes in a day (total $27,000) only if the daily cap allows it. The third ACH at $7,000 succeeds; the fourth is rejected. Daily limits reset at the customer's configured timezone midnight, not at the bank's, which avoids the surprise of a same-day rejection because the agent crossed the bank's UTC midnight.

Capability schemas are versioned. When we add a new capability or change the bounds an existing one accepts, the change is deployed alongside a backward-compatible parser so existing tokens keep working. Capability deprecation runs on a 90-day window with notifications to every customer holding affected tokens.

Isolation between agents

Each agent's token is scoped to a single user. The user identity is part of the token claim, signed by the OAuth issuer, and verified at every API call. A token issued for user A cannot make calls against user B's account, regardless of what the prompt says.

For shared accounts (a finance team where multiple agents act on behalf of the same user), each agent still has its own token with its own scope. An agent for the controller cannot exceed the controller's scope. An agent for the CFO cannot exceed the CFO's scope. The two agents are isolated, even though they act on the same account.

This isolation is enforced at four layers:

1. Token level. Token claims include the user ID and the agent identity, signed by the auth issuer.
2. API gateway level. The gateway verifies the token signature and the user identity match on every request, against an internal user-to-account mapping.
3. Database level. Every query against the bank's database includes the user ID as a filter, enforced by row-level security (RLS) policies. A query that omits the user ID filter is rejected by the database, not by the application code.
4. Audit level. Every action is logged with the agent identity, the user ID, and the capability invoked. Audit log review will surface any cross-user access attempt, even if it succeeded somehow.

The four-layer enforcement means no single layer's failure results in a privilege escalation. The model is intentionally redundant.

The audit log

Every action an agent takes is logged. The log entry captures:

• The agent identity (agent name, deployment, session ID)
• The user identity the agent is acting on behalf of
• The token used (with its scopes at the time of the action)
• The full prompt that triggered the action (or the prompt chain, for multi-turn workflows)
• The capability invoked
• The data the agent acted on (invoice ID, vendor record, transaction reference)
• The outcome (success, failure, rejection reason)
• A cryptographic signature linking the entry to the previous entry (a tamper-evident chain)

The log is append-only. Past entries cannot be modified. The chain of cryptographic signatures means any tampering is detectable on review. We use Ed25519 signatures over the SHA-256 hash of the previous entry, batched into 1-minute Merkle roots that are written to a separate immutable store. The full audit chain can be cryptographically verified end-to-end by an auditor with the public key.

This log is the same log that captures human actions. The "human or agent" distinction lives only in the agent identity field. Everything else is the same audit trail. Compliance, board reporting, and external auditors read one log, not two.

How a Request Flows Through the Model

A typical agent action: "send $4,000 ACH to Acme for invoice INV-1142."

1. Prompt arrives. The agent receives the user prompt in its session.
2. Tool call constructed. The agent constructs an MCP tool call: send_ach({recipient: "Acme", amount: 4000, memo: "INV-1142"}).
3. API call to Meow. The agent calls the Meow API gateway with its bearer token.
4. Token validated. The gateway verifies the token signature, checks the token has not been revoked, and extracts the user ID and the scopes.
5. Capability checked. The gateway checks the send:ach scope is present and the cap_per_payment is not exceeded.
6. Recipient resolved. The gateway resolves "Acme" against the user's vendor master, retrieves the bank details, and verifies the bank details have not changed since the last payment.
7. Approval check. If the action exceeds the configured approval threshold (or hits a "new vendor" or "bank-detail change" rule), the gateway holds the request and triggers the approval surface (SMS, Slack, agent chat).
8. Payment dispatched. Once approved (or if no approval is required), the request is forwarded to the payment engine. The payment engine executes the ACH on the partner-bank rail.
9. Audit entry written. The full action is logged with the cryptographic chain entry.
10. Response to agent. The gateway returns the payment reference number to the agent, which surfaces it back to the user.

Steps 4 through 7 are the permissions model in action. They fail closed. Any check that does not return an explicit "allow" results in the request being rejected. The end-to-end latency for a clean ACH dispatch through this pipeline is around 180ms.

What This Defends Against, Threat by Threat

Threat 1 (compromised prompt): Caps and approval thresholds bound the damage. A malicious prompt cannot exceed the configured cap on the agent's token. A high-value action triggers human approval. The blast radius is the configured cap minus the time it takes to revoke the token. For an AP agent with a $10K cap, the blast radius is at most $10K assuming instant revocation, $25K assuming the daily cap is exhausted before revocation. We have not seen a successful attack of this class in production.

Threat 2 (LLM session injection): Same as Threat 1, with one addition: the system prompt can be configured to require a confirmation token from the user (typed into the agent chat, generated server-side and sent out-of-band) for sensitive actions. The injection cannot synthesize the confirmation token from outside the user's session. We default this on for any action above the per-day cap and any new-recipient wire.

Threat 3 (compromised credentials): Tokens are short-lived (24 hours by default) and rotation is automatic. A stolen token has a maximum 24-hour exploitation window. Cap and approval rules bound the damage within that window. Anomaly detection (unusual geography, unusual time of day, unusual recipient) flags suspicious actions for human review. We additionally support hardware-bound tokens through WebAuthn for customers who want to eliminate token replay entirely; the token is bound to a YubiKey or platform authenticator and cannot be moved off the device.

Threat 4 (lateral movement): Token claims include the user ID. The four-layer enforcement (token, gateway, database, audit) means an attempted lateral move fails at multiple checkpoints. We have not seen a successful lateral move in production.

Threat 5 (insider error): The audit log preserves every action, the cryptographic chain prevents tampering, and the explicit-rules model prevents the agent from acting outside its scope. Errors are recoverable through the same dispute and clawback process that exists for any human-initiated payment.

SOC 2 Considerations

The permissions model is designed against the SOC 2 Trust Services Criteria, specifically:

• CC6.1 (Logical Access Controls): The token-based authentication, scope grammar, and capability-based authorization map cleanly to CC6.1. The four-layer enforcement provides defense-in-depth.
• CC6.2 (User Registration and Authorization): Per-agent token issuance is auditable. Agent identity, agent class, and the issuing user are captured at issuance time. Token revocation propagates within seconds of the revocation event.
• CC6.6 (Logical Access Controls Over Information Assets): Token issuance and revocation are auditable, time-bound, and reversible. The agent identity is a first-class citizen, not a service account.
• CC6.8 (Prevention or Detection of Unauthorized Software): Capability schemas are versioned and the agent cannot construct unsupported capabilities at request time.
• CC7.1 (System Monitoring): The audit log is append-only, cryptographically chained, and captures every action with full context.
• CC7.2 (Anomaly Detection): The runtime checks for anomalous behavior (new vendors, unusual geographies, bank-detail changes) feed the same monitoring pipeline.
• CC7.4 (Incident Response): Token revocation is single-click. Anomaly-triggered alerts route to the customer's incident response surface (SMS, Slack, ticketing system).

A SOC 2 auditor reviewing the system reads the audit log, traces a sample of actions through the model, and verifies the controls fired correctly. The model is built to make that audit straightforward. We have completed Type I and Type II SOC 2 audits with no exceptions related to the agent permission system.

Production Engineering Decisions

Five engineering decisions that shape how the model behaves in production. Each is a deliberate design choice that holds the model up under real customer load.

Token rotation under load. Auto-rotation runs with a soft-rotate window so an agent in the middle of a multi-call workflow always has a fresh token before the old one expires. The grace period is configurable, with the default tuned against multi-hour AP cycles and overnight batch closes. An agent never receives a 401 mid-workflow.

Capability composition logging. When an agent combines capabilities locally (read:balance plus send:ach to construct a "check balance, then send if above $X" workflow), the agent SDK logs every intermediate read against the agent identity. The full chain is auditable, not just the final action.

Database row-level security on every replica. RLS policies are enforced on every replica of the bank's primary database, including analytics and reporting tiers. Cross-user data is isolated at the database layer, not the application layer, on every read path.

Approval-surface latency tolerance. Above-threshold approvals run with a 5-minute default timeout, configurable per customer. The window accommodates carrier congestion in any global market without expanding the fraud surface, since cap enforcement is independent of approval timing.

Audit log signature key rotation. Audit-entry signing keys rotate annually. Historical public keys remain published with their signing windows so any auditor can verify any historical entry against the key in force at the time. The model supports indefinite-horizon audit verification.

What We are Working on Next

Three areas of active investment in the model. Each is a place where the existing controls already cover the production case and the next layer of work is making the guarantees stronger.

Cross-agent identity modeling. The current design enforces different identity classes for the prepare and approve roles, so an automated agent cannot also approve its own actions. Deeper agent-identity modeling (formalized agent lineage, attestation chains, cross-agent trust graphs) is the next step.

Long-running session continuity. The hard-stop at 7 days regardless of rotation status guarantees boundedness today. Ongoing work is making rotation continuity provable end-to-end, with cryptographic attestations at every rotation boundary.

Vendor master cryptographic identity. Multi-step verification on bank-detail changes is enforced today. The next layer is around cryptographic vendor identity and supplier-side attestations, so the vendor master itself becomes an attested source of truth instead of a trusted database.

The Bottom Line

A permissions model for agentic banking is not a feature. It is the entire product. The bank that gets the model right wins the customer who is currently asking ChatGPT to manage their finance work. The bank that builds an "AI banking" demo on top of a legacy permission system gets nowhere near production.

The full agentic stack (workflows, controls, audit) lives on top of the model described here. The companion posts cover the workflows: why every bank account will be opened by an AI agent and the agent-run AP playbook.

The model is what holds them up.