Key Takeaways

• Once agents start acting inside employee sessions, platform-only controls lose sight of them, so AI agent governance works best when policy follows agents into the browser, the desktop, and the endpoint session.
• Agents acting inside an employee's logged-in session need their own identity and short-lived, scoped credentials, so the audit log can tell agent from human.
• Proportional autonomy, scaled to what an agent can change, avoids a binary choice between lockdown and blind trust that pushes teams toward shadow AI.
• A useful agent inventory covers what runs on endpoints, including MCP servers, skills, and AI extensions, backed by inline data controls and one audit trail.

AI agent governance stops short of where agents work

Your governance committee may already have approved a model list, a sanctioned orchestration platform, and a review process for new use cases. Meanwhile, agents are filing tickets, editing shared spreadsheets, and pulling Model Context Protocol (MCP) servers onto developer laptops.

Those controls were the right place to start, and they still do useful work. Model cards, approved-provider lists, and platform policies were built for a time when AI mostly produced text for human review. The human was the last step before anything changed in a real system.

The environment has evolved since then, because agents now take actions instead of suggesting them. Many run where people work, such as browser agents clicking through SaaS apps and computer-use agents driving desktop applications. Others are coding agents in a developer's terminal or AI extensions riding along in a logged-in tab.

Gartner predicts an average global Fortune 500 enterprise will have over 150,000 agents in use by 2028, up from fewer than 15 in 2025. In McKinsey's 2026 State of AI survey, 40% of respondents from organizations with over $1 billion in annual revenue report scaling AI agents, up from 27% the year before.

Those numbers expose a mismatch between where AI agent governance looks and where agents act. Platform-layer controls can see what an agent was configured to do, but not what it did inside a user's tab, terminal, or desktop app.

You can probably say which models your organization has approved. Saying what an agent did in a finance app at 4:55 on a Friday is harder. Closing that gap starts with a question most identity programs haven't had to answer before: who, exactly, is acting?

Agents in a user's session need their own identity

Picture the audit log after a busy afternoon of agent work. An employee launched a browser agent inside the session they already use for email and the CRM. The log now shows one person doing twice the work at machine speed.

When an agent borrows a user's session or a shared service account, it inherits whatever that person or account can reach. Accountability blurs quickly, and least privilege is lost by default the moment the agent starts working.

This catches well-run identity programs off guard, and it isn't a failure of discipline. Those programs were tuned for people who log in, pause, and log out, while agents keep working between clicks.

A stronger model for AI agent governance treats each production agent as a non-human identity with an owner, a stated purpose, and a lifecycle. That owner reviews the agent on a schedule and retires it when the job it was built for is done.

Credentials should follow the same lifecycle logic as the identity itself. Instead of standing access, issue just-in-time credentials scoped to a single task, and let them expire with it.

Government guidance on agent identity is moving in the same direction. In February 2026, NIST's National Cybersecurity Center of Excellence published a concept paper on applying identity standards and best practices to software agents. It's an early-stage proposal rather than a finished standard, but it signals where expectations are heading.

Joint guidance from CISA and its Five Eyes partners, Careful Adoption of Agentic AI Services, is more direct. Published May 1, 2026, it advises against broad or unrestricted agent access, especially to sensitive data or critical systems. It also calls for continuous runtime authentication, with centralized policy decision points evaluating each action.

Here's a practical test for whether agent identity is real or just a label. Pick a single action in a SaaS audit log and ask your security operations team whether the person or the agent performed it. If the team can't answer with confidence, the identity layer isn't doing its job yet, whatever the identity architecture diagram says.

Scale autonomy to what an agent can change, not who built it

For your team, the choice so far may have felt uncomfortably binary. Block the agent and watch people find a workaround, or approve it and hope the guardrails someone configured months ago still fit.

In a May 2026 Gartner analysis, analyst Shiva Varma said many enterprises treat agent governance as "either locked down or fully trusted, and that is the root cause of failure." The same analysis predicts 40% of enterprises will demote or decommission autonomous AI agents by 2027, due to governance gaps identified only after production incidents.

The same Gartner analysis recommends proportional governance across four autonomy levels. Each rung earns a different control, matched to how much the agent can change on its own:

• Observe: the agent reads data but changes nothing, and its activity is logged.
• Advise: the agent drafts recommendations or content, and a person reviews them before anything moves.
• Act with approval: the agent can execute, but a human approves each state-changing step.
• Act autonomously: the agent works on its own inside a narrow scope, with rate limits and a kill switch.

The most useful shift in AI agent governance is to tier by the action instead of the agent. The same agent might sit at observe in the CRM and at act with approval in the payments portal. Tiering by vendor or model hides where the risk really lives, which is in the verbs: submit, send, delete, and transfer.

Approvals deserve an honesty check, because human-in-the-loop controls help only when approvals are rare enough to read carefully. When routine steps ask for a click, rubber-stamp fatigue is a common pattern. Reserve approvals for the steps you'd want to explain to an auditor later.

The agent inventory that matters lives on the endpoint

Your orchestration platform may list a few dozen sanctioned agents, each with an owner and a tidy description, but the laptops across your organization often tell a different story.

Registered-agent lists capture what teams chose to register, which is a reasonable place to begin. Discovery on the endpoint shows what people installed, including coding agents, local MCP servers, agent skills, AI browser extensions, and agentic features inside SaaS apps. Neither view is wrong, but only one describes what's running today.

A working inventory should capture a consistent set of fields for each agent:

• Owner: the named person accountable for the agent's behavior and reviews.
• Runtime location: the browser, the desktop, a command line, or a SaaS application.
• Tool reach: the tools and MCP servers the agent can call.
• Data reach: the systems and data classes the agent can read or change.
• Autonomy tier: where the agent sits on the autonomy ladder for each action.
• Last review date: when someone last confirmed the agent still needs its access.

Treat MCP servers and skills like software supply chain components, not like settings. A new MCP server quietly adds tools to each agent connecting to it, so the inventory has to track tool reach, not just agent names.

For AI agent governance, keeping the inventory useful means treating it as a live record rather than an annual census. Reconcile what endpoint discovery finds against the registered list on a regular cadence, and route the differences to the teams closest to them. An agent with no owner is a finding to resolve, not a footnote: someone either claims it and accepts its reviews, or it's retired.

Island takes this endpoint-first view because discovery and policy work better from the same place. With Island Enterprise AI, the policy engine and audit trail already applied to people extend to the agents they run. An unregistered MCP server then surfaces as a governance decision rather than a surprise in an incident review.

Data controls belong between the agent and the application

A browser agent is asked to summarize a customer's support page, and the page hides instructions telling it to export the account list. Model guardrails see a prompt, but they don't see the page, the clipboard, or the upload button.

The OWASP Top 10 for Agentic Applications is a peer-reviewed framework shaped by more than 100 experts. It catalogs agent-specific risks including goal hijacking, tool misuse, and identity and privilege abuse. A poisoned page is one way to hijack an agent's goal, and inside an authenticated session it can steer the agent with the user's full access.

The controls that help most here sit at the point of execution, between the agent and the application it's touching:

• Redact sensitive data before it reaches the model.
• Inspect model responses before they reach the user or the next tool.
• Govern copy, paste, upload, and download when an agent performs them.
• Require approval before state-changing steps like submit, send, or transfer.
• Log each prompt and action to one audit trail shared with human activity.

An agent updating a vendor's payment details pauses before submitting, and the approval request appears in the same browser session. The reviewer sees the invoice and email thread the agent read, plus the field it wants to change. They're judging evidence in context, not approving a vague request after the fact.

Where those controls live shapes what they can actually see and act on. Controls built into the enterprise browser and desktop environment see the rendered page and the agent's action natively, with full session context.

Extensions layered onto consumer browsers add useful visibility, and they often complement a native approach where both are deployed. Network and proxy controls are strong at inspecting traffic, which is the job they were designed for. They don't see what happens inside the rendered page after it loads.

In AI agent governance, the audit trail deserves as much attention as the controls themselves. When agent and human actions land in the same log with the same context, an investigation reads like a timeline. When they're split across systems, investigations turn into reconciliation projects.

Governance people route around isn't governance at all

When the sanctioned agent is slower or clunkier than the personal one, people quietly switch. Nobody announces it; the work just moves to a tab or an account the security team can't see.

Gartner analyst Max Goss made this point in the same April 2026 Gartner release on agent sprawl. Without usable sanctioned tools, Goss warns, employees will likely "go around the organization's controls and start using shadow AI which presents far greater risks."

The flip side is encouraging for teams trying to say yes to agents. In McKinsey's State of AI trust in 2026, nearly two-thirds of respondents cite security and risk concerns as the top barrier to scaling agentic AI. AI agent governance done well removes that barrier instead of adding another one, which is why the governed path has to be the easier path.

Day-to-day ownership works best as a shared operating model, not one team's burden. Security sets the guardrails and autonomy tiers, IT publishes approved agents and keeps the catalog current, and business owners answer for what their agents do. Each group owns what it understands best, so governance becomes a shared job instead of a handoff.

In practice, you can make approved agents available where your people already work, such as a browser sidebar or an internal app store. Governed versions should inherit single sign-on, data loss prevention, and private access automatically, so choosing them costs the user nothing. Keep per-agent cost and usage visible, too, so leaders can see which agents are earning their keep.

Then measure adoption of sanctioned agents as a governance KPI alongside incidents. A falling incident count paired with falling sanctioned usage usually means the work moved somewhere you can't see. When the governed path is also the fastest one, policy stops chasing agents and starts traveling with them.

Your next agent can arrive with its guardrails already in place

If a practical walkthrough of endpoint-based AI agent governance would help, we're happy to show you what we've built. Request a demo.

FAQs

What is AI agent governance?

AI agent governance is the set of identity, policy, and runtime controls deciding what AI agents can access and do. It works best when those controls apply where agents execute, including the browser, the desktop, and the endpoint session.

How is AI agent governance different from traditional AI governance?

Traditional AI governance focuses on models and on outputs a person reviews before acting. Agent governance has to control actions taken with real permissions, so the controls follow the action rather than the model.

How do you govern AI agents that use employee credentials?

Give each production agent its own non-human identity with a named owner, instead of letting it borrow a person's session. Then issue just-in-time, task-scoped credentials that expire when the task ends.

What should an AI agent inventory include?

At minimum, record each agent's owner, runtime location, tools and MCP servers, data reach, autonomy tier, and last review date. Build it from what's discovered on endpoints, not only from what's registered in a console.

Does AI agent governance slow down adoption?

It shouldn't, as long as the governed path is the easiest one to use. Good governance doesn't slow agents down; it gives them a safe lane to scale.