
Your team might connect an agent to the CRM, email, and a shared drive on a Friday afternoon. By Monday it's drafting replies, updating records, and moving files under a credential your security team didn't issue and doesn't own. Friday's pilot has a way of becoming Monday's production integration.
You likely already know how to govern service accounts and API keys. Those identities were predictable: one job, one scope, and an owner who remembered why it existed. Agents work differently, reasoning about the access they need, calling tools through Model Context Protocol (MCP) servers, spawning sub-agents, and chaining actions across systems.
A Cloud Security Alliance whitepaper describes agents as autonomous actors that "acquire permissions dynamically at runtime." In other words, the permission set on file is only a starting point, and the population of these actors is growing quickly.
In a June 2025 forecast, Gartner predicted 33% of enterprise software applications will include agentic AI by 2028, up from less than one percent in 2024. The biggest non-human identity risks AI agents introduce tend to fall into six patterns:
Two of these risks have already drawn formal attention from standards bodies. In a January 17, 2025 technical blog on agent hijacking, NIST reported the strongest new attack against one tested model raised task-hijack success to 81%, compared with 11% for the strongest baseline attack.
The OWASP Top 10 for Agentic Applications, published in December 2025, names two categories: ASI03 Identity & Privilege Abuse and ASI04 Agentic Supply Chain Vulnerabilities. The second category explicitly covers poisoned MCP components.
Each risk on the list surfaces when the agent acts, not when it's credentialed. That makes AI agent governance less an inventory problem than a behavior problem.
You may have spent the better part of a decade getting service accounts under control, and the work paid off. Vaults, rotation schedules, privileged access management (PAM), and quarterly access reviews solved the problem of their era. Back then, a machine identity typically had one job and a fixed scope, and scoping access at issuance worked because runtime behavior matched the design.
The agent era has surfaced a timing problem those programs weren't built around. An agent's effective access is decided when it acts, not when it's credentialed. A procurement agent granted read access to vendor records in March might be drafting payment instructions by April, through a connector someone added later.
Your credentialing process answers "who is this?" It doesn't answer "what is it doing with the customer file right now, and on whose behalf?" A clean vault and a rotated key prove the credential is healthy, while saying very little about whether the agent is.
Shorter-lived tokens and workload identity federation narrowed the exposure window considerably, and they're worth keeping. A one-hour token is still valid for the full hour, though, and an agent can do plenty of unreviewed work in that time.
Quarterly access reviews share a similar blind spot, since they evaluate a snapshot of an identity whose permissions may change mid-task. Identity and access management (IAM) and PAM were designed for a different problem, and they remain the right foundation for knowing who an agent is. What most programs need now is an extension of that foundation, not a replacement.
For AI agent governance to keep pace, it has to move from the identity store to the moment of action. That's where an agent decides what to do next, and it's where the useful questions now live.
When an agent request lands in your queue, you probably start by asking whether its credential is scoped correctly. If you shift the question to "should this agent take this action, right now, for this person?", the control set changes. You keep least privilege and layer least agency on top of it, granting the minimum autonomy a task needs along with the minimum access.
In practice, four controls follow the agent to the moment of action:
Article 14 of the EU AI Act requires high-risk AI systems to support human oversight: people must be able to monitor, override, and stop them. Those obligations phase in from December 2027, and they aren't agent-specific or a mandate for sign-off on each action. Still, they set a useful baseline for what meaningful oversight looks like.
An audit trail ties the four controls together. One record should connect each agent action to the agent, the human it acted for, and the owner accountable for it. That's how non-repudiation moves from a compliance term to something an investigator can actually use.
Standards bodies are converging on this model. In a February 5, 2026 concept paper on agent identity, NIST's National Cybersecurity Center of Excellence (NCCoE) proposed a new project. Its focus is the identification, authorization, auditing, and non-repudiation of AI agents, and it's a proposed project rather than a final standard.
Protocols are moving the same way. The MCP authorization specification defines protected MCP servers as OAuth 2.1 resource servers, which turns each MCP connection into its own authorization surface. Your agentic AI governance program needs a view of those connections, not only of the identities using them.
The point isn't to slow agents down. These controls let your teams say yes to more agents, faster, because each approval carries less risk than it would under a standing-key model. Security then becomes the team making agent approvals routine, which is a far better seat than being the team saying no.
One of your employees asks a browser-based agent to pull last quarter's pipeline into a deck for Monday's forecast call. The identity provider sees one login, and it's the employee's. The agent then reads the CRM, copies figures, and uploads a file, all under that same session.
Many of the agents you care about most don't hold a credential of their own, because they borrow your user's session instead. Non-human identity inventories typically don't list them, and the identity provider logs a human. For these agents, AI agent governance has to live at the interface where the work happens: the browser, the desktop, and the MCP connection.
Data boundaries and app access policy should apply to the agent as they do to the person, covering copy, paste, uploads, downloads, and screenshots. Where those controls live shapes what they can see. Controls built into the enterprise browser and desktop environment see the agent's actions natively, inside the session.
Extensions, meanwhile, add useful visibility on consumer browsers and complement that model, especially for contractors and unmanaged devices. Network and proxy controls occupy a different position in the stack: they see the traffic, not what happened on the page.
One policy and one audit trail for people and agents pay off on a bad day. Investigators follow one timeline rather than two stitched logs, and a revoked permission covers the person and their agents at once. Two governance stacks for two kinds of workers means two sets of gaps, and attackers only need one of them.
Each point solution solved a real problem, and together the solutions became the problem. Agents need an environment that behaves like one environment.
Island is one example, with agent governance built in, not bolted on, across the Island Enterprise Platform. Island Enterprise AI extends the policy people work under to where agents act, including the Island Enterprise Browser.
Any environment needs per-task credentials and live discovery. Here, Agentic Identity swaps standing keys for just-in-time credentials from the Island MCP Gateway, and Agentic Endpoint Posture discovers agents, MCP servers, skills, and extensions.
When controls live in the environment, they fade into the background, and the employee and agent just get the work done. Independent coverage of Island's $400 million Series F described the aim as a least-privilege harness for AI agents. It doesn't replace IAM or non-human identity (NHI) tooling; it extends policy to where agents act.
When you begin AI agent governance, your first instinct may be to open the identity provider and list service principals. It's a reasonable start, and it's incomplete.
The most complete agent inventory usually isn't in the directory. It lives on endpoints and in browsers, where employees install coding agents, AI extensions, and local MCP servers without a ticket.
A coding agent wired to a local MCP server with database access typically won't appear in the directory. Its effective reach may still exceed what most service accounts can touch.
You'll get the best discovery results when you start at the endpoint and the interface, then reconcile that view with your identity provider. Most agent inventories start going stale the day they're finished, which argues for continuous discovery over a quarterly census.
Your first pilot doesn't need to be your most powerful agent, either. Pick the one running on a borrowed human credential, because it usually has the widest effective reach and the thinnest audit trail.
It also helps to make the governed path the easiest path. When approved agents get credentials and connectors in minutes, shadow AI tends to shrink through adoption rather than enforcement. The CSA whitepaper points in a similar direction.
In the same June 2025 forecast, Gartner predicted over 40% of agentic AI projects will be canceled by the end of 2027, as Reuters reported. It cited escalating costs, unclear business value, or inadequate risk controls as the drivers. Of those three drivers, risk controls are the one security teams directly own, which makes governance part of what keeps agent programs funded.
Before any agent scales, it helps to answer four questions about its ownership, its reach, and its brakes:
The goal is governance your people and agents barely notice, because it travels with the work. An agent nobody can stop mid-action isn't ready for more access, however impressive the demo looked.
If you want to pressure-test this model against your own agents, we're happy to walk through it with you. Schedule a walkthrough.
The biggest risks include orphaned credentials, inherited human permissions, standing API keys, trust passed down delegation chains, hijacking through prompt injection, and unvetted MCP connections. Each one tends to surface at runtime, when the agent acts, rather than when its credential is issued.
You should govern the action as well as the identity, using task-scoped just-in-time access, per-action policy, human approval for consequential steps, and one audit trail. That combination lets teams approve more agents without piling up standing risk.
Service accounts typically run fixed jobs with fixed scopes, so access set at issuance matches what they do. Agents decide what to do next, pick up access, and delegate work at runtime, which makes their effective permissions a moving target.
IAM remains the foundation for establishing who an agent is and what it was granted. It was designed to decide access at login, so it needs session-level and connection-level policy to judge each action an agent takes.
Each agent needs a named human owner plus an audit trail recording whose behalf it acted on and what it touched. With both in place, accountability is designed in rather than reconstructed after an incident.