Can you prove who or what can access sensitive systems, execute transactions, and retrieve customer records, across both human and non-human identities, at the exact millisecond an action occurs?
If your bank is scaling autonomous agents, that single question is where your next OCC examination and audit committee review will converge.
The OCC recently issued its supervisory framework for what it designates "Super Intelligence" (SI), pulling terminology from the 2026 executive order to cover everything most of the industry still categorizes as AI and Agentic AI.
At first glance, the guidance appears measured. The OCC isn't asking banks to stand up an isolated risk appetite or invent a separate SI risk category. Instead, examiners apply judgment scaled to the real-world impact of each specific use case, the same proportional stance state examiners took in the CSBS AI supervisory framework.
The core takeaway is, governance must track consequence and transferred agency, not technical sophistication. A basic, rules-driven bot authorized to move funds carries far more institutional risk than an advanced LLM that merely drafts internal memos.
If you take one lesson into your next risk committee, make it this: don't grade your AI exposure by how complex the model is. What the agent can execute determines the controls you need.
Why Agents Break Traditional Banking Access Controls
Internal chatbots answer questions. Agents take action.
Once you give a model the ability to query back-end systems, invoke API tools, navigate workflows, and execute transactions on a user's behalf, your risk posture fundamentally changes.
Many teams make the mistake of relying on system prompts to set boundaries. It's a dangerous assumption. A prompt can influence how an agent intends to behave, but it cannot physically prevent an agent from using valid credentials it already holds. Prompt injections can bypass safety guardrails, and shifting context windows cause models to hallucinate or drift.
When agents fail, you face the classic headaches every Identity and Access Management (IAM) team knows all too well:
- Unauthorized privilege escalation
- Uncontrolled data exposure
- A broken, opaque audit trail right when a critical transaction occurs
Prompt engineering belongs inside the model to guide intent. But enforcement must live outside the model.
The most defensible architecture places an independent policy decision point between the agent and your environment. The policy validates every single action against deterministic authorization policies and shuts it down instantly if it exceeds allowable scope, regardless of what the prompt instructed.
Engineering's immediate objection will be latency, but against model inference times that routinely run in seconds, a sub-millisecond policy check at the edge is a rounding error. You get the strongest possible operational posture without creating a bottleneck.
What OCC Examiners Will Actually Look for in the Field
The OCC framework outlines sixteen components across six pillars: purpose, risk, control, oversight, resilience, and assurance.
Cut through the regulatory jargon and the framework's real weight lands on one operational phase: runtime behavior.
When examiners evaluate your autonomous agents, they will be checking for five specific capabilities:
- Strict Purpose Boundaries. Can you prove, in auditable terms, who may invoke the agent, what systems it can touch, and what actions it can trigger? If an agent acts outside its defined remit, the OCC considers that a control failure even if the final output looks accurate.
- Upstream Data Governance. Are you filtering data before it ever hits the context window? Relying on an LLM to "ignore" sensitive customer data in its prompt doesn't fly; technical controls must block access upstream.
- Operational Circuit Breakers. For high-impact or autonomous workloads, do you have automated tripwires? Think least-privilege scoping, rate limits, temporary suspension, and instant kill switches that pull an agent off the wire the moment it begins executing erratically.
- Governing Agents as Privileged Identities. When an agent holds broad API credentials, compromise happens at machine speed. Examiners expect banks to treat agent and non-human identities with the exact same rigor, rotation, and access policies applied to a domain admin.
- Forensic Reconstruction. If an agent executes an anomalous transaction, can you trace every step backwards? It means an immutable log tying the initial prompt to the specific tools called, the data retrieved, and the exact policy approval granted.
Look at that checklist again. Every single one of these mandates is an execution-time enforcement problem. Offline benchmark scores and model accuracy tests solve none of them.
Mapping PlainID Runtime Authorization Directly to the OCC Mandates
PlainID is an external Policy-Based Access Control (PBAC) platform purpose-built for execution-time enforcement.
The division of labor is straightforward: your identity provider handles authentication, while PlainID acts as the deterministic policy layer deciding what a user, non-human identity, or autonomous agent can retrieve, touch, or execute at the exact millisecond of the request.
When you map PlainID's architecture to the OCC framework, four operational requirements fall directly into place:
- Eliminating Scope Drift & Excessive Agency. Static service accounts and hardcoded credentials are a non-starter for autonomous agents. PlainID enforces a Zero Standing Privileges model at runtime. If an agent hallucinates, goes off-script, or encounters prompt injection, the request still hits an external policy gate. If the API call falls outside its authorized scope, it gets killed on the spot, regardless of what instructions the model accepted.
- Securing Data Upstream for RAG. You cannot count on a model to self-censor. PlainID enforces row- and column-level entitlements, complete with masking and filtering, before data ever reaches the context window. Your agent simply cannot pull PII or material non-public records it has no right to see.
- Instant Enterprise-Wide Revocation. The OCC expects circuit breakers. Because PlainID manages policy from a unified control plane while executing decisions locally at the edge, your risk and security teams can pull an erratic agent's transaction rights across the entire enterprise with a single action. It needs no redeploying of microservices, no engineering tickets, and no propagation delays across disparate services.
- Examiner-Grade Forensic Trails. When an auditor asks why an agent accessed a sensitive database or initiated a wire, "the model decided to" is not an acceptable answer. PlainID records every allow/deny decision in plain, business-readable logic, instantly giving you the end-to-end reconstruction examiners require.
Two Real-World Scenarios: Internal and External
Internal: Developer & Employee Assist
Consider an engineer prompting an internal assistant to troubleshoot an issue, inadvertently requesting customer transaction histories. PlainID intercepts the query at runtime, blocks the data retrieval upstream, and logs the denial in clean audit text. The exact same security rule applies whether the engineer typed the command into a terminal or instructed an autonomous agent to execute it for them.
External: Retail Customer Agent Dilemma
Right now, risk committees across retail banking are taking a blunt-force approach: outright bans on external consumer agents connecting into core banking APIs. The fear is obvious: an unvetted third-party agent initiating fraudulent transfers, chaining unintended API actions, or exfiltrating data via prompt manipulation.
A blanket ban is an unsustainable stance as consumer-facing agentic tools become the default interface for personal finance.
With runtime PBAC, you don't have to trust the customer's agent. PlainID decouples identity from capability. When a retail customer's agent initiates an action, PlainID evaluates the request in real time:
- Is the agent operating within strict transaction thresholds?
- Does it stay confined exclusively to read-only balance lookups unless the customer clears step-up biometric auth?
- Does policy strictly block it from invoking administrative APIs like address changes or wire transfers?
If the consumer agent drifts, gets compromised, or attempts a forbidden action, the policy engine denies the request at the perimeter. You give retail customers the agentic connectivity they expect without surrendering perimeter control or failing supervisory exams.
OCC Examination Readiness: The Reality for Banking CISOs
Heading into an exam, banking CISOs face a simple architectural reality: you can't manage what you can't deterministically govern at runtime.
The only defensible path forward is an authorization layer decoupled from the model, one anchored in verified identity and built to withstand forensic audit scrutiny.
When the audit committee asks whether you can control and reconstruct what your agents are doing at the point of execution, offline benchmark scores and prompt guardrails will not protect you.
Runtime authorization does.
Take the Next Step: Benchmark Your Controls Against the OCC Pillars
You don't have to wait for an exam notice to identify where your agentic architecture is exposed.
If your team is actively evaluating how your AI initiatives map to the OCC's six pillars, let's connect. We'll walk through your current authorization model, pressure-test your runtime controls against the supervisory framework, and share how peer institutions are already solving this at scale.
