Key Takeaways

• AI agent governance becomes enforceable when every agent action traces to a verifiable identity, an accountable owner, and the person the agent acts for.
• Many AI agents aren't classic non-human identities; they act on a person's behalf inside that person's sessions, which service-account programs only partly cover.
• Short-lived, task-scoped credentials issued at the moment of action govern agents more effectively than standing tokens and quarterly access reviews.
• The first step toward managing non-human identities at scale is finding agents already running in browsers, desktop apps, extensions, and Model Context Protocol (MCP) servers.

Most AI agent governance policies describe behavior nobody can enforce

The AI governance committee has approved the policy deck, and the principles are sound. Meanwhile, agents are already drafting emails, filing tickets, and querying the CRM under someone's login, and nobody in the meeting can say whose.

AI agent governance is the set of identity, access, and runtime controls deciding what an agent may do, on whose behalf, and with what evidence. It differs from model governance for one simple reason: agents don't just answer questions, they act.

Adoption is moving faster than the controls around it. Gartner predicts at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028. The same Gartner forecast expects over 40% of agentic AI projects to be canceled by the end of 2027, partly over inadequate risk controls.

Maturity is trailing, too. Deloitte's 2026 State of AI in the Enterprise survey found only 21% of organizations have a mature governance model for agentic AI. The gap isn't for lack of effort, since most programs started where governance has traditionally started: with written policy.

Policy-first programs stall for a structural reason. Most agent policies are written for an agent that can be identified, and in many environments, most production agents can't be.

A rule like "agents may not export customer data" depends on knowing which agent is acting, for whom, and with which credential. Without those answers, enforcement falls back to reviewing logs after the fact, which is closer to auditing than governing.

The same written rule means different things depending on where the agent runs. An agent under a shared service key usually looks the same no matter who launched it, so the rule has nobody to hold accountable. Inside an analyst's browser session, the opposite happens: the agent looks like the analyst, and the rule can't separate the person from the delegate.

AI agents are part workload identity and part human delegate

Most identity teams already run a mature playbook for service accounts, so it's tempting to file agents under that heading and move on. The instinct makes sense, and it does cover part of the problem.

Human IAM grew up around HR lifecycles and interactive logins. Non-human identity (NHI) programs grew up around workloads with fixed jobs, like service accounts, API keys, and CI/CD roles.

Both models were right for the problems they were built to solve, and both still earn their keep. What's changed is a single agent can behave like either one in the same afternoon, usually in one of three patterns:

• Autonomous workload agents: Agents running on a schedule or trigger under their own credential, closest to classic NHI.
• Delegated agents: Agents acting for a specific person, often inside that person's browser or desktop session.
• Chained agents: Agents calling other agents or MCP tools, passing authority along at each hop.

Risk concentrates in delegation. The MCP specification's own security guidance names the classic version of this failure: the confused deputy problem. An agent holding one party's authority ends up acting for another, and nothing in the request looks wrong.

The OWASP Top 10 for Agentic Applications ranks identity and privilege abuse (ASI03) among its top risks. Its concern is leaked credentials letting agents operate far beyond their intended scope.

Delegation adds a quieter version of the same issue. An agent inside a user's session doesn't appear as a new identity in most directories; it appears as that user, having an unusually productive day.

Standards bodies are converging on this gap. NIST's National Cybersecurity Center of Excellence is exploring it in a concept paper on software and AI agent identity and authorization. The paper covers identification, authorization, auditing, and non-repudiation for agents, and it remains a concept rather than a mandate.

Identity-first governance ties each agent action to owner, delegator, and scope

When one of your agents tries something consequential, like pushing a pricing change or pulling a customer list, you need four answers in that moment:

• Which agent is this? A unique, verifiable identity rather than a shared key.
• Who owns it? An accountable team or named person.
• Who is it acting for right now? The delegating human or system behind the request.
• What is it allowed to touch for this task? A scope bounded by the delegator's own access and the task itself.

This is the practical core of identity-first AI agent governance, because once those four answers exist, your policies become enforceable. "Agents may not export customer data" turns into a decision made at the moment of action instead of a finding in next quarter's audit.

A delegated agent shouldn't hold more access than the person it acts for, and it usually needs far less. Over-permissioning tends to creep in at delegation time rather than provisioning time, when nobody is looking closely at scope. Picture a meeting summarizer inheriting a senior user's entire session because that was the easiest path; suddenly it can reach the finance system.

Scoping the delegation, not the agent, is where you get the most leverage. Give the agent the slice of the user's authority this task requires, and let it expire when the task does.

Audit follows naturally from this model. Every action is attributable to the agent and, ultimately, to the human authority behind it, which mirrors the accountability chain in NIST's concept paper.

It also helps to pair least privilege with what OWASP calls least agency, giving an agent only as much autonomy as the work requires. Together, the two principles keep an agent's reach and its independence proportional to the job you actually delegated.

Standing credentials are the policy you didn't mean to write

Most teams have found an API key in a config file that outlived the project, the engineer, and the reason it was created. It's a familiar kind of archaeology, and agents make those digs far more frequent.

A long-lived token held by an agent is a standing grant of everything it can reach, whatever the written policy says. That's less a policy than a permission slip with no expiration date. For AI agent governance, credential lifetime is the rule your systems actually execute.

In most environments, quarterly access reviews can't keep pace with identities that appear and disappear within a single working session. The better model is just-in-time, task-scoped credentials brokered when the agent acts, bound to the delegator's identity, and expired when the task ends.

An agent reconciling invoices gets read access to one ledger for the length of the job, bound to the analyst who delegated it. It can't write or browse other ledgers, and once the reconciliation finishes, the credential expires with nothing left for a future dig to uncover.

MCP makes this more pressing. The NSA's May 2026 guidance on MCP security design observes "MCP's rapid proliferation has outpaced the development of its security model." It also notes the protocol doesn't define how to associate a session with an identity, and authorization is optional.

That doesn't make MCP insecure by design. It means the security model is underspecified and left to implementers, which is exactly where you have room to act.

Island addresses this gap by keeping standing secrets out of agents' hands through Island Enterprise AI. Its MCP gateway issues just-in-time credentials when an agent acts, and each call runs under the same policy engine and audit trail governing people. With no long-lived token waiting to leak, the credential stops being a policy nobody meant to write.

Governance works best where the agent actually runs

You can often see an agent reached a SaaS app. What you usually can't see is what it did once inside the session, which is where the consequential work takes place.

Your delegated agents do much of their work inside authenticated sessions: browser tabs, desktop apps, and MCP connections to internal tools. Those sessions are where identity, data, and action meet, so your enforcement point matters as much as your policy. Three architectural approaches have emerged, each shaped by the era it was built for:

• Controls built into the work environment: These connect browser, desktop, and MCP sessions to one policy engine evaluating identity, data, and agent actions together.
• Add-on layers on existing browsers and apps: These extend session visibility and make a strong complement, with reach shaped by the host environment.
• Network and proxy controls: These fit an era when traffic was the best vantage point, and they see destinations better than in-session actions.

The first approach holds up best, and the reason is timing. When identity, data, and action are evaluated in one place as the agent acts, policy doesn't depend on reconstructing context from scattered logs later.

Island Enterprise AI is one example of this approach, and Island also offers an extension for teams complementing the browsers they already use. Either way, the same environment governing people's work governs their agents.

In practice, runtime visibility means seeing a delegated agent about to paste a customer record into a personal AI account, then stopping that single action. The same in-session vantage point lets controls catch data leakage and prompt injection as they happen, not in next week's report.

Nobody wants AI agent governance that works by making agents so hard to use that employees route around them. When one of your agents needs approval, the human-in-the-loop step can appear in the flow of work rather than as a ticket in someone's queue. That's what saying yes to AI looks like: governance built in, not bolted on, so you can deploy more agents rather than fewer.

Start with the agents already acting on your employees' behalf

You don't need a finished framework to make meaningful progress this quarter. You need a clear sequence, and the right first move is less obvious than it looks.

Your first inventory shouldn't be the agent program your team approved. It should be the delegated agents already in use: AI browser extensions, desktop assistants, agentic browsers, and MCP servers your employees connected on their own. Those carry real user authority, and few of them are likely to appear in a formal registry.

Approved agents went through review, so they tend to be the best-governed ones in the environment already. The unreviewed ones are where authority and oversight have drifted furthest apart, which is why they deserve your first look.

• Discover delegated agents: Map every extension, desktop agent, and MCP connection to the person whose access it uses.
• Replace standing secrets: Move your highest-impact agents to just-in-time, task-scoped credentials first.
• Move one policy from document to runtime: Enforce your committee's top rule, such as no customer data in personal AI accounts, when agents act.

In your environment, ownership should usually default to the employee whose access the agent uses, with that person's team lead deciding whether it stays, gets scoped down, or gets retired.

From there, track one metric: the share of agent actions you can attribute to an accountable human. It's our recommendation, not an industry benchmark, and it beats a count of registered agents because it measures accountability instead of paperwork.

The timing works in your favor. McKinsey's 2025 State of AI survey found 23% of respondents' organizations scaling an agentic AI system somewhere in the enterprise, so most are still early. That arguably makes now the cheapest moment to lay the identity foundation for AI agent governance, before agents multiply across every team.

Accountable agents start with a verifiable identity

If you want to pressure-test identity-first agent governance against your environment, let's compare notes. Request a demo.

FAQs

What is AI agent governance?

AI agent governance extends oversight from what a model says to what an agent does, binding each action to a verified identity, owner, and scope.

Are AI agents non-human identities?

Some are, but many act on behalf of a specific person inside that person's sessions. Those agents need an identity of their own plus a verifiable link to the human they represent.

How do enterprises manage non-human identities at scale?

At scale, automation replaces manual access reviews, issuing and expiring credentials per task and mapping every identity to an accountable owner.

Is monitoring AI agents enough for governance?

Monitoring is retrospective and explains what an agent already did. Governance decides what it may do before execution, while there's still time to stop it.

Who should own AI agent governance?

Ownership typically spans identity, security, and the business teams deploying agents. Each individual agent, though, should have one accountable owner recorded alongside its identity, because an agent without an owner isn't governed, only tolerated.