AI Governance Has to Move From Policy to Runtime

TL;DR

Written AI policy stops working the moment an agent can act, and most governance programs never notice, because the policy still reads fine. It says agents shouldn't share confidential data externally; nothing in the tool-calling path checks that at the moment it happens.

That gap is the difference between a rule and a control. A rule is something a person is supposed to remember. A control runs at the exact moment an agent tries to read, send, or write, whether anyone is watching or not.

The common view is that a clearer policy document or a more thorough model review closes this gap. It doesn't, because neither one executes. OWASP says the same thing in one line about excessive agency: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not."

We're not saying stop writing policy. It still sets the target. But it has to compile into something running in the same path as the action, or it stays decoration.

Start by asking whether any single line of your AI policy would actually stop an unauthorized action today. If you can't answer that in a sentence, you don't have runtime governance yet.

Overview

Most enterprise AI policy was written for systems that only talked. Don't paste sensitive data into unapproved tools, don't trust outputs without review, don't deploy anything without a security sign-off. None of that is wrong, and none of it says what happens the moment an agent can act on its own.

An agent connected to Gmail, Salesforce and a knowledge base reads records, drafts messages, and in a growing number of deployments sends them. The policy document has an opinion about whether that's allowed. The tool-calling path, in most organizations, has none.

Four questions have concrete answers. Where can the authorization check physically sit, and what does each placement miss. What can a decision return besides allow and deny. Which lines of the EU AI Act change what engineering builds rather than what compliance files.

Motivation

The first wave of enterprise AI was copilots and chat. They were useful, and the human stayed the execution layer: a model proposed, a person decided. Agentic systems move the agent into that layer, holding credentials, calling APIs, chaining steps across systems that used to be reserved for a person or for code an engineer reviewed before it shipped.

Traditional software fixes the set of reachable states at design time: engineers decide which buttons exist and which roles can press them, and someone reviews that before release. An agent composes a sequence nobody wrote down, generated fresh from the request, the available tools, and whatever context it retrieved. So the unit of governance shifts from the screen a person can reach to the specific action an agent is attempting, in the moment it attempts it.

The regulation has already conceded the point. The EU AI Act's own definition of an AI system, in Article 3(1), is "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment." Autonomy is in the definition, not in an annex of edge cases.

Take a support agent connected to Zendesk, Slack and a knowledge base. Summarizing a ticket is low risk. Notifying a channel the whole company reads, or putting a customer's account details in an outbound message, is not. A policy that says "agents should be used responsibly" doesn't tell the runtime which is which.

The Runtime Governance Layer

Runtime governance decides what an agent is allowed to do at the moment it tries to do it, weighing who invoked the agent, which agent is acting, which tool and data are involved, what the action would do, and the rules attached to that workflow.

A plain allow-or-deny model runs out of expressiveness fast. Real deployments need finer outcomes: allow a read but not a write, allow a draft but block automatic send, redact a field, or let an action through while flagging it for later review. Access control settled this shape long ago. NIST's ABAC guide, SP 800-162, defines the decision component as one that "computes access decisions by evaluating the applicable" digital and meta policies, and the companion component as one that "enforces policy decisions in response to a request from a subject requesting access to a protected object." Keep the two apart and the rules can change without rewiring every agent.

Figure 1 — A tool call passing through a runtime decision before it reaches Gmail, the CRM, or the database. The exact rules matter less than the fact that every branch gets evaluated and logged before the side effect happens.

NIST's zero-trust architecture, SP 800-207, adds the detail most agent deployments skip. It splits the decision side into a component that renders the verdict and one that establishes the session, and specifies that the deciding component "makes and logs the decision (as approved, or denied)." Logging is part of what the check is, not a feature bolted on after it.

Where the Check Can Live

There are four places to put an authorization check in an agent stack, and we'd argue only two of them are controls. They are the four terms of the enforcement point dimension in the Agent Access Control Taxonomy, named in the first column below.

Table 1 — Four placements for an authorization check. The first two are advisory. Real deployments need the third and fourth together, because the provider's scopes are rarely granular enough on their own and the gateway cannot enforce what the provider doesn't distinguish.

OWASP's Excessive Agency entry, LLM06 in the 2025 Top 10 for LLM applications, traces the same failure to three roots: excessive functionality, excessive permissions, excessive autonomy. Its guidance on placement is blunt. Authorize downstream rather than relying on the model to decide whether an action is allowed.

The protocols have already standardized the wire shape of a runtime decision. The MCP authorization specification requires servers to validate that access tokens "were issued specifically for them as the intended audience," and defines what a server returns when a caller's token is valid but insufficient: HTTP 403 with error="insufficient_scope" and a scope parameter naming what the operation needs.

Tool boundary <-- 403 insufficient_scope, scope="files:write" Agent --re-authorize (old scopes UNION challenged scope)--> Authorization server <-- token (may be a subset of the request) Agent --retry--> Tool boundary --> result, or a terminal 403 The denial names what was missing, so the retry is targeted rather than a broad grant up front. -->

Figure 2 — A step-up authorization exchange as MCP specifies it. The denial carries the missing scope, which is what makes narrow initial grants practical instead of merely virtuous.

On token passthrough, where a server forwards a credential it never validated, the same specification says servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server," and lists the first consequence as an audit problem: downstream logs "may show requests that appear to come from a different source with a different identity."

Core Capabilities

Agent Identity

We think this is the one to get right first, because everything downstream reads from it. Without a distinct identity per agent, a log shows a user performing an action the user only delegated, or an application calling an API with no record of which agent initiated the request.

A shared service account or a broad API token collapses every agent and every user behind one identity at the exact moment that matters, the pattern the taxonomy files under aact:identity-model/shared-service-account. An agent acting for a junior employee and one acting for an admin present the same credential, and neither the downstream system nor the audit trail can separate them. So agents get created, reviewed, monitored and revoked like actors, with the delegation chain preserved from the human who asked through to the system that was touched.

Permission Boundaries

An agent shouldn't inherit everything the user or application it runs through can do. It needs the minimum its workflow requires, which means thinking more granularly than "it can connect to Salesforce." Read records, or update them. Retrieve documents, or share them externally.

MCP's security guidance lists a cost of getting this wrong that has nothing to do with breach: a single omnibus scope "masks user intent per operation." A grant of files:* tells a later reviewer nothing about what any given call was for. A read-only connection to a customer database and one that can run arbitrary updates both show up as "database access" in a vendor review, and they are not the same exposure.

Human Approval Gates

"Human in the loop" is one of the most common requirements in AI governance and one of the least specified. Runtime governance has to make it concrete: which actions need approval, who can approve them, what the approver actually sees, how long an approval stays valid, and how the decision gets logged.

What the approver sees is the part teams skip and later regret. A prompt that says only "the agent wants to send an email" gives a reviewer nothing to decide on, and over weeks it trains them to click approve without reading. Regulators have named that failure directly, and we get to the wording below.

Approval should be risk-based. Review everything and the agent stops being useful. Review nothing and the policy is decoration. An agent might draft a CRM update without review and still need a human before that update writes back.

Context-Aware Decisions

The same action can be low or high risk depending on who's doing it, what data's involved, and where it's going. Posting in a test Slack channel isn't posting company-wide. Emailing a teammate isn't emailing a customer. So a rule weighs agent identity, user role, data classification and destination together, rather than resolving a static role assignment. That is also what lets one rule scale across many agents instead of becoming a pile of agent-specific exceptions: "external sends of confidential data require approval" governs every agent that ever tries it.

Auditability

A useful trail captures who invoked the agent, which agent acted, what tools it called, what data it touched, which decisions applied and what it ultimately did. That is not every prompt and every document forever; capture references and verdicts, not copies of the sensitive material.

What it buys shows up during an incident. When an agent does something unexpected, the cause was user intent, retrieved context, model output, a permission gap or a missing approval, and each has a different fix. A log that can't tell a prompt-injection vector from a misconfigured permission leaves the team guessing.

Common Failure Modes

The same failure modes keep showing up, because they're the predictable result of governance sitting in a document instead of in the execution path.

• Privilege inheritance. An agent gets the full access of the user or service account it runs under. The symptom is a permission review that finds no rule was broken, because none was written.
• Confused-deputy exposure. Untrusted content the agent retrieves steers it into an action the user never asked for. MCP's security guidance documents a concrete version at the protocol layer: a proxy server with a static client ID, dynamic client registration, and a third-party consent cookie can hand an attacker an authorization code with no consent screen shown. The fix there is per-client consent checked before the upstream redirect, which is a runtime check, not a policy line.
• Approval fatigue. Oversight is technically present but so frequent and so context-poor that reviewers approve by reflex. The tell is an approval queue with a near-100% approval rate and a median decision time under two seconds.
• Attribution gaps. Logs show a user or an application acting, with no record of which agent initiated the request or under whose delegation. A confused deputy and a plain over-grant both present as "the agent did something it was allowed to do," and only the delegation chain separates them.

Each of these maps to exactly one capability above, which is a useful check on its own: if you can't say which capability would have caught a given failure, you probably don't have it yet.

Principles and Frameworks

None of this departs from the AI risk frameworks enterprises are already adopting; it gives them teeth. NIST's AI RMF 1.0 organizes its work around four functions: govern, map, measure and manage. The first three produce decisions and intentions, and a compliance team can own most of that directly. Manage is where risk gets responded to, and the framework's own description is about resourcing rather than documenting: it "entails allocating risk resources to mapped and measured risks on a regular basis and as defined by the GOVERN function." Its subcategories include post-deployment monitoring plans and mechanisms for communicating incidents, neither of which a document performs on its own.

SP 800-162 anticipated the deployment shape too: the deciding and carrying-out components may be "physically and logically separated from each other," with a central decision service handing verdicts to whatever sits in the request path. That is what an agent gateway needs, and it predates agents by a decade.

What the Regulation Actually Requires

The articles divide cleanly into filings and engineering, which the summaries tend to blur.

Table 2 — The split that matters. Article 113 as amended sets 2 December 2027 for Annex III high-risk systems and 2 August 2028 for high-risk AI embedded in regulated products; Article 50's transparency duties were not moved and apply from 2 August 2026.

Article 14 reads like an engineering ticket. High-risk systems must be built so they "can be effectively overseen by natural persons during the period in which they are in use," with measures "commensurate with the risks, level of autonomy and context of use." Article 14(4) then requires the assigned person be able to "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output," and to stay aware of "the possible tendency of automatically relying or over-relying on the output" of one.

Writing "a human is in the loop" into a policy document satisfies none of that. An approval gate that surfaces the recipient, the affected records and the reason the system flagged the call does. Article 26(2) adds the personnel half, requiring deployers to "assign human oversight to natural persons who have the necessary competence, training and authority." Article 12 requires the system to "technically allow for the automatic recording of events (logs) over the lifetime of the system," and Articles 19 and 26(6) put a floor of "at least six months" under how long those logs are kept.

From Use Case to Infrastructure

Every deployment mixes tiers inside one agent. A finance agent that reads invoices all day is harmless until the moment it prepares a payment. An engineering agent summarizing incidents is low risk until it opens a pull request against production. Neither is made safe by the model; it comes down to whether the consequential step is gated and the routine ones aren't.

Enterprise security went through this shift already. Password policy gave way to identity systems that enforce it. The written rule becomes a specification, and the control built from it is what an auditor can point to.

Where Fabriq Fits

Agentic Fabriq covers a narrow slice of this: it holds each user's credentials in a vault and attaches them server-side at the moment of the call, so the agent never handles the secret, and it makes an agent's effective tool list the intersection of the user's scopes and the agent's. Every call carries two identities, the agent and the acting user, plus an audit record, which is what closes the attribution gap above.

It is not a substitute for the provider's own grant. Clearing a vault copy is not revoking a grant upstream, so the call to the provider's revocation endpoint is still yours to make.

Frequently Asked Questions

What is runtime AI governance? Evaluating each attempted action against identity, permissions and context at the moment it is attempted, rather than reviewing the system that might attempt it. The test is whether the check returns a verdict the agent cannot ignore.

Isn't a system prompt enough to constrain an agent? No. A prompt is advice to a component that also reads untrusted input, so anything in the prompt competes with anything in a retrieved document.

Where should the authorization check sit? At the boundary where the credential is attached, backed by the narrowest grant the provider will issue. A framework wrapper is not sufficient on its own, because the next code path added won't go through it.

Does the EU AI Act require approval workflows? Not in those words. Article 14 requires that high-risk systems be designed for effective oversight by people who can disregard, override, or reverse the output, and Article 26(2) requires deployers to assign that oversight to people with competence, training, and authority. A risk-based approval gate is one way to meet it; a paragraph in a policy document is not.

What did the Digital Omnibus change? Dates, not duties. Article 113 now sets 2 December 2027 for Annex III high-risk systems and 2 August 2028 for high-risk AI inside regulated products. Prohibitions have applied since 2 February 2025, governance and general-purpose model rules since 2 August 2025, and Article 50 transparency from 2 August 2026.

Conclusion

The enterprises that get this right won't be the ones with the longest AI policy. They'll be the ones that can turn policy into something that runs: who's acting, on whose behalf, with which permissions, against which systems, and with what audit trail, answered at the moment an agent tries to act, not after.

That takes infrastructure: agent identity, granular permissions, approval gates and audit trails wired into the path the agent actually uses. Not products bolted on afterward, but the connective tissue that lets an agent ship with the same confidence as anything else touching production.

Sources

All URLs read 2026-09-29.

• NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0 — the govern, map, measure and manage functions; section 5.4 on what MANAGE entails; MANAGE 4.1 post-deployment monitoring.
• NIST SP 800-162, Guide to Attribute Based Access Control — the decision and carrying-out components, their definitions, and the note that they may be physically and logically separated.
• NIST SP 800-207, Zero Trust Architecture — the split on the decision side, and the requirement that the deciding component makes and logs the approve-or-deny verdict.
• OWASP LLM06:2025, Excessive Agency — the definition, the three roots (functionality, permissions, autonomy), and the instruction to authorize downstream rather than in the model.
• MCP Security Best Practices, specification 2026-07-28 — the confused deputy conditions and mitigation, the token passthrough prohibition, the audit consequences, and scope minimization.
• MCP Authorization, specification 2026-07-28 — MCP servers as OAuth 2.1 resource servers, audience validation, and the 403 insufficient_scope step-up exchange in Figure 2.
• EU AI Act, Article 3 (Definitions) — "varying levels of autonomy" in the definition of an AI system, and the provider/deployer split.
• EU AI Act, Article 12 (Record-keeping) — automatic recording of events over the lifetime of the system.
• EU AI Act, Article 14 (Human oversight) — effective oversight, measures commensurate with autonomy, automation bias, and the power to disregard or override.
• EU AI Act, Article 19 (Automatically generated logs) — the six-month minimum retention for providers.
• EU AI Act, Article 26 (Obligations of deployers) — paragraph 2 on competence, training and authority; paragraph 6 on deployer log retention.
• EU AI Act, Article 50 (Transparency obligations) — disclosure to people interacting with an AI system, in force 2 August 2026.
• EU AI Act, Article 113 (Entry into force and application) — the amended text setting 2 December 2027 for Annex III and 2 August 2028 for Annex I.
• Agent Access Control Taxonomy — the nine dimensions; the enforcement point terms naming the four placements in Table 1, and the identity model term for a shared service account.
• European Commission, Regulatory framework for AI — the AI Omnibus timeline change, the 7 May 2026 political agreement and its entry into force on 27 July 2026.