The CISO's Guide to Runtime Governance for AI Agents

If you run security at a regulated enterprise, you already have AI agents in production. You may not have approved all of them. Your developers are running coding agents with shell access. Your business units are wiring copilots into customer data. Somewhere in your environment an agent is making a model call right now, and you cannot see what it sent.

This guide is about the control layer that fixes that. It is written for the person who has to answer for it when the regulator asks.

The gap nobody planned for

Start with the numbers, because they are worse than most boards understand.

Check Point's 2026 Cloud Security Report found that 77% of organizations have changed their security strategy in response to AI. Only 26% have the architecture to enforce it. That is a 51-point gap between intent and capacity. The strategy decks exist. The governance boards have met. The architecture that would let any of it actually happen does not.

The same research found that 83% of organizations have not broadly deployed runtime controls for LLM inputs and outputs. 70% are running GenAI in production. 64% have agents in pilot or production. 12% have given those agents privileged access to core systems. The agents are live. The controls are not.

This is the same shape every infrastructure shift takes. The capability arrives, the business adopts it because the business always adopts capability ahead of control, and security spends the next eighteen months building the governance layer that should have existed at deployment. We saw it with SaaS. We saw it with mobile. We saw it with cloud. CASB, MDM, and CSPM were the answers, and each arrived after the adoption, not before.

AI agents are the current instance. The governance layer is runtime governance. This guide is what it is and what to require.

What runtime governance actually means

Runtime governance is policy enforcement at the point where an AI agent acts. Specifically, it is inspection and control of every prompt, every response, every tool call, and every agent-to-agent message, applied inline, before the action completes.

The word that matters is "before." Most AI security today is detection. The tool watches what happened and writes a log. Detection produces evidence after the event. It does not produce control at the moment that matters. When an agent sends customer PII to a public model, a detection tool tells you it happened. A runtime control stops it from happening.

Check Point's data on this is stark. Across prompts, only 13% of organizations can block a malicious prompt in real time. For data leaving to AI services, 16% can block. For unsafe model outputs, 5% can block. Everyone else can, at best, detect and alert. They see the risk. They cannot stop it.

Runtime governance is the layer that moves an organization from "we detected it" to "we prevented it." That distinction is the entire game in a regulated environment, b/c a detected violation is still a violation. The customer data still left. The regulator still has a finding.

Why this is a separate layer

The most common pushback I hear from security teams is that they already have this covered. They have an identity governance program. They have a workflow platform with AI controls. They have a data loss prevention tool. Why is runtime a separate thing?

Because each of those answers a different question, and none of them answers the runtime question.

Identity governance answers "who is this agent and what is it allowed to access." That is necessary and it is upstream of runtime. Okta, Entra, Veza, and the rest resolve the identity and scope the permissions. But identity does not inspect what the correctly-identified agent actually sends to the model. An agent can be perfectly authenticated and still ship a customer's social security number to a public endpoint. Identity said yes to the agent. Identity has nothing to say about the payload.

This matters more now that the incumbents are collapsing runtime into identity in their marketing. CyberArk's Idira and similar plays position identity as the whole answer. It is not. Identity is the answer to who. Runtime is the answer to what. Different questions, different layers, and the failure mode test proves it: when an agent leaks PII to a public model, the agent was identified just fine. The failure was at the payload, which identity never inspects.

Workflow governance answers "which agent runs, on whose authority, doing what work." ServiceNow's AI Control Tower and Microsoft's Agent 365 sit here. They spawn agents, scope authority, and audit workflow actions. This is the workflow plane, and it is real. But it sits above the call between the agent and the model. It governs which agent gets to run. It does not inspect what that agent sends to the model once it is running. When the workflow plane fails, an agent runs the wrong workflow, and that is a CIO problem. When the runtime plane fails, an agent sends customer data to a public model, and that is your problem.

Data loss prevention answers "is sensitive data leaving through known channels." Classic DLP was built for email, file transfer, and web uploads. AI traffic does not look like those channels. A long prompt to an LLM endpoint, a streaming response, a model-specific API call, a tool invocation carrying a sensitive argument. Traditional DLP either misses these or drowns in false positives. Check Point found 71% of organizations report increased WAF false positives since GenAI adoption, and only 22% rate their WAF effective against AI-specific attacks like prompt injection.

Runtime governance is the layer that sits in the data path between any agent and any model, inspects the actual content of the interaction, and enforces policy inline. It composes with identity and workflow. It does not replace them. It fills the gap they leave.

The four questions a runtime layer has to answer

When you evaluate any runtime governance approach, make it answer four questions concretely. If it cannot, it is detection wearing a governance label.

What did the agent actually send to the model? Not "which agent called." The content. The prompt, the context, the tool arguments, the data attached. If the system cannot inspect the payload, it cannot govern it.

Can you stop it before it leaves? Inline enforcement, not after-the-fact alerting. Block, redact, route to a compliant zone, or require human approval. At the moment of the call, before the data crosses the perimeter.

Does it tie back to a verified human? Every agent action should trace to a named human principal who authorized it. When the agent is six hops down a chain of other agents, the trace still has to hold. Service-account anonymity is the thing that turns an incident into an unanswerable question.

Can you prove it to a regulator? The audit record has to be captured at enforcement time, tamper-evident, and tied to identity. Reconstructed-after-the-fact logs are not proof. They are a project you start the week the exam notice arrives.

The on-premises requirement

For regulated enterprises, one architectural point is not negotiable: the runtime layer has to be able to run on your infrastructure, with your data never leaving your perimeter.

This is not a preference. It is a regulatory and supply-chain requirement.

The regulatory side: FINRA, SEC, OCC, HIPAA, ITAR, CMMC, and the EU AI Act all require demonstrable control over AI systems processing sensitive data. A cloud-hosted gateway can promise that control. It cannot architecturally guarantee it, because the data transits infrastructure you do not own. "Trust us" is not a control a CISO can defend in an exam.

The supply-chain side: the March 2026 LiteLLM compromise proved the cost of inherited dependencies. 95 million monthly Python downloads. A third of cloud environments touched. One coordinated supply-chain campaign through PyPI, and every enterprise running the compromised package spent that week verifying whether their secrets had walked out the door. A runtime layer built as a cloud-distributed library inherits every vulnerability in its supply chain. A signed, on-premises appliance with no production PyPI dependency does not.

When you evaluate runtime governance, the deployment model is a gating criterion, not a feature comparison. On premises, VPC, and air-gapped have to be on the table. If the only option is the vendor's cloud, the data residency question is already answered the wrong way for a regulated buyer.

What good looks like in practice

Here is what a runtime governance layer does on a single model call, in the order it happens, so you can hold any vendor's architecture against a concrete sequence.

The agent makes a call. The runtime layer intercepts it at the network layer, with no application code change. An SDK shim, a reverse proxy, or a DNS route. The caller is resolved to an SSO-verified user or a signed agent identity, and that identity traces to a human principal. The prompt is inspected for PII, secrets, and policy violations, with redactions applied inline and disallowed patterns blocked before egress. The request is routed to the appropriate model by cost, latency, or compliance zone. Sensitive data to an on-premises model, non-sensitive to a public one, by policy you set. An immutable audit entry is written: caller, model, token count, every policy decision, every redaction, in a format exportable to SOC 2, HIPAA, EU AI Act, and SR 11-7. The response comes back through response-side inspection, so a model that hallucinates PII into its output gets caught on the way out, not just on the way in.

All of that on a single call, at sub-millisecond overhead, with the data never leaving the perimeter. That is the bar. Anything that cannot describe its own version of this sequence is not yet a runtime governance layer.

Mapping it to the exam

The reason this matters to you specifically, rather than to your CIO, is that the failure modes land on your desk and the evidence requirements land in your exams.

SR 11-7 requires documented validation, ongoing monitoring, and independent challenger review for every model in use, including LLM-based ones. A runtime layer that records every model call, every policy decision, and the enforcement history of each endpoint gives you the model inventory and the monitoring evidence as a query, not a quarterly scramble.

FINRA Rule 3110 requires information barriers that are operationally enforced, not documented on paper. A runtime layer that maps every user to a regulatory classification at request time and blocks MNPI from crossing group boundaries enforces the barrier on the wire and produces the supervisory attestation on demand.

FFIEC IT examination covers access governance, change management, incident response, and audit log integrity. A runtime layer with identity-bound, tamper-evident logs answers the audit-integrity question directly.

EU AI Act Article 52 requires high-risk system documentation, human oversight records, and post-market monitoring telemetry. A runtime layer captures the oversight and monitoring evidence at enforcement time.

The pattern across all four: audit data captured at the moment of enforcement, not assembled retrospectively. Examination prep collapses from a multi-week project into a query against data you already hold. That is the difference between a control that exists in a policy memo and a control that survives an exam.

The attack surface you inherited

Runtime governance is not only about your own agents behaving badly. It is also about the attacks that ride the agent's authority.

Prompt injection is the clearest example. An agent crawls a documentation page, a support ticket, or a web result that contains instructions written for the model rather than the human. The model treats those instructions as legitimate and acts on them. The agent had real credentials and real access, so the injected instruction executes with the agent's full authority. The SymJack disclosures in May showed five major coding agents turned into supply-chain delivery systems through exactly this path: a developer approves what looks like a routine file operation, and the agent executes attacker-controlled code with the user's privileges. The human approved. The system did what it was built to do. That is the problem.

You cannot patch your way out of this category, b/c the next injection vector will look different from the last. The structural answer is a layer that inspects what the agent is about to send and what it is about to execute, independent of how the agent was convinced to do it. Identity does not help here, b/c the agent is correctly identified. Workflow governance does not help, b/c the workflow is running as designed. The only control that catches an injected instruction is the one sitting in the path inspecting the actual content of the call.

The non-human identity problem compounds it. Check Point found 48% of organizations rank managing non-human identities as their leading AI-related identity challenge. Agents authenticate with service accounts, API keys, and delegated permissions that do not behave like human access and do not fit human-centric IAM models. An over-privileged service account behind an agent is a standing liability. The runtime layer is where you constrain what that account can actually do at the moment it acts, regardless of what its credentials technically permit.

What to do now

Three steps, in order, because each one makes the next possible.

See it. You cannot govern what you cannot see. Only 5% of organizations report full visibility into AI tool usage. Before you enforce anything, inventory the AI traffic: which agents are calling which models, what data is moving, where it goes. The runtime layer is also the instrument that produces this visibility, because it sits in the path where the traffic actually flows.

Enforce at the highest-risk boundary first. Do not try to govern everything on day one. Start where the failure is most expensive: the agents touching customer data, the coding agents with shell access, the model calls leaving the perimeter. Strict policy at the boundary that matters, then expand as clean telemetry accumulates.

Make the evidence automatic. The audit trail has to be a byproduct of enforcement, not a separate reporting effort. If producing exam evidence is a project, you have built the wrong thing. If it is a query against logs captured at enforcement time, you have built the right thing.

Runtime governance is not a new category because someone needed a new category. It is the layer that the last two years of AI adoption left unbuilt, and the layer that the next two years of regulation will require. The enterprises that build it now will present a defensible posture to regulators, auditors, and boards. The ones that wait will be reconstructing evidence the week the exam notice arrives.

The agents are already in production. The question is whether you can prove what they did.

This is the layer APERION builds. Runtime governance on the wire, on premises, identity-bound, exam-ready. See the Trust Fabric architecture for where it sits in the full stack, or request a demo to see it on real hardware.