AI agent governance: How security teams find, track, and control AI agents

AI agent governance gives security teams control over the autonomous agents already working in their SaaS environment. This guide covers how to find every agent, see what it can reach, and make sure a person is accountable for it.

‍

Key takeaways

• AI agents act autonomously across systems. Governing them takes a different approach than governing AI tools that respond to prompts.
• Most enterprise environments already have AI agents operating without IT approval. Employees deploy them, SaaS platforms auto-provision them, and MCP server connections extend them.
• The first job in AI agent governance is discovery. You can’t apply controls to agents you don’t know exist.
• An AI agent inventory should cover OAuth grants, API keys, MCP server connections, and non-human identities, not just application installations.
• AI agent lifecycle management applies controls at every stage, including registration and ownership, least privilege, guardrails, access reviews, monitoring, offboarding, and retirement.

‍

What is AI agent governance?

AI agent governance is the set of processes, policies, and controls security teams use to discover, assess, and manage the AI agents operating in their environment. Also called agentic AI governance, it covers any AI system that takes actions on its own, with access to email, files, code, and business systems, instead of returning an answer for a person to review.

‍

The need arrived fast. In 2025, Salesforce made Agentforce generally available, Microsoft shipped Copilot Studio to enterprise customers, and OpenAI opened GPT Actions to anyone with an API key. Within a year, AI agents went from developer experiment to standard enterprise capability, and most security teams still don’t know how many are running in their environments.

‍

An AI agent is any software system that can take autonomous actions to accomplish a goal: querying external APIs, running code, reading or writing files, sending messages, or connecting to other services, without a human approving each step. Unlike a traditional AI tool, which responds to a prompt and waits for the next one, an agent persists, plans, and acts. That matters for governance because agents act on the data they can reach, sending email, editing files, and changing records in business systems.

‍

How is AI agent governance different from AI governance?

AI governance decides which AI tools employees may use and what data they can share with them. AI agent governance manages autonomous systems that already have access to your environment and act on it. It is narrower, more operational, and focused on identities and permissions rather than usage policy.

‍

When a security team governs AI tool adoption, the core questions are: which tools are employees using, what data are they sending to those tools, and do those tools meet the organization’s security standards? The controls are mostly discovery and policy enforcement. 

‍

For that broader program, see our guide to AI governance.

‍

Agent governance asks different questions. An agent may have been granted OAuth access to a user’s calendar, email, and documents. It may hold an API key with write access to a production system. It may be connected to a Model Context Protocol server that extends its reach to file systems, databases, and internal APIs. And it may keep operating after the employee who deployed it has left the organization.

‍

What makes agentic AI different from AI tools?

An AI tool waits for a prompt, returns an answer, and stops. A person reads the output and decides what happens next. An AI agent works differently in four ways that matter for security:

• It runs continuously: Agents can operate around the clock on schedules, triggers, or events, with no one watching each run.
• It has no human checkpoint between steps: An agent plans a task, calls a tool, reads the result, and takes the next action on its own. A bad instruction at step one carries through every step after it.
• It holds standing access: Agents authenticate with OAuth tokens, API keys, or service accounts that persist between tasks and usually don’t expire.
• Its reach grows over time: Developers add tools, platforms ship new capabilities, and new MCP server connections extend what the agent can touch, often without a new review.

The result is a structural visibility gap. Most existing controls, such as SSO, MDM, and network monitoring, were designed around human identities and approved applications. AI agents operate as non-human identities that don’t appear in those systems. A tool inventory will miss them. Network logs will show their traffic but won’t identify it as agent activity. An MDM policy has no concept of an autonomous agent credential.

‍

What are shadow AI agents?

Shadow AI agents are autonomous agents running in your environment without security’s knowledge or approval. Unlike shadow AI tools, which produce outputs a person reviews, shadow agents take actions directly: sending email, editing files, pushing code, or calling APIs, often with credentials that outlast the employee who set them up.

‍

A shadow AI tool generates outputs that a human reviews and acts on. A shadow agent’s actions persist after the conversation ends. When the agent runs under a service account or automation framework credentials, they persist even after the employee who created it has been offboarded.

‍

Behind every agent is a human decision. Someone adopted a tool, connected an integration, or switched on a platform feature, usually to get work done faster and usually without a security review. That makes shadow agents a workforce issue as much as a technical one. They enter enterprise environments through three main paths.

‍

Employee-built AI agents and their OAuth access

Building a personal agent takes minutes. Platforms like OpenAI’s GPTs, Anthropic’s Claude tool-use features, and no-code agent builders let users create agents with OAuth connections to their work accounts. To IT, this looks like a new OAuth grant from a user, which may or may not trigger a review depending on whether the organization monitors OAuth.

‍

The risk isn’t limited to developers. Browser extension agents, AI assistants with deep calendar and email integrations, and consumer AI platforms with business connectors are used at work by employees who don’t think of themselves as deploying an agent. They’re configuring a productivity tool that happens to act on their behalf.

‍

Agents auto-provisioned by SaaS platforms

Enterprise SaaS platforms are building agents into their products. Salesforce Agentforce lets users create agents within Salesforce. Microsoft Copilot Studio lets users build agents connected to SharePoint, Teams, and Outlook. ServiceNow and Workday are adding similar capabilities, and HubSpot’s Breeze Agents operate inside the CRM.

‍

These agents are often created without a dedicated IT review because they live inside platforms IT already manages. The security team approved Salesforce. That doesn’t mean they’ve evaluated every Agentforce agent a sales ops user created last Tuesday.

‍

How MCP servers expand an AI agent’s access

The Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools and data sources. An agent using MCP can connect to any MCP server, including servers that expose file systems, databases, internal APIs, and code repositories.

‍

For example, a support agent might use MCP servers to pull tickets from Zendesk, account details from Salesforce, and articles from a knowledge base, all in one workflow. Each connection is useful, and each one is another point that needs to be vetted.

‍

As such, an agent’s effective access can be much larger than its stated permissions. A user might authorize an agent to access their email. If that agent also connects to an MCP server that exposes the company’s code repository, its actual access is email plus code, and the second connection may never have been part of the original approval.

‍

Our research on MCP server exposure and credential risk documents how MCP server sprawl introduces credential exposure and privilege escalation that traditional SaaS discovery tools don’t surface. The OpenClaw AI incident, which exposed 1.5 million API tokens through a popular AI tool, shows how quickly agent-layer risk can materialize. MCP server connections are the least visible and fastest-growing part of the SaaS attack surface.

‍

How do you build an AI agent inventory?

To build an AI agent inventory, review four places agents authenticate: OAuth grants, API keys, MCP server connections, and the agent registries inside SaaS platforms. For each agent, record its credential, access scope, owner, platform, MCP connections, and recent activity. Then monitor continuously, because new agents appear every week.

‍

Governance can’t come before discovery. Before you can apply least privilege, run access reviews, or set runtime policies, you need to know which agents are operating in your environment.

‍

An AI agent inventory is not the same as an AI tool inventory. An AI tool inventory asks which applications employees are using. An agent inventory asks which autonomous systems have access to your environment, what they can do, and who authorized them.

‍

Which AI agents belong in your AI agent inventory?

A typical mid-market enterprise running modern SaaS already has agents in several categories, whether IT knows it or not.

• Platform-provisioned agents: Organizations on Salesforce likely have Agentforce agents created by sales ops or marketing. Microsoft 365 environments may have Copilot Studio agents connected to SharePoint or Teams data. HubSpot Breeze Agents are active wherever a marketer has explored the feature.
• Employee-built agents: Employees on OpenAI’s platform may have created GPTs with Google Workspace or Slack OAuth connections. Developers using Anthropic, LangChain, or similar frameworks may have built agents with API key access to internal systems.
• Browser extension agents: Several popular browser extensions now take actions for users across web applications. They typically hold OAuth grants that appear alongside normal SaaS connections.
• Workflow-tool agents: Workflows built in Zapier, Make, or n8n that call an AI model have effectively become agents. They receive a trigger, call an LLM, and take an action, often with write access to business systems.

Where to find AI agents: OAuth grants, API keys, MCP servers, and platform registries

AI agents surface across several layers that a conventional SaaS discovery approach may not cover.

• OAuth grants: Most agents authenticate to user accounts through OAuth. An agent with access to a Google Workspace or Microsoft 365 account appears in that user’s list of connected apps, but traditional OAuth risk management focuses on sanctioned third-party SaaS, not agentic connections. Look for grants with write scopes to email, calendar, documents, and collaboration tools. Write scopes are a strong signal of an agentic connection worth reviewing.
• API keys: Developer-built agents often authenticate with API keys stored in code repositories, environment variables, or developer tools. An API key with write access to a production system is a non-human identity with standing access that most identity governance programs don’t track.
• MCP server connections: Agents using MCP connect to servers that may not appear anywhere in your SaaS inventory. The connection is agent-to-server rather than user-to-application, so it bypasses discovery methods built around human identity. Finding it requires visibility into the agent’s runtime environment or traffic to known MCP server endpoints.
• SaaS platform agent registries: Salesforce Agentforce, Microsoft Copilot Studio, ServiceNow, and similar platforms keep internal registries of the agents created in them. Administrators can see these registries, but they require intentional review and won’t surface in a conventional SaaS discovery scan.

For a side-by-side look at eight ways to find agents, download the Practitioner’s Guide to Shadow AI Agent Discovery.

‍

What to record for each agent

For each agent you discover, capture at minimum:

• Identity: What credential does the agent use: a user OAuth grant, a service account, an API key, or a platform-specific agent credential?
• Access scope: Which data stores, systems, or services can it reach? Are any permissions broader than its purpose requires?
• Deployment source: Who deployed it: a user, a developer, or an automated platform action? Was there a security review first?
• Platform: Which framework or SaaS product does it run on, and what are that platform’s data handling and retention practices?
• MCP connections: Does it connect to any MCP servers? What tools and data sources do those servers expose?
• Activity status: Has it been active recently? Do its actions match its stated purpose?

Keeping the inventory current

AI agent inventories go stale fast. Employees deploy new agents, SaaS platforms add agentic features in product updates, and the MCP server ecosystem grows weekly. An inventory built today is incomplete by next month.

‍

Keeping it current takes continuous monitoring, not point-in-time scans. AI security and governance tools built for this environment surface new agent connections as they appear, flag changes in access scope, and alert on high-risk grants when they’re created, not at the next quarterly review.

‍

Agentic AI risk management: which risks matter most?

Agentic AI risk management focuses on four risks: agents with more privilege than they need, broad access to sensitive data, unmanaged non-human identities, and MCP server connections that extend access beyond what anyone approved. Prioritize agents with write access to production systems and broad data scope first.

‍

Privilege escalation

AI agents often request broader permissions than their purpose requires. A calendar assistant may have requested access to a user’s full Google Workspace account, including Drive and Gmail. An agent first granted read access may have been updated by its developer to include write access after the original review.

‍

The risk mirrors what privileged access management addresses for human users, but it applies to non-human identities that don’t appear in the same review cycles. Agents with unnecessary write access to production systems are the highest-priority escalation risk.

‍

Data access scope and leakage

Agents with broad access to email, documents, databases, and code repositories can expose data on purpose or by accident. With AI agents, leakage is often indirect. An agent may summarize sensitive documents and include that content in an API call to an external model provider, where it persists in logs or training pipelines. No file was downloaded and no email was forwarded, but the content left the organization’s control.

‍

Our research on browser extensions that harvest and exfiltrate AI chat conversations shows the pattern: tools that appear to run locally can send session content to external servers without triggering traditional DLP controls.

‍

AI agent identity management and non-human identity sprawl

AI agent identity management means treating every agent credential as an identity with a named owner, a defined scope, an expiration policy, and a place in your access reviews.

‍

Every agent credential, whether an OAuth token, API key, or service account, is a non-human identity. Non-human identities typically don’t expire, aren’t reviewed on the same cadence as human users, and survive employee offboarding unless someone revokes them.

‍

Identity and access management programs are well established for people, but most organizations have weak or no governance for non-human identities at scale. As agent adoption grows, the number of non-human identities is outpacing the programs built to manage them.

‍

MCP server security risks

MCP server connections are the least visible part of an agent’s access. A user who grants an agent access to their calendar may not know which MCP servers that agent also connects to. The developer decides that at build time, and the MCP specification doesn’t require user consent for each server connection.

‍

Four MCP attack patterns matter most for agent governance:

• Malicious servers: an MCP server built or modified to capture the credentials or data passed through it.
• Tool poisoning: hidden instructions in a tool’s description that steer the agent into actions the user never asked for.
• Tool shadowing: a malicious server that changes how an agent uses tools from a separate, trusted server.
• Vulnerable servers: legitimate servers with weak authentication or overly broad permissions that attackers can exploit.

Each one turns a single agent connection into a path to systems the original approval never covered. For attack details and mitigations, see our post on MCP security risks.

‍

AI agent lifecycle management: from registration to retirement

AI agent lifecycle management is the process of governing an agent from the day it’s deployed to the day it’s retired. It has seven stages: registration and ownership, least privilege, guardrails, access reviews, monitoring, offboarding, and retirement. An inventory without these controls is just a catalog of your exposure.

‍

AI agent registration and ownership

Treat a new agent the way you’d treat a new hire. Before it gets production access, record who deployed it, what business function it serves, which credentials it uses, and which systems it needs, and give it a named human owner. An agent with no owner has nobody to answer access review questions, nobody to notice when it misbehaves, and nobody to retire it when it’s no longer needed.

‍

Least privilege for AI agents

Least privilege means granting only the access an agent needs for its intended function. In practice, that means reviewing the permissions each agent requests and removing any that exceed its purpose.

‍

This is harder with agents than with people because agents often request permissions during setup, before IT has reviewed them. A practical approach: flag any agent OAuth grant with write scopes for review before activation, and keep a list of approved permission profiles for common agent types in your environment.

‍

Guardrails for AI agents

Guardrails limit what an agent can do, even when it has access. Common guardrails include read-only permissions by default, human approval before high-impact actions such as sending external email or changing production data, an allowlist of approved MCP servers, and limits on which data an agent can pass to an outside model. Guardrails don’t replace visibility. They only work on agents you know about.

‍

Access reviews for agent OAuth grants

User access reviews are a standard requirement in SOC 2 and security audits, but most cover only user-to-application access. They should also cover agent-to-application access, including OAuth grants held by agents, API keys with standing access, and service accounts used by agent platforms.

‍

Agent access reviews are more complex because no agent can confirm whether it still needs access. The review should include the employee who deployed the agent, the application owner, and, for platform-provisioned agents, the business unit that owns the platform.

‍

SOC 2 compliance requirements increasingly cover AI agent access. Organizations that can’t produce an agent inventory at audit time can’t show scope completeness for in-scope applications, a gap auditors are beginning to ask about.

‍

AI agent monitoring: runtime behavior and drift

AI agent monitoring tracks what an agent does after it’s approved. Least privilege and access reviews cover an agent’s permissions at a point in time. Monitoring covers its behavior over time.

‍

Runtime monitoring looks for anomalies: unusual data access patterns, requests to new API endpoints, connections to new MCP servers, or a sudden jump in the scope or volume of actions. Setting a baseline is harder than with traditional software, because an agent’s actions depend on the prompts it receives and the decisions it makes on its own.

‍

Drift detection matters because developers can update agents without triggering a new security review, and platform-provisioned agents can gain capabilities through SaaS product updates. An agent approved last quarter may have a different effective access scope today.

‍

Offboarding: what happens when the employee leaves

Employee offboarding revokes a departing employee’s access to SaaS applications, but it usually doesn’t address the agents that employee deployed under their own identity.

‍

When an employee leaves, review every agent running under their OAuth credentials. If the agent performs a business function you want to keep, move its credentials to a service account or assign a new owner. If it was a personal productivity tool, revoke it. Otherwise, a non-human identity with the former employee’s access keeps operating under orphaned credentials.

‍

The same applies to mergers and acquisitions. An acquired company’s agents are part of the identity and access scope you inherit. Agents running under credentials of departed employees, or with access to systems no longer in scope, are a hidden exposure that standard M&A IT integration checklists don’t catch.

‍

The fix doesn’t require a new process. Add one step to your offboarding checklist: review the departing employee’s OAuth grants and API keys for agentic connections.

‍

Retiring and decommissioning AI agents

Agents outlive their purpose. A pilot ends, a workflow moves to a new tool, or a platform-provisioned agent goes unused. Retiring an agent means more than turning it off: revoke its OAuth grants, rotate or delete its API keys, disconnect its MCP servers, disable any service account it used, and record the retirement in your inventory. A dormant agent with live credentials is still a non-human identity with standing access.

‍

Who owns AI agent governance?

AI agent governance should be owned by the team that already manages SaaS discovery, OAuth risk, and access reviews. GRC defines the audit evidence requirements, and business unit leaders are accountable for agents built inside the SaaS platforms they own.

‍

Most organizations don’t have a named owner yet, and that gap is part of the problem. Security teams have the threat model but often lack visibility into the SaaS platforms where agents are created. IT manages SaaS access but may not have the context to evaluate agent-specific risks. AppSec understands development patterns but typically doesn’t monitor employee-deployed agents. GRC needs the evidence but usually isn’t involved until audit time.

‍

A workable model gives primary ownership to whichever team manages SaaS discovery, OAuth risk management, and access reviews today. That team sets up the inventory process, defines risk criteria, and owns the access review workflow.

‍

Scale the program to your exposure. An organization with a handful of developer-built agents needs less than one where Agentforce is active across the whole sales team. A risk-tiered approach works best: start with agents that have write access to production systems and broad data scope, then extend to lower-risk agents as the program matures.

‍

Bring your workforce into AI agent governance

Blocking AI tools outright tends to backfire. Employees work around controls that slow them down, and their agents end up in places security can’t see. Programs that work give employees a fast, clear path to do the right thing:

• A short AI acceptable use policy that says which agent types and permissions are allowed
• Guidance delivered when an employee connects a new agent, not weeks later in a review
• A fast approval path for agents that need broader access
• AI agent governance included in security onboarding for new hires

The goal is to let people move quickly while security keeps visibility and oversight.

‍

Nudge Security discovers AI agent connections alongside 175,000+ SaaS apps on Day One, without network changes or prior knowledge of your environment. Security teams get a single view of agent OAuth grants, platform-provisioned agents, and MCP server connections. See how Nudge Security handles AI security and governance.

‍

Where to start with AI agent governance

The organizations that govern AI agents well in 2026 won’t be the ones with the longest policy. They’ll be the ones that built an inventory first. Governance frameworks, access reviews, and runtime controls are only as good as the inventory they’re applied to. An unknown agent is an unreviewed agent, and an unreviewed agent is a blind spot in your identity and access program, no matter how mature that program is.

‍

The starting point is the same for every organization: find every agent credential in your environment, understand what it can do, and make sure someone owns it.

‍

Nudge Security gives security teams the visibility to take that step. Discover your AI agent exposure alongside your full SaaS and AI estate. See plans or start a free trial.