AI Agent Governance: Framework, Risks and How to Control Agentic AI Access (2026)

AI agent governance is the set of controls that decides which systems an autonomous AI agent may access, which actions it may execute, who is accountable for it, and when its access ends. It differs from AI governance in one decisive way: AI governance reviews what a model says, while agent governance controls what an agent does. An agent holds credentials, calls tools, writes to production systems and keeps working when nobody is watching. That makes it an identity, not a content risk.

Most mid-market IT teams already own the controls needed to govern agents. They just have not applied them to non-human identities yet.

Table of contents

• What is AI agent governance?
• The four agentic AI risks nobody has inventoried
• The AI agent governance framework: five controls
• Mapping agent controls to EU compliance requirements
• How to extend your existing IAM stack to AI agents
• A 30-day AI agent governance plan
• Why Corma for AI agent governance
• Frequently asked questions

Something changed quietly between 2025 and 2026. Search demand for shadow AI went from 1,600 monthly US searches in July 2025 to 4,400 in June 2026, according to Google Ads Keyword Planner data pulled in July 2026. That curve is not marketing curiosity. It is IT and security teams discovering, one incident at a time, that employees have connected autonomous software to company systems without telling anyone.

The scale of the shift is documented. Gartner predicts AI agents will be responsible for 15 percent of day-to-day work decisions by 2028, up from zero percent in 2024. McKinsey estimates agentic and generative AI use cases could unlock 2.6 to 4.4 trillion dollars annually, while noting in the same body of research that only 1 percent of organizations consider their AI adoption mature. Capability is scaling faster than control.

The market response has been to sell a new layer: agent governance platforms, guardrail engines, runtime policy interceptors. For a company of 50 to 500 employees with a four-person IT team, buying a parallel governance stack is not realistic. This guide takes the opposite route. It shows how the five controls that actually govern agents map onto the identity and access management capabilities you already run, how they line up against EU AI Act, NIS2, ISO 27001 and GDPR obligations, and what to do in the next 30 days.

What is AI agent governance?

AI agent governance is a discipline of access control applied to autonomous software. It defines which resources an AI agent can reach, which actions it can perform, which human is accountable for it, and how its permissions are reviewed and revoked over time.

An AI agent is an AI system that plans a sequence of steps, selects tools, and executes actions toward a goal without prompting for each step. If a large language model is the reasoning layer, an agent is that layer plus credentials, tool access and a job description. The distinction matters because governance targets the credentials and the tool access, not the reasoning.

How is AI agent governance different from AI governance?

Traditional AI governance was built for systems that produce output: bias testing, hallucination review, content filtering, model documentation. Those controls assume a human reads the output and decides what happens next. Agents remove that step. An agent can create a Jira ticket, update a CRM record, provision a user, or send an external email before any human sees the underlying reasoning.

The practical consequence: an agent governance failure produces an action you have to undo, not an answer you have to correct.

What changed in 2026?

Three shifts turned agent governance from a research topic into an operational one.

• Agents are now built by non-engineers. Microsoft Copilot Studio, Salesforce Agentforce, n8n, Zapier Agents and Retool let a business user create a working agent in an afternoon. Procurement, security review and IT are not in that loop.
• The Model Context Protocol (MCP) multiplied connection points. Every MCP server an agent connects to is a new credential path into a system. Nudge Security research documents MCP server sprawl as a fast-growing extension of the SaaS attack surface that conventional discovery tools do not surface.
• The regulatory calendar became concrete. The EU AI Act's transparency obligations under Article 50 apply from 2 August 2026, while high-risk obligations moved to 2 December 2027 under the Digital Omnibus on AI adopted by Parliament on 16 June 2026 and the Council on 29 June 2026. Deadlines exist, and they are now specific.

The four agentic AI risks nobody has inventoried

Most agent risk articles list prompt injection, hallucination and model drift. Those are real, and they are also the risks a security vendor can sell a runtime product against. The four risks below are the ones that show up in an actual mid-market audit, and they are all identity and asset management problems.

Untracked access: OAuth grants, API keys and MCP connections

An agent needs credentials to be useful. In practice those credentials arrive through the fastest available path: an employee approves an OAuth grant with broad scopes, pastes a long-lived API key into an automation, or points an agent at an MCP server using a service account nobody documented.

The failure mode is not exotic. It is a token with write access to a production system, held by software, with no expiry date and no named owner. This is the same visibility gap that produced shadow IT, with one difference: the software can now act on its own.

Agent sprawl: shadow IT with a decision engine

Agent sprawl is the uncontrolled accumulation of AI agents created outside IT procurement, each holding its own permissions and connections. Nudge Security data puts the average organization at 26 distinct AI applications already in use, most adopted without IT oversight. Every agentic platform in that set can generate agents.

Sprawl is measurable and it compounds. Two employees building similar agents on different platforms produce two credential sets, two audit gaps and two renewal lines. The pattern is familiar to anyone who has read our analysis of the rise of shadow AI and how to mitigate it.

Orphaned agent accounts: nobody offboards an agent

This is the blind spot of the entire market. Search the top ten results for "ai agent governance" and you will find extensive coverage of deployment, guardrails and human oversight, and almost nothing about termination.

When an employee leaves, a mature IT team revokes their accounts. When the employee who built three agents leaves, those agents keep running, keep their tokens, and keep their access. They become orphaned non-human identities: active credentials with no accountable human. Auditors treat an orphaned service account as a finding. An orphaned agent is the same finding with a larger blast radius, because it acts rather than waits.

Invisible cost: seats, credits and tokens

Agents consume paid resources. They occupy licence seats in the tools they operate, burn API credits and consume model tokens. Because the spend often lands on a departmental card or inside an existing subscription, it surfaces in finance reporting long before it surfaces in a security review.

That makes cost the most reliable early warning signal available. An unexplained increase in AI spend is frequently the first detectable symptom of an ungoverned agent, and it reaches the CFO before it reaches the CISO.

The AI agent governance framework: five controls

The framework below follows the sequence that works operationally: you cannot apply a policy to an agent you have not found, and you cannot revoke access you cannot attribute.

1. Discover and inventory every agent

Governance cannot precede discovery. Before least privilege, reviews or runtime policy, you need an inventory that answers three questions per agent: what can it reach, what can it do, and who created it.

An agent inventory is not an AI tool inventory. A tool inventory asks which applications employees use. An agent inventory asks which autonomous systems hold access to your environment. Discovery sources that actually work: identity provider logs, OAuth grant records, SaaS discovery signals, expense and card data, and browser-level signals for platforms without APIs.

2. Give every agent a unique identity and a human owner

Every agent gets its own identity and one named human custodian. No shared API keys across agents, no generic service accounts, no credentials inherited from a departing employee.

This single control produces most of the audit value, because it makes every agent action traceable to a person who can be asked to justify it. It is the same discipline as user provisioning applied to software rather than staff.

3. Apply least privilege with roles, not shared API keys

Scope permissions to the task. An agent that reads calendar data to draft summaries does not need write access to the CRM. In practice this means role-based access control for non-human identities, with time-bound credentials where the platform supports them.

If your team is choosing a permission model, our comparison of RBAC and ABAC access control models applies directly: roles scale better for a fixed agent catalogue, attributes handle dynamic context better.

4. Set human-in-the-loop thresholds by action criticality

Not every agent action deserves an approval gate, and a system that asks for approval on everything gets bypassed. Calibrate to consequence: reversible and low-impact actions run autonomously, irreversible or externally visible actions require explicit human approval.

The mechanism already exists in most IAM stacks as an approval workflow. Routing agent privilege escalations through the same channel you use to automate user access requests avoids building a second approval system.

5. Certify, then revoke: access reviews and agent offboarding

Agent permissions decay in the same direction as human permissions: they only ever grow. The control is periodic certification, and it needs to include a deletion path.

Two rules make this work. First, include non-human identities in the scope of your automated and compliant access reviews rather than reviewing them separately. Second, add agents to the leaver step of your joiner-mover-leaver process, so that automated provisioning and offboarding covers the agents an employee created, not just the accounts they held.

Mapping agent controls to EU compliance requirements

European organizations do not get to treat agent governance as an emerging best practice. Several existing obligations already cover it, and one framework has a live 2026 deadline.

The EU AI Act timeline as it actually stands in July 2026. The Digital Omnibus on AI was adopted by the European Parliament on 16 June 2026 and by the Council on 29 June 2026, with entry into force in July 2026. It defers high-risk obligations for stand-alone Annex III systems from 2 August 2026 to 2 December 2027, and for AI embedded in Annex I regulated products to 2 August 2028. Article 50 transparency obligations still apply from 2 August 2026. New prohibitions and the Article 50(2) marking requirements for systems already on the market apply from 2 December 2026.

The practical reading for an IT leader: the high-risk conformity work has more runway, but the record-keeping and human-oversight design work does not become optional. Article 12 requires automatic logging of events over a system's lifetime. Article 14 requires that high-risk systems be designed so humans can effectively oversee them. Both are engineering and access-control requirements, and both are easier to satisfy if agent identity and logging exist before the deadline rather than after.

NIS2 is the more immediate constraint for most in-scope companies. Article 21(2) lists the required cybersecurity risk-management measures, which include access control policies and asset management. An undocumented agent holding production credentials is an asset management failure under that article, whatever else it is. Our guide to what the NIS2 directive means for your business covers the scoping question in detail.

How to extend your existing IAM stack to AI agents

Here is the argument in one line: the four pillars the market sells as new (discovery, least privilege, guardrails, human oversight) are respectively SaaS discovery, RBAC, conditional provisioning and access review. You are not missing a category of tooling. You are missing coverage of non-human identities in the tooling you have.

What your current stack already covers, if it is configured for it:

• SSO and your identity provider give you a single place to see and cut authentication. Agents that authenticate through the IdP are agents you can disable in one action.
• SCIM provisioning gives you programmatic account creation and, more importantly, programmatic account removal. Where an agent platform supports SCIM, deprovisioning becomes an API call rather than a manual ticket.
• RBAC gives you the permission model. Agents become role holders.
• Access reviews give you the recurring certification cycle. Add a non-human identity view.
• Joiner-mover-leaver workflows give you the lifecycle. Add an agent step to the leaver checklist.

What genuinely needs to be added:

• An agent register with owner, purpose, connected systems, credential type and review date.
• Credential hygiene for machines: no shared keys, expiry dates on tokens, rotation schedule.
• Approval thresholds by action type, documented rather than implicit.
• A termination path triggered by both agent decommissioning and owner departure.

For teams that want the operational view rather than the framework view, our earlier piece on the governance of AI agents and managing the future of IT covers the organizational side of the same problem, including who should own the register.

A 30-day AI agent governance plan

This is written for an IT team of two to six people supporting 50 to 500 employees, with no dedicated security operations function.

Week 1: find them. Pull OAuth grants from Google Workspace or Microsoft Entra ID. Export SaaS and AI application spend from finance. List every agentic platform in use. Do not attempt policy yet.

Week 2: name an owner for each. One line per agent: owner, purpose, systems reached, credential type. Anything without an owner goes on a revoke shortlist, not a review list.

Week 3: cut the obvious. Revoke orphaned tokens, replace shared API keys with per-agent credentials, remove write permissions that no documented use case requires.

Week 4: make it recurring. Add non-human identities to the access review cycle, add an agent line to the offboarding checklist, and set approval thresholds for the three or four highest-consequence action types in your environment.

Why Corma for AI agent governance

Corma is a European platform that combines SaaS Management and Identity and Access Management in one system, which is the specific combination agent governance requires. Discovery lives on the SaaS management side. Identity, least privilege, approvals and revocation live on the IAM side. Splitting those across two vendors is how agents fall between the two.

Four points matter for this use case:

• Converged discovery and control. Corma discovers applications, licences and access in the same platform that provisions and revokes them, so an agent found on Monday can be scoped or cut on Monday. Most competitors do one side or the other.
• European hosting and native GDPR compliance. Data is hosted in the EU, and Corma holds ISO/IEC 27001:2022 certification. For a company mapping controls to NIS2 and the AI Act, this removes the data transfer question that US-headquartered SaaS management vendors have to answer.
• Cost and access in one view. Because Corma tracks licences and spend alongside identity, the budget signal described earlier becomes an operational alert rather than a quarterly surprise.
• Mid-market implementation reality. Full onboarding typically takes under a month for a company in the 50 to 500 employee range, which is the difference between a control that exists on paper and one that runs.

The pattern is already documented in regulated environments. Our case study on identity governance in healthcare at Satelia shows the same control set applied where audit requirements are strictest.

Frequently asked questions

What is agent governance in AI?

Agent governance in AI is the practice of controlling what an autonomous AI agent can access and execute, who is accountable for it, and how its permissions are reviewed and revoked. It covers identity, permissions, approval thresholds, logging and termination, and it applies to the agent's actions rather than to the model's output.

How is AI agent governance different from AI governance?

AI governance evaluates model outputs for accuracy, bias and compliance. AI agent governance controls agent actions: which systems the agent reaches, which operations it can perform and under what conditions a human must approve. The first is a content review problem, the second is an access control problem.

Do I need a dedicated AI agent governance platform?

For most mid-market companies, no. The five controls that matter (discovery, unique identity, least privilege, approval thresholds, certification and revocation) are IAM and SaaS management capabilities. A dedicated runtime governance platform makes sense when you are building agents in-house at scale with custom tool chains. If you are mostly consuming agents built on Copilot Studio, Agentforce, n8n or similar, extending your existing identity stack is faster and cheaper.

Who should own AI agent governance: IT, security or compliance?

IT should own the register and the lifecycle, because IT already runs provisioning and deprovisioning. Security should set the approval thresholds and the permission standards. Compliance should own the mapping to NIS2, ISO 27001 and the AI Act. Splitting ownership three ways with no register owner is the failure pattern to avoid.

How does the EU AI Act apply to AI agents?

It depends on use case, not on the technology. Article 50 transparency obligations apply from 2 August 2026. High-risk obligations for stand-alone Annex III systems, which cover areas such as employment, education, creditworthiness and access to essential services, apply from 2 December 2027 following the Digital Omnibus on AI adopted in June 2026. Article 12 logging and Article 14 human oversight requirements are the provisions most directly relevant to agent design.

What is an orphaned AI agent and why does it matter?

An orphaned AI agent is an agent whose accountable human owner has left the organization or is no longer identifiable, while its credentials remain active. It matters because the agent keeps executing actions with valid permissions and no one to justify them, which is both a security exposure and an audit finding under access control requirements such as ISO 27001 control A.5.18.

How do I discover AI agents employees created without telling IT?

Combine four signals: OAuth grant records in your identity provider, SaaS and AI application spend in finance data, admin logs from agentic platforms your company licenses, and browser-level signals for platforms with no admin API. Any single source misses a category, which is why converged SaaS management and identity platforms surface more than an IdP audit alone.

Conclusion

Agent governance looks like a new problem because the vendors selling it need it to be one. Strip the framing away and the requirement is familiar: know what has access to your systems, give every access a named owner, scope it to the task, gate the dangerous actions, and take it away when it is no longer needed. Your IAM stack was built for exactly that. It simply has not been pointed at non-human identities yet.

The teams that will pass their first agent-related audit in 2027 are the ones building the register in 2026.

See how Corma discovers, scopes and revokes access across your SaaS and AI stack in one platform. Request a demo.