An AI Agent Governance Framework for Enterprise Operations

Standards position current as of 3 September 2026.

Every AI governance framework your organization has adopted was written to govern what a model produces. An agent is judged by what it does, and that is why an organization mapped to the NIST AI Risk Management Framework or certified against ISO/IEC 42001 can still have no governance over the agents its teams are shipping. Research through 2026 found that the major frameworks contain almost no references to agents or agentic systems at all. The gap is being filled from an unexpected direction: NIST’s own concept work frames agents as identities that are commonly treated as generic service accounts with no dedicated authorization or accountability controls, and proposes applying existing identity standards to them. That is good news, because it means agent governance is not a new discipline. It is identity lifecycle management and change control, applied to an actor that acts on its own. We recommend you build it inside those two functions rather than as an AI program, because you already run both.

Overview

• Frameworks govern outputs, agents produce actions. That mismatch is the whole gap, and it is why existing mappings do not cover this.
• Treat every agent as a named identity. Its own registry entry, its own scoped permissions, its own audit trail.
• Decide whether the agent acts as itself or as the user. This single architectural fork determines both your blast radius and your ability to attribute anything.
• Nobody decommissions agents. The lifecycle almost always stops at deployment, which is how standing access accumulates.
• A prompt change is a production change. It alters system behaviour with none of the review a code deployment would get.

The 5 Why’s

This is written for IT directors, security leads, and compliance officers at organizations between roughly one hundred and a few thousand employees where agents have moved past experiment. The typical situation is a Microsoft or Google tenant with agent-building capability enabled, a handful of agents built by business teams, several more embedded in software you already licensed, and no register of any of them.

The trigger is usually a question nobody can answer. An auditor asks which automated systems can modify records. A customer’s risk assessment asks whether AI systems access their data. A board member asks who is accountable if an agent sends the wrong thing to the wrong party. Or an agent does something unexpected and the investigation reveals that its actions were logged under a shared service account.

Sector conditions raise the stakes. Healthcare organizations face agents touching clinical and patient data where an action carries care implications. Financial services firms face agents inside processes their examiners expect to be controlled and documented. Legal and professional services firms face client confidentiality obligations that never contemplated a non-human actor with mailbox access. Defense and aerospace suppliers face agents that may cross a compliance boundary, which pulls them into an assessment scope. Organizations with European market exposure face AI Act duties that reach agents by extension, since the definition turns on varying levels of autonomy and the high-risk obligations follow.

The consequence of no governance is not a rogue agent. It is an accumulation of automated actors holding standing access, taking actions nobody can attribute, that you cannot inventory when asked.

Why Your Existing AI Framework Does Not Cover Agents

Because the frameworks were built for a different object, and the standards bodies have said so themselves.

The NIST AI Risk Management Framework organises risk around design, development, deployment, use and evaluation of AI systems, with risk categories oriented to data quality, model behaviour, and output reliability. ISO/IEC 42001 specifies an AI management system, and it is genuinely valuable for the unglamorous discipline it imposes on onboarding, lifecycle and audit trails. Neither was designed for a system that selects a tool and takes an action in a production environment without a person in the loop. Community feedback gathered during 2026 held that the AI RMF, SP 800-53, and ISO/IEC 42001 do not adequately address the risk surface created by agents taking autonomous real-world actions.

What has appeared since is worth knowing. Singapore’s Infocomm Media Development Authority published the first comprehensive framework for agentic AI in January 2026, reaching a revised version in May after input from more than sixty organizations, and it requires each agent to carry a verifiable digital identity and an audit trail recording which agent acted under whose authorisation. NIST’s Center for AI Standards and Innovation launched an AI Agent Standards Initiative in February 2026 across three pillars covering industry-led standards, open protocol development, and security and identity research, with an accompanying concept paper proposing that established identity and access standards including OAuth, OpenID Connect, SPIFFE and SCIM be applied to agents directly. Finalised NIST guidance is not expected before 2027. OWASP published a Top 10 for Agentic Applications in December 2025, and its categories concentrate on tool misuse and supply chain rather than on model output.

Two conclusions follow, and they should shape what you build now. First, waiting for a finalised standard means waiting past your adoption curve, so the practical move is to build against the direction of travel rather than the destination. Second, that direction is identity infrastructure rather than model risk assessment, which tells you where this work belongs organisationally. It sits with the team that already governs service accounts and privileged access, alongside the rest of your cybersecurity program, not in a separate AI committee. If you have an ISO/IEC 42001 program, keep it and add agent-specific controls inside its management system structure, because the international ecosystem is building on 42001 as the governance foundation and supply chain partners are increasingly asking for alignment.

How Should an Agent Be Identified and Authorized?

With its own identity, its own least-privilege grant, and short-lived credentials rather than standing ones. Then one architectural decision that most organizations make by accident: whether the agent acts as itself or on behalf of a user.

That fork matters more than any other choice here. When an agent acts on behalf of a user, it inherits that user’s permissions, which is safer for data access because the agent can never reach anything the requester could not. It also destroys attribution, because every action appears in your logs as the user, and you lose the ability to distinguish what a person did from what an automation did in their name. When an agent holds its own identity, attribution is clean and reviewable, but you now have to grant it permissions deliberately, and the temptation is to over-grant so it works for everyone.

The workable pattern for most enterprise operations is both together: the agent holds its own identity for accountability, and authorization is still evaluated against the requesting user’s entitlements at the data layer, so the agent cannot become a permissions bypass. That combination is more work to implement and it is the only version that survives an audit question about who did what. Read-only agents can be governed much more lightly, and it is worth separating them explicitly, because the risk profile changes entirely at the point an agent can write, send, approve, or commit. Organizations in regulated environments should also note that an agent operating inside an assessed compliance boundary becomes part of that boundary and inherits its documentation and access review obligations, which is a scoping question best answered before deployment rather than during an assessment. Our compliance work usually starts there, and for organizations that need to map that boundary formally against a named framework, that is exactly what an AI risk assessment is built to produce.

What we recommend you do about it:

• Give every agent its own identity. No shared service accounts, no borrowed credentials, no agents operating under a human’s account.
• Decide the delegation model deliberately. Own identity for attribution, user entitlements enforced at the data layer for containment.
• Separate read from write in the grant. An agent that can only read is a different governance object from one that can act.
• Use short-lived credentials. Standing secrets for automated actors are the exposure that never expires.
• Enforce authorization at the data layer, not in the agent. Retrieval should respect the requester’s permissions, or the agent becomes a bypass by design.

What Does the Agent Lifecycle Look Like?

Seven stages, and most organizations implement the first four and stop. The stages nobody runs are where the risk accumulates.

Request. A defined intake, triggered by capability rather than by cost, since agents are usually built rather than bought and never cross a procurement threshold.

Review and approve. What data it touches, what actions it can take, which systems it reaches, and who is accountable for its behaviour. A named human owner is not optional and should be recorded as a person rather than a team.

Provision. Its own identity, scoped grant, and credentials issued through the same process you use for any privileged account.

Register. An entry recording purpose, owner, data categories touched, read versus write capability, systems and tools reachable, the delegation model, whether it sits inside a compliance boundary, and a review date.

Monitor. Tool invocations logged with attribution, and alerting on behaviour outside the expected envelope.

Review. Periodic recertification of the grant, in the same cycle as your existing access reviews. An agent’s permissions drift upward over time as capabilities are added, and nothing pulls them back without a review.

Decommission. This is the stage almost nobody runs. Agents built for a project outlive it, holding scoped access to production systems that nobody is watching, owned by someone who has moved teams or left. It is the same pattern as an unmanaged application surviving an employee’s departure, applied to something that can act.

The lifecycle needs adapting to where agents come from. Agents your teams build are the ones this process fits naturally. Agents embedded in software you already licensed arrive without passing through any of it, shipped in a vendor release, and they belong in the register regardless, which means reviewing the AI capabilities in your approved application list is part of building the inventory. Agents supplied by a vendor operating in your tenant need the same treatment as any third party with standing access, including the question of what the vendor can see. And organizations already running a mature non-human identity program should extend that program rather than starting a parallel one, since agents are a category within it rather than a separate problem. The registry itself matters less than the review date, because a register nobody revisits describes the organization as it existed on the day it was written. If you are starting this from nothing, an AI readiness assessment is the practical way to establish what exists before building a lifecycle process around it.

What we recommend you do about it:

• Trigger intake on capability, not cost. Agents rarely cost enough to hit a procurement gate, which is why they bypass governance.
• Record a named human owner. A person accountable for the agent’s actions, not a distribution list.
• Put agent recertification in your existing access review cycle. New process fails, existing process absorbs.
• Register embedded and vendor agents too. They arrive without asking and they hold real access.
• Build a decommissioning trigger. Project end, owner departure, or a review date reached with no business justification.

How Do You Control Change and Prove What Happened?

Treat prompt and model changes as production changes, and log every tool invocation with attribution to both the agent and the person on whose behalf it acted. Those two practices are the difference between an incident you can investigate and one you can only apologise for.

Change control is the gap almost nobody has closed. An agent’s behaviour is determined by its instructions, its model version, and its available tools, and all three can change without a single line of code being reviewed. A business user editing a system prompt is altering production behaviour. A vendor updating the underlying model changes how an agent responds to the same input. A new tool added to an agent’s catalogue expands what it can do. In a software deployment each of those would pass through review, testing, and a release record. In most agent deployments none of them do. The fix is unglamorous: version the prompts, record the model version in use, require review for tool additions, and keep a change log you could hand an auditor.

Attribution is the other half, and it is what Singapore’s framework requires explicitly: an audit trail recording which agent acted under whose authorisation. If you cannot reconstruct that, you cannot investigate, you cannot revoke precisely, and you cannot answer the question a regulator or a customer will eventually ask. Alongside it you need the ability to stop an agent quickly, which sounds obvious and is frequently absent, so it is worth testing rather than assuming. Approval gates belong on consequential actions, and the category worth being categorical about is decisions affecting people, since employment, credit, insurance, housing, clinical and academic decisions are where both the emerging state regimes and the EU AI Act concentrate, and where the Act’s human oversight duty falls on the party relying on the system rather than on whoever built it. Organizations running agents inside Microsoft environments should look at what their existing tenant already provides here before buying anything, since audit, data protection and conditional access capabilities in Microsoft 365 cover more of this than most buyers assume.

What we recommend you do about it:

• Version prompts and record model versions. Behaviour changes with both, and neither is currently reviewed anywhere.
• Require review for new tools. Adding a capability is expanding the grant.
• Log tool calls with dual attribution. Which agent, on whose behalf, against which resource.
• Test the stop. Confirm you can pause or revoke an agent quickly, before you need to.
• Gate decisions about people. Human approval on employment, credit, clinical and similar actions, without exception.

Building It in the Right Order

Six steps, in sequence, and none of them require a platform purchase.

Start with the register, because every control references it. List the agents your teams built, the agents embedded in software you already licensed, and any agent a vendor operates in your tenant. Record purpose, owner, data touched, read or write, systems reachable, and a review date.

Then fix identity. Give each agent its own, retire shared service accounts, move to short-lived credentials, and settle the delegation model so attribution works and the agent cannot exceed the requester’s entitlements.

Then attach the lifecycle to processes that already run. Intake triggered by capability, approval recording a named owner, recertification inside your existing access review cycle, and a decommissioning trigger. New processes fail; existing ones absorb.

Then add change control. Versioned prompts, recorded model versions, review for new tools, and a change log.

Then close the attribution gap, logging which agent acted on whose behalf, and confirm you can stop an agent quickly.

Then map what you have built into whichever framework you report against, whether that is ISO/IEC 42001, the NIST AI Risk Management Framework, or a customer’s questionnaire. Do the controls first and the mapping second, because a mapping to a framework that does not mention agents will not tell you what to build. Our IT consulting team works through this sequence with clients in that order.

If you cannot currently list every agent with access to your systems and name a human accountable for each one, that register is the first deliverable. Schedule a consultation to work through your agent inventory and authorization model.