Why Runtime Governance and Security Are the Same Problem for AI Agents
Edward Meyman · February 2026
For traditional software, security and governance are separate disciplines. Security controls what systems can access, and under what conditions. Governance controls what organizations permit. They live in different teams, different tools, different audit cycles — and that separation mostly works, because traditional systems have bounded behavior: given known code and configuration, you can model the space of possible actions and validate controls against it.
AI agents break this separation. If you are a CISO, Chief Compliance Officer, or head of enterprise architecture in a regulated industry, this convergence is not a future concern — it is a present architectural vulnerability.
The Old Model: Separable Concerns
In a traditional enterprise architecture, a software agent's behavior is bounded by its code and configuration. An automated trading system executes the logic its developers wrote. A claims-processing pipeline follows the rules it was programmed with. A data integration service moves records according to its configuration.
For these systems, security and governance address genuinely different questions. Security already handles two dimensions of authorization: data access (Can this system read the database?) and function access (Can this system execute a trade?). Governance asks a further question: Given the conditions right now, should this specific action proceed? The security team manages firewalls, credentials, and access control lists. The compliance team manages policies, audits, and regulatory filings. They coordinate, but they operate independently — because the system's behavior is bounded by code and configuration. Once you've verified what the code does and what it can reach, you've answered both questions.
This separation is so deeply embedded in enterprise architecture that it shapes organizational structure, procurement categories, and regulatory frameworks. Security is a technical function. Governance is a legal and compliance function. They report to different executives, buy different tools, and operate on different timescales.
The New Reality: Collapsed Boundaries
An AI agent doesn't execute predetermined logic. Its action selection is probabilistic and context-contingent: the same tool access can yield materially different actions depending on prompts, retrieved context, and model output. The same agent, with the same credentials and the same resource access, can take fundamentally different actions depending on what it's asked, what it retrieves, and what its reasoning model produces.
By "action" I mean any tool invocation or external side effect — write, send, approve, execute, publish — that changes state outside the model. This is the boundary that matters.
This means security — in the traditional IAM sense of controlling resource access — is no longer sufficient to govern what the system does. An OAuth token that grants an agent access to a patient records database tells you nothing about whether the agent will synthesize a diagnosis, generate a treatment recommendation, or trigger an automated referral. The identity layer confirms the agent can open the door. It does not authenticate the intent of what happens next.
In healthcare, "access to records" can be fully legitimate while "issuing a referral" or "ordering a diagnostic test" may require additional policy conditions, clinical approvals, or patient consent checks — at the moment of execution, not after the fact. In credit underwriting, an agent with access to applicant data and scoring models can generate a decision that creates immediate regulatory exposure under fair-lending rules if no pre-execution policy check governs which factors it weighed and why. In both cases, the agent is perfectly secure. It is not governed.
In financial services, the pattern is the same: a security team grants an AI agent access to a financial database. The agent has valid credentials, proper SPIFFE attestation, and a well-scoped OAuth token. From a security perspective, everything is correct. The agent then uses that access to generate a risk assessment that triggers an automated portfolio rebalancing. Was that action permitted? The security layer has no opinion — the agent had access to the data it needed. The governance layer, if it exists as a separate system, either doesn't see the action in real time or sees it only after the fact, when the rebalancing has already executed.
The gap between "authorized to act" and "authorized to act in this context" is where regulated enterprises face their actual risk. Traditional role-based access control can answer whether an agent is permitted to call a function. It cannot answer whether this particular invocation, given these specific runtime conditions, is permitted under governing policy. For AI agents, that gap can only be closed at the moment the agent proposes an action and before that action produces external effects.
Why Deterrence Doesn't Bridge the Gap
For human actors, organizations can tolerate some separation between security and governance because humans are subject to deterrence. A financial analyst who has access to trading systems is also subject to compliance training, personal liability, professional reputation, and the knowledge that violations will be investigated. The governance layer operates partly through cultural and legal mechanisms that don't require real-time technical enforcement.
AI agents are not subject to deterrence. They have no reputation to protect, no career to lose, no fear of consequences. They also lack the common-sense judgment that human actors apply instinctively — a bartender recognizes an intoxicated patron and stops serving; an AI agent with "permission to pour drinks" has no comparable contextual brake. Agents will attempt whatever action their reasoning model produces, as long as the technical infrastructure permits it. This means governance cannot rely on the agent "choosing" compliance — it must be enforced architecturally, at the same boundary where security controls operate.
This isn't a theoretical concern. It's a structural property of any system where the governed entity is a probabilistic model rather than a human being. For human-governed systems, you can separate the lock on the door (security) from the rules about what you do inside (governance) because the person inside has reasons to follow rules even without a lock on every action. For AI-governed systems, every action needs a context- and policy-aware lock — and the lock must check both access rights and policy compliance simultaneously.
What This Means Architecturally
If runtime governance — pre-execution authorization of agent actions — and security are the same enforcement problem, they need to be solved at the same architectural layer. This has several implications.
The enforcement decision must be logically unified. Even if implemented as multiple distributed enforcement points, pre-execution authorization for AI agents must co-evaluate both identity/access questions (Is this agent who it claims to be? Does it have credentials for this resource?) and policy-authorization questions (Is this specific action permitted under current governing policy?). In practice, this looks like an authorization gateway sitting between the agent's planner and any side-effectful tool calls — evaluating both access rights and policy compliance before the action produces external effects. Two architecturally separate checkpoints — one for security, one for governance — create a gap between them where unauthorized actions can execute.
Policy and credentials must be co-evaluated. The authorization artifact that proves an action was permitted must bind identity attestation (who the agent is), access attestation (what it can reach), and policy attestation (what rules authorized this specific action) into a single, verifiable object. If these attestations live in separate systems with separate verification chains, the audit trail has structural gaps.
Organizational separation becomes a liability. When the security team manages access controls and the compliance team manages governance policies, and these are implemented as separate technical systems, neither team has complete visibility into the actual authorization state of AI agents. The security team sees valid credentials. The compliance team sees policy definitions. Neither sees the runtime intersection — whether a specific action by a specific agent was both technically accessible and policy-authorized at the moment of execution.
Standards must converge. The current standards landscape reflects the traditional separation: identity standards (OAuth, OIDC, SPIFFE) on one side, governance frameworks (NIST AI RMF, ISO 42001) on the other. For AI agents, we need standards that address the intersection — specifications for authorization artifacts that simultaneously attest identity, access rights, and policy compliance in a single verifiable object. One approach to this convergence is the concept of a Proof-Carrying Decision: a self-contained, replayable authorization artifact (inputs, identity, policy references, and decision result) that a third party — whether an internal auditor, a regulator, or an automated compliance system — can verify independently, after the fact, without access to the original system.
Authorization must be replayable. Traditional system logs record what happened. For AI agents, that is insufficient — auditors and regulators need to verify not just that an action occurred but why it was authorized: which policy version applied, what inputs the agent had, and whether the same inputs would produce the same authorization decision today. Replayable authorization artifacts are not an enhancement to existing audit logs. They are a new dimension of compliance infrastructure that agentic architectures require and traditional logging cannot provide.
What to Do Monday
Practically: treat every tool call as a transaction. Require a decision-time authorization check that binds (1) agent identity, (2) tool and resource scope, (3) the policy version in force at execution time, and (4) the proposed action parameters — then log a replayable artifact that a regulator or auditor can independently verify. If you can't do that for a given agent deployment, you're doing access control, not agent governance. Post-hoc monitoring can prove you had a problem; it cannot prevent the side effect that already happened.
The Uncomfortable Implication
The convergence of security and governance at runtime means that organizations deploying AI agents need to rethink not just their technical architecture but their organizational structure. A model where the CISO owns security controls and the Chief Compliance Officer owns governance policies, and these are implemented as separate technical layers, will produce structural blind spots for AI agent deployments.
This doesn't mean these roles should merge. It means the technical enforcement layer they rely on must be unified. The authorization boundary where AI agent actions are evaluated before execution must enforce both access controls and governance policies simultaneously — and produce a single audit artifact that proves both were satisfied.
Organizations that maintain the traditional separation will face a specific and predictable failure mode: AI agents that are fully authorized from a security perspective taking actions that are unauthorized from a governance perspective, with no technical mechanism to prevent it in real time. The breach won't be a security breach in the traditional sense — credentials won't be compromised, access controls won't be bypassed. It will be a governance breach: a properly authenticated, properly credentialed agent taking an action that no policy authorized, discovered only after the fact.
What Comes Next
The recognition that runtime governance and security are inseparable for AI agents is beginning to surface in standards discussions. NIST's National Cybersecurity Center of Excellence recently published a concept paper on AI agent identity and authorization that addresses identity and access management for agentic architectures. The paper covers identity, authentication, and access delegation thoroughly. The missing piece — and the one that its readers should be pushing for — is decision-level authorization: verifying not just that an agent has valid credentials, but that each specific action is permitted under governing policy before it executes. That is where the traditional boundary between security and governance dissolves, and where the architectural gap is widest.
This is not merely a feature request. It's an architectural recognition that the boundary dissolves when the governed entity is a probabilistic, context-contingent system. The organizations and standards bodies that recognize this convergence early will build more defensible AI architectures. Those that maintain the traditional separation will build systems with structural governance gaps that no amount of post-hoc monitoring can close.
Either your architecture evaluates actions before execution — or your agents are already operating in the authorization gap.