AI governance is becoming runtime infrastructure, not policy theater

At a glance

What this is: This analysis argues that AI governance is becoming runtime infrastructure because agentic systems now make decisions, call tools, and change enterprise systems in production.

Why it matters: It matters because IAM, security, legal, and compliance teams can no longer treat AI oversight as a policy exercise; they need controls that operate at the agent-tool boundary.

By the numbers:

• Around 23% are scaling agentic AI systems, according to Obot.
• Roughly 39% remain in experimentation, according to Obot.
• EU AI Act fines can reach up to €35M or 7% of global turnover for prohibited practices, according to Obot.

Context

AI governance is the control layer that determines how models, agents, tools, and data are approved, monitored, and constrained in production. In 2026, the problem is no longer whether organisations have a policy, but whether they can enforce it at runtime when an agent can call services, move data, or trigger business actions.

The article’s core argument is that static governance breaks down once AI becomes operational infrastructure. That creates a genuine identity and access problem as well as a compliance problem, because agents, skills, and tool chains now need inventory, authorization, auditability, and review just like other governed systems.

Key questions

Q: How should organisations govern agentic AI when authority changes at runtime?

A: Organisations should govern the conditions under which authority changes, not just assign a fixed autonomy label. That means tying decision authority, tool access, and accountability to the workflow and the risk of the action being taken. Static categories fail when the same agent can operate under different oversight expectations in different contexts.

Q: Why do agentic AI tools create more governance risk than copilots?

A: Agentic tools can decide and act, so a mistake becomes an operational event rather than a suggestion. That expands the blast radius of false positives, prompt manipulation, or bad telemetry. Copilots reduce search effort but leave execution with the analyst, which preserves clearer accountability.

Q: What are the signs that AI agent governance is too weak for production use?

A: Weak governance usually shows up as poor visibility into what agents can access, incomplete audit trails, and inconsistent oversight across security, legal, compliance, and operations teams. Another warning sign is when organizations cannot explain which datasets an agent used or why it took a specific action. Those gaps make investigation, containment, and compliance far harder.

Q: What should security teams do when AI agents need access to tools and data?

A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities. Limit tool scope, define approval gates, and require explicit revocation triggers for sessions and delegated access. The goal is to prevent broad runtime behaviour from inheriting static privileges.

Technical breakdown

Why runtime governance replaces static AI policy

Static policies assume a stable system that can be reviewed after the fact. Agentic AI breaks that assumption because a single workflow can invoke external APIs, write to systems, and pass through multiple tools in seconds. Governance therefore shifts from document approval to enforcement at the moment of action. The practical architecture is a control layer that sits between the agent and the tool, checks policy, records the transaction, and blocks or escalates risky steps before they execute.

Practical implication: move governance controls to the point where the agent actually acts, not to a policy document reviewed later.

Agent-tool gateways and machine identity controls

A gateway pattern works because it turns opaque tool use into governed traffic. The gateway can enforce identity checks, access scope, environment separation, logging, and policy decisions for each call an agent makes. This is where the identity angle becomes concrete: agent sessions need attributable credentials, tool permissions, and auditable authorisation just like human users, but with tighter scope and stronger runtime constraints. Without that, the organisation cannot reliably explain who or what changed a system.

Practical implication: treat agent credentials, tool permissions, and logs as first-class controls in the same way you treat privileged human access.

MCP as governed infrastructure, not just integration plumbing

Model Context Protocol standardises how agents discover and use tools, which makes it attractive for scale but also creates a governance boundary. If MCP servers are deployed without a control plane, teams can end up with scattered tools, inconsistent access rules, and weak visibility into what agents can reach. Used well, MCP becomes the place where policy, inventory, and audit converge. Used poorly, it becomes another layer of unmanaged shadow infrastructure with broad integration reach.

Practical implication: inventory MCP-connected tools and attach ownership, access rules, and audit logging before they spread across teams.

Threat narrative

Attacker objective: The objective is not a single exploit but uncontrolled AI-driven action that bypasses oversight, expands access, and creates operational or compliance harm.

1. Entry occurs when teams wire agents into external tools, internal services, and data sources without a governed control plane.
2. Escalation happens when those agents inherit broad permissions, allowing them to modify systems, trigger transactions, or call services beyond intended scope.
3. Impact follows when runtime actions create compliance exposure, data movement risk, and business damage that static policies cannot explain or reverse cleanly.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime governance is now the control plane, not an add-on. Once agents can call tools and change systems, governance that lives only in policy documents is functionally absent at the moment of risk. The field should stop treating AI governance as a committee output and start treating it as an enforced runtime layer with inventory, authorisation, and audit trails. Practitioners should design for action-time control, not retrospective assurance.

Agent identity has become a governance problem, not just an authentication problem. When an AI system can act on behalf of a business process, its access scope, session boundaries, and approval rules matter as much as the model itself. That makes the agent-tool boundary the place where identity governance, PAM, and AI oversight now intersect. Practitioners should expect agent credentials to be constrained, attributable, and reviewable like any other privileged workload identity.

MCP has created a new governed-infrastructure layer. Standardised tool discovery makes it easier to scale AI, but it also concentrates risk if the control layer is missing. The named concept here is governance debt at the agent-tool layer: the longer teams leave connectors, skills, and tool permissions unmanaged, the harder it becomes to classify risk or answer board questions. Practitioners should treat tool registries and gateways as mandatory governance infrastructure.

Shadow AI is really shadow infrastructure with identity consequences. Untracked agents, copilots, and tool integrations bypass review in the same way unmanaged cloud resources do, but with additional concerns around delegated action and data access. That means governance has to cover discovery, approval, and monitoring, not just policy publication. Practitioners should assume that if they cannot inventory an AI workflow, they cannot govern its access or explain its outcomes.

Boards now expect artifact-level evidence, not policy rhetoric. The article’s direction is clear: inventories, risk classifications, audit trails, and human oversight records are becoming the artefacts that matter. This aligns with broader AI governance frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001, where accountability depends on evidence. Practitioners should build control evidence into the operating model, not as a post hoc compliance project.

From our research library:

• 13% of organisations suffered breaches of their AI models, according to IBM's Cost of a Data Breach 2025 report.
• Read next: Agentic AI Identity Risk Board Briefing

What this signals

Governance debt at the agent-tool layer: the longer teams leave connectors, skills, and permissions unmanaged, the harder it becomes to classify risk or answer board questions. That problem is now visible in the gap between experimentation and production, and it will widen unless teams treat tool registries and gateways as core control infrastructure.

The practical shift for readers is from policy publication to evidence production. AI inventories, approval logs, and runtime audit trails are quickly becoming the artefacts that matter when boards, auditors, or regulators ask how AI systems are constrained and who can make them act.

52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey. That shift is a sign that governance is moving into the operational stack, where identity, access, and control enforcement actually live.

For practitioners

• Build an AI inventory with ownership and risk tiering Map every agent, tool, MCP server, and shadow AI use case. Record owner, access scope, data sensitivity, and risk classification so governance can be enforced consistently.
• Move approval to the agent-tool boundary Require runtime checks for high-risk actions such as payments, production code merges, or data deletion, and block execution until policy conditions are met.
• Constrain agent credentials to least privilege Issue tightly scoped identities for AI systems, separate environments, and revoke any connector permissions that exceed the specific workflow being executed.
• Centralise audit logging for every AI interaction Log tool calls, data flows, approvals, and policy decisions into SIEM or observability tooling so investigations can reconstruct what the agent did.
• Pilot a governed MCP control plane Route new agent integrations through a gateway that can enforce policy, reveal approved tools, and prevent unmanaged connector sprawl.

Key takeaways

• AI governance now fails or succeeds at runtime, because agents can call tools and change systems faster than static policies can respond.
• The article ties governance readiness to tangible operating risk, including inventory gaps, shadow AI, and weak approval flows at the agent-tool boundary.
• The control that matters most is enforced oversight over identities, permissions, and tool access, not another policy document or ethics statement.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Runtime Oversight: Runtime oversight is the monitoring and intervention layer that evaluates behaviour after a system is deployed. It covers logging, approvals, rollback, and escalation when an AI system interacts with live data, live users, or live tools, and it is essential when behaviour can change during execution.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It helps practitioners connect identity controls to the AI systems and workloads their programmes now have to govern.