AI agent governance is moving from reviews to runtime

AI agents can be created in an afternoon and start acting on finances, customer relationships or regulated processes immediately. A governance process that reviews systems periodically cannot operate at the same pace. “Applying traditional strategic governance to AI, the way you would with applications and systems, just doesn’t work for AI agents,” says Philipp Herzig, CTO of SAP, which sells AI, architecture, process, identity and governance technology and benefits commercially as enterprises invest in these controls. The change is architectural: enterprises need continuous discovery, business context, behavioral evidence and controls that can act while an agent is executing.

AI agents are moving governance from review time to runtime

The timing problem comes from autonomy because an agent can act between formal reviews. “Things happen so much faster once you introduce autonomy. The agent acts on your behalf, at times without your explicit approval. With proactive real-time operational governance, you are preventing issues rather than chasing them,” Herzig says. Large language models already complicate AI governance, while agents add independent execution: a system can make decisions and pursue work between governance reviews, shortening the interval between an AI decision and its business consequence.

That shorter interval matters most where accountability is already formalized. Banks operate under model-risk guidance including SR 11-7 and SR 26-2; drug manufacturers have GxP and FDA requirements; government organizations face FedRAMP, authority-to-operate requirements and data-sovereignty rules. The EU AI Act and NIST AI Risk Management Framework also establish expectations around documentation, risk classification and human oversight. Financial services, healthcare and pharmaceuticals, and the public sector consequently face particularly strong pressure to make AI activity accountable.

Pharmaceutical production makes that accountability requirement concrete because governance has to preserve a traceable history throughout the process. “Think about the pharmaceutical industry, where you have a chain of custody,” Herzig says. “If you make drugs, you have to know every point where the product was touched. You cannot have blank spots in a regulated business process.” A non-deterministic agent, whose response can vary across apparently identical interactions, makes reconstruction harder because organizations may have to explain why the system behaved as it did.

That reconstruction requirement exposes the limits of governance mechanisms built around discrete reviews. Registries establish known assets, session logs retain evidence, checklists and templates structure reviews, and deployment-time permissions constrain initial access. Post-event reconstruction can explain some incidents after they occur, but autonomous execution requires these measures to work as a continuous system because the governed estate, an agent’s behavior and its use of granted authority can all change after approval.

Continuous discovery tracks an estate that can change in an afternoon

A continuous system starts by knowing what currently exists. Enterprises need to answer four questions at any time: which agents exist and what each is for; which data and systems they can access; which business processes they participate in; and whether their behavior remains within policy. The first question enables the other three because an unknown agent cannot be connected reliably to access, process or policy information.

The need for a current inventory grows when employees can create autonomous systems directly. Chat interfaces and copilot tools can let someone assemble a functioning agent in an afternoon and immediately put it to work. Herzig gives the example of invoice handling: “Say someone decides they no longer want to handle invoices, so they build a quick agent in a copilot tool and hand the work over.” That decision can introduce autonomous activity into finances and customer relationships before a centralized governance function knows the entity exists.

Because creation can happen outside a planned release process, discovery has to follow it continuously. “You can’t manage what you can’t see,” Herzig says. “If I can’t automatically discover and maintain a working inventory of AI assets or AI agents, I don’t know what I‘m governing.” For technology leaders, the perimeter now extends beyond an approved deployment pipeline, which may cover centrally released systems while missing agents created through tools already available to employees.

That wider perimeter also includes the infrastructure around agents. Herzig estimates that agents represent “less than a third” of the enterprise AI-governance scope. The rest includes large language models; Model Context Protocol (MCP) servers, which connect AI systems with applications and other resources; agent-to-agent protocols; and multi-agent orchestration, in which multiple agents divide and delegate work. Governance discovery therefore has to identify autonomous actors and the infrastructure through which they communicate and act.

Delegation makes that broader inventory more consequential because the agent receiving a task may differ from the one performing a later action. An enterprise may know the agent that received the original request while still needing to establish which other agent acted, which system it reached and under whose authority. As autonomous entities receive access outside central visibility, an inventory updated during planned deployment reviews cannot reliably represent the operational environment.

SAP’s AI Agent Hub illustrates one vendor approach to cross-platform discovery. SAP positions the hub as an entry point that can identify agents beyond its own products, supporting SAP’s commercial governance offering. “Our discovery already covers ServiceNow, AWS, Microsoft and Google agents, well outside the SAP ecosystem,” Herzig says. Cross-platform discovery matters because an enterprise inventory has to follow the organization’s actual technology mix.

Once discovery establishes presence, governance still needs to establish consequence. Knowing that an invoice agent exists does not establish who owns its decisions, what delegated authority it carries, which workflow depends on it or what else could fail if its behavior changes. Answering those questions requires connecting the inventory to enterprise architecture and business processes.

Governance maps assets to processes, identity and ownership

The inventory becomes actionable when each asset gains business context. “Having a registry is one thing, and positioning that estate in the context of your business is another,” Herzig says. “Knowing which agents sit inside which processes and which applications run on top of them answers the harder questions.” Once an agent is mapped to processes, applications and systems, teams can identify dependencies and its potential blast zone, meaning the business operations and technology components exposed if the agent behaves incorrectly.

Those dependencies provide the basis for assigning ownership. Accountability needs to connect to the agent and the workflow in which it operates, including the guardrails around its behavior and the authority delegated through a user role. An agent working with invoices, for example, has to be understood through the business workflow and permissions that make its actions consequential. Asset ownership by itself leaves unanswered who is responsible for the process decisions the agent performs.

Connecting responsibility and permission brings identity and access management (IAM), the discipline used to control identities and their access, into the governance model. IAM has primarily been designed around people, while autonomous entities can pursue assigned goals using delegated permissions. An agent may use those permissions in unexpected ways, including attempts to find another route when an API restriction prevents progress. Teams therefore need to understand whose authority the agent exercises, what access follows from it and whether actual use stays consistent with the intended role.

Delegation further complicates that identity model under multi-agent orchestration. One agent can accept a task and delegate part of it to another, separating the origin of the request from the entity that ultimately takes an action. Responsibility and attribution then depend on retaining the relationships among the agents, their identities, the workflow and the delegated permissions. Without those relationships, a registry can show that several agents exist while leaving the chain of responsibility unclear.

SAP spreads these forms of context across several products, all part of its commercial technology portfolio:

The product arrangement reflects a broader architectural requirement because operational decisions about an agent depend on information that traditionally lives in separate architecture, process, identity and workforce systems. Connecting those systems makes risk analysis more specific: an unknown autonomous entity presents a discovery problem, while a known agent attached to an application, workflow, owner and identity can be evaluated through its dependencies and likely impact. The same context gives continuous monitoring a structure because raw activity becomes meaningful when tied to the process the enterprise cares about.

Process-level telemetry can govern behavior and prove business value

Once an agent has business context, monitoring can compare its granted access with the access and behavior it actually exhibits. Permissions can remain formally unchanged while an evolving agent changes how it uses them, so continuous telemetry gives governance teams evidence of that divergence. Teams can then evaluate whether access remains appropriate as execution changes.

Agents already generate substantial low-level evidence. “Agents produce plenty of base telemetry, including token input and output, model usage over time, tool call health, and success rates,” Herzig says. Those signals show how an agent operates, and their governance value increases when attached to the process in which the agent acts. Tool-call success, for example, becomes more useful when teams can connect it to whether a governed workflow completed correctly.

That process connection also gives teams a baseline for judging results. Process benchmarks can be established “before it goes live,” giving the organization a reference point for evaluating conformance and business results after deployment. Measures can then aggregate at the process level and, beyond that, across an application portfolio at the business-capability level. Monitoring can consequently show what changed in the operation while preserving the technical telemetry needed to understand why.

Herzig illustrates that connection with a workflow whose staffing changes from six people to two people working with agents. “The question is whether you can aggregate that detail against a process that six people used to run and now runs with two people and agents in the loop. Proving the efficiency gain requires tooling that rolls those signals up to the level where business value becomes visible.” Token counts or model usage alone cannot establish that efficiency gain; process-level measurement connects agent execution to the changed operating result.

Because process conformance and business value both depend on actual execution, the same evidence can support governance and business assessment. A team needs to know whether the agent followed permitted paths, while leaders need to know whether the resulting process improved. Once architecture and process mappings connect telemetry with business activity, both assessments can use the same operational record. Governance data can then support ROI decisions as well as evidence required for incidents or audits.

That shared evidence changes when measurement should be designed. If a benchmark is established before deployment, teams know which outcomes and policy conditions they intend to measure before autonomous execution begins. Designing measurement afterward forces teams to reconstruct the baseline and the agent’s effect from the records already available. Current evidence and process context then become prerequisites for intervention because a runtime control needs both to determine whether an action is allowed.

Runtime enforcement depends on discovery, context and evidence

With current evidence available, runtime enforcement can move governance from recording behavior to intervening during execution. If an agent attempts to reach a restricted system, post-event discovery leaves remediation to the owner of the affected process. A runtime control can evaluate the action as it occurs and prevent a disallowed step before the system is reached.

That intervention becomes more important as behavior changes after deployment. “Agents keep learning, keep adjusting, and keep drifting,” Herzig says. An entitlement approved when an agent was released may remain technically available even as the way the agent uses it evolves. Conventional reconstruction is particularly difficult with non-deterministic systems, so deployment-time permissions and later session analysis cannot by themselves establish that policy held throughout execution.

Herzig consequently treats runtime control as essential: “Without the ability to measure that and enforce controls at runtime, you don’t have AI governance.” Measurement supplies the information required for enforcement because a control needs to know which agent is acting, its permitted role, the process context and what its current behavior indicates. With those inputs, the control can determine whether a particular action violates policy.

SAP describes its governance development as moving from visibility into the AI estate and its associated risk toward runtime control and management, an evolution that also expands the scope of SAP’s commercial governance offering. In SAP’s deployment path, SAP Integration Suite can build and manage MCP servers and requires verification before those servers enter production. Joule Studio applies verification before agents leave a test environment. SAP also plans verification seals explicitly grounded in regulations such as the EU AI Act.

Those deployment gates establish a controlled starting state, while continuous intervention addresses behavior after release. SAP says runtime enforcement capabilities and guardrails are planned before the end of 2026, so these remain future elements of its stated roadmap. Keeping that timing clear matters operationally because verification before production and enforcement during later execution solve different parts of the governance problem.

Runtime controls therefore depend on the layers established earlier. Discovery tells the control system that the agent exists; architecture and process mappings show what its actions affect; ownership and identity establish responsibility and delegated authority; monitoring shows what it is actually doing. Together, those inputs give the intervention point enough information to make a policy decision during execution.

Enterprise examples turn governance into an operating discipline

The same layered model is already shaping repeatable operating practices inside enterprises. AmTrust Financial Services expanded its SAP LeanIX enterprise-architecture practice into AI governance ahead of EU AI Act obligations. It created an AI inventory, classified applications by risk and established a cross-functional AI-governance council. Those steps connect discovery and risk classification with an organizational structure that can make governance decisions.

CapitaLand addresses the scaling problem through reusable governance frameworks across business units operating in more than 260 cities. As AI adoption grows, rebuilding a governance method for every deployment creates its own scaling constraint. Reusable frameworks give distributed business units a repeatable structure as their use of AI expands.

These cases demonstrate inventory, risk classification, coordination and scalable governance structures, while complete runtime enforcement represents a further layer of the operating model. Enterprises can mature individual layers as the wider model develops. Organizational coordination is part of that work because enterprise architects, CISOs and compliance chiefs hold different pieces of the information and authority required to govern an autonomous system.

That distribution of responsibility also helps explain the emergence of AI centers of excellence in large organizations. Continuous governance crosses architecture, security, compliance, identity and process management, so gaps can appear between functions even when each team performs its own role correctly. A cross-functional operating structure gives those functions a place to coordinate decisions as agents are discovered, assessed, monitored and governed through their lifecycle.

Cross-vendor telemetry limits continuous governance

Once that operating model crosses technology providers, the hardest constraint becomes access to telemetry. Enterprises may discover agents across ecosystems, yet detailed behavioral and performance signals required for monitoring can remain inside individual vendor environments. Cross-vendor discovery consequently supplies part of the visibility required for enterprise-wide controls, while telemetry determines how much of the agents’ behavior can actually be assessed.

Herzig identifies this as an open ecosystem problem: “Where the industry needs more work is a stronger open agent ecosystem, because the granular telemetry required to access how agents are performing, monitor agent health and behavior, and the aggregation of this information into measurable business outcomes sits behind closed doors in each big tech environment. No organization runs purely on SAP or purely on Microsoft. Opening that up makes AI governance better for everyone.” As SAP’s CTO, Herzig has a commercial interest in interoperability that lets SAP’s governance products work across heterogeneous enterprise environments. The claim matters operationally because behavioral telemetry underpins policy enforcement and the process-level ROI measurements used to judge whether agents are delivering value.

Agent-to-agent protocols and MCP servers make that boundary more important as activity moves between platforms. An enterprise may discover participating entities yet still lack consistent evidence about what happened during delegation, which tools were called and how execution affected a process when different vendors expose different telemetry. Fully continuous governance therefore depends on visibility that follows agent activity across platform boundaries.

That dependency makes interoperability a governance requirement with direct effects on control quality. Discovery, context and runtime controls can continue to improve inside individual environments, but enterprise-wide governance remains constrained when the evidence needed to assess behavior stops at a vendor boundary. As agents act across systems and delegate across platforms, the effectiveness of the control layer depends on how much of that execution enterprises can actually see.

In conclusion

For executives, the shift to agentic AI changes governance from a periodic assurance exercise into an operating capability. Approval before deployment still matters, but it cannot account for agents that are created outside central release processes, change how they use existing permissions or delegate work across systems after they enter production.

The practical priority is to build the connections that make continuous governance possible: a current inventory of agents and supporting infrastructure, clear ownership and identity, mappings to business processes and applications, and telemetry that shows how autonomous systems actually behave. Runtime controls can then act on that context rather than applying policy without knowing the business consequence.

Regulated industries face the strongest immediate pressure because they already have to demonstrate accountability, traceability and control. But the underlying challenge extends to any enterprise giving AI authority over financial transactions, customer interactions or other consequential processes. Governance maturity will increasingly depend not only on whether an organization can approve an agent, but whether it can see, understand and control that agent throughout execution.

Cross-vendor visibility remains a constraint. As agents operate across technology platforms, governance will be only as continuous as the evidence enterprises can obtain across those boundaries. Technology leaders evaluating agentic AI should therefore treat discovery, interoperability, process context and runtime enforcement as architectural requirements rather than controls to add after deployment.