What is agent governance?

By Nolan Sullivan, Founding Growth Engineer

·Published September 8, 2026·Updated September 14, 2026

Most oversight efforts attach rules to software or to users: what was purchased, who gets access. It falls outside both groups. At runtime, it picks what to do, has delegated rights, and works for someone, usually by way of a Model Context Protocol (MCP) service. Since what an agent picks matters through single API requests, those requests are the target whichever way you define oversight.

Why does agent governance have two meanings?

The term can mean 2 separate things.

Sometimes people use “agent governance” for AI oversight, conflating the two terms. The Cloud Security Alliance titled its April 2026 research note The AI Agent Governance Gap: What CISOs Need Now, and much of the analyst and vendor material follows the same usage: agents are the reason the program is being funded, so the program takes their name. Seen this way, governance and AI governance mean the same organization-wide work, and the label stretches to include assistants and copilots too.

The term can also mean the narrower task of overseeing background agents. Background agents are those that run with no one steering. Infosec groups need to figure out how to plug those bots into corporate oversight: login audits, update approvals, the SIEM, vendor threats, and offboarding. Every employee’s tasks fall under those rules automatically. An idle helper tool does nothing by itself until a person hooks it up.

This article covers both readings. The section below explains the four controls that apply to both broad and narrow uses of the term.

How is agent governance different from AI governance?

Used that way, both labels point to the same plan, and that works for directors. The distinction earns its keep in program design, because the agent slice breaks assumptions the rest of the program relies on.

The organization-wide effort is AI governance. All AI apps at work are included, like assistants and copilots embedded inside SaaS apps, built around visibility over what’s there, rights for who may enter, rules for what may pass through, plus observability over past events. That effort, plus the setup teams now converging toward to support it, is discussed in the plain AI guide and a AI Control Plane guide.

As used here for these measures, it is the portion of that effort aimed at them. They require a separate approach since bots violate 3 of the program’s assumptions:

• A chat assistant answers questions, so governing it means governing data exposure. An agent calls tools, so governing it means governing actions: create_refund, merge_pull_request, send_email.
• An application does what it was built to do. An agent chooses its next call at runtime, so its behavior cannot be fully reviewed before deployment.
• An application authenticates its users. An agent is itself a principal, and which identity it acts under is a design decision someone has to make, not a property it arrives with.

So the same 4 roles still fit, though they attach onto another part. For other AI tools, pricing is per app or user. For them, it is the function invocation.

What does agent governance have to cover?

Managing AI tools takes 4 rules, each one adding to the last. Each is a separate field discussed fully in its own guide.

Finding and listing assets goes ahead because each other step assumes a target set. Each agent inventory entry lists the tool, who runs it, and whether it is sanctioned, while checks back up the list by surfacing unapproved tools, the group covered under shadow AI meaning.

Who they are says which actor appears. The link points to an actual actor: whoever controls the sign-in, or a specific account tied to an individual. A shared service account fails all three of attribution, least privilege, and lifecycle, for the reasons laid out in agent identity and in the wider non-human identity category.

Rules and permissions set what a known actor can do, evaluated each function use, not just when it connects. Which permissions an agent should hold, and how they derive from the identity and access management the organization already runs, is the subject of extending IAM to agents and task-scoped credentials.

Audit comes from the other parts: each permit and block tied to an identity, with exportable records sent into SIEM files, plus checks reviewable by the rule then in place. It’s also an artifact the assessor wants before anything else.

How do you discover background agents?

It lacks a login and user slot, so tools made to spot users and apps miss it. You’ll see it as an app account in the login system, OAuth approval on a SaaS tenant, an API token with an AI vendor, a workflow in a repository, or outbound calls to an inference endpoint. It means using those traces to make a named entry for each asset. The Agent discovery page walks through everything, while the links underneath locate background agents alone.

Which sources reveal background agents?

• Identity provider logs. Microsoft Entra ID writes noninteractive authentications to a separate service principal sign-in log, where the app presents its own certificate or secret rather than a user signing in. The Okta System Log carries the equivalent events. An agent that authenticates as a client appears here first.
• OAuth consent grants. Agents built on SaaS platforms enter through consent screens rather than procurement. A review of third-party app grants in Google Workspace, Microsoft 365, Salesforce, and GitHub lists every agent a person authorized in three clicks.
• Model provider admin APIs. The Anthropic Admin API and the OpenAI Admin API list every API key in the organization with its creator and workspace. A key whose creator has left, or one that maps to no registered agent, is a finding.
• Egress to inference endpoints. DNS and proxy logs showing regular connections to api.anthropic.com, api.openai.com, or generativelanguage.googleapis.com from a server rather than a laptop mark a workload that calls a model. Paired with tool API calls from the same host, that workload is a background agent.
• Repository and CI configuration. Vendor-hosted coding agents install as Git-provider apps. Cursor cloud agents, for example, require a Cursor and Git-provider administrator to authorize the organization and repositories, so the app installation audit enumerates them. Workflow files that invoke Claude Code, Codex, or Copilot as an action are found by scanning the repository.
• Endpoint configuration. MCP servers are declared in known files such as the Claude Desktop and Cursor configs, and scanners such as mcp-scan read those locations directly. Agent hooks fire on every tool call inside coding agents, so they report the servers an agent is wired to, including ones never approved. The shadow AI reference covers the endpoint architecture.

How do you tell an agent from an ordinary service account?

These traces show each non-human account, and most are standard apps. A few signs set them apart:

• Cadence and shape. A cron job calls the same endpoint on the same schedule. An agent authenticates, then makes a variable sequence of calls to several tools, on a schedule no person would keep and with no interactive session behind it.
• Model traffic next to tool traffic. A host that reaches an inference endpoint and then calls internal APIs is running an agent loop. Either signal alone is ambiguous, and the pair identifies the loop.
• Scope drift. A service account uses the same two scopes for years. An agent’s legitimate behavior changes when someone edits its instructions or adds a tool, so its call pattern drifts without a deploy.

The split counts because they get other tools. In a March 2026 survey by the Cloud Security Alliance and Aembit, 68% of organizations said they cannot clearly distinguish AI agent activity from human activity, which leaves the identity and access controls in the next two sections with no population to attach to.

What does a discovery finding become?

Each result turns into an asset entry or decommission task. The CSA’s April 2026 research note on the AI agent governance gap lists what the record should capture: “agent identity, delegated permissions, connected tools and data sources, human owner of record, and the business process each agent supports.” Microsoft applies the same test in the risk table of its agent registry for Microsoft 365, where a shadow agent is one with “no registry entry, no owner, or no Microsoft Entra Agent ID,” rated critical. For agent inventory, the page explains the entry layout, while background agents explains the unattended details: the starting event, any requester, and used credential.

How do you give a background agent an identity?

Agent identity ties each login to an actual user. With that user-steered system, the one in charge is whoever is using it. Since nobody sits at the keys, a background process must construct its own binding instead of getting it inherited. What determines this: whose power it holds, and how the system demonstrates that on every call.

Whose authority does the run carry?

Background agents fit into a pair of groups:

• A run that works for one person. Someone assigned the task and left. The agent should keep that person’s delegated authority through a task-scoped credential: short-lived, issued for this run, naming the person as subject and the agent as actor, and dead when the task ends. Deprovisioning the person stops new credentials from being issued.
• A run that works for the organization. A nightly triage worker or a queue consumer has no requester. It needs a dedicated identity of its own, registered in the directory as a non-human identity with a named human owner and a fixed grant.

Both examples follow separate paths, and the rules show it. The MCP enterprise-managed authorization extension, built on the identity assertion authorization grant that Okta ships as Cross App Access, begins with a user logging in. Okta’s own documentation says not to use Cross App Access for autonomous agents that run “without an active user session or human initiation.” Those agents authenticate as workloads.

How does a workload identity work for an agent?

A workload is verified through attestation, not a saved credential. It verifies the job’s location and identity, then creates one short-lived credential. SPIFFE defines the pattern: the workload receives an SVID, an X.509 certificate or JWT carrying its identifier, from a local API and never holds a bootstrap secret. The leading IAM providers treat agent identity on the same footing:

• Google Cloud agent identity issues each agent a SPIFFE-based certificate valid for 24 hours and renewed automatically, and the identity cannot mint long-lived keys.
• Microsoft Entra agent identities “don’t have credentials of their own.” They authenticate with federated identity credentials issued by an agent identity blueprint, and every agent identity requires at least one human sponsor responsible for renewal, removal, and suspension.
• Okta registers agents in Universal Directory as first-class identities with human owners and short-lived scoped tokens in place of standing credentials.

When behind-the-scenes software does something for a user, both sides are in the token. OAuth 2.0 token exchange (RFC 8693) defines the act claim to identify the acting party while the sub claim stays the person, and a chain of delegation nests one act inside another. The IETF transaction tokens draft goes further for the call chain inside an organization: a signed JWT with a lifetime “on the order of minutes or less,” a unique txn identifier, and immutable context that every downstream service can log. This composite is what agent identity composite covers, and its trail is what checks use.

What lifecycle does an agent identity need?

They get no counterpart to the joiner, mover, and leaver flow unless a team builds one. The CSA’s draft agent identity governance framework from March 2026 sets the baseline: every autonomous agent has a named sponsor, is reviewed for continued need quarterly, and is decommissioned with all credentials revoked when its project ends. That same study found just 28% of companies can tie what bots do to a person responsible in every system. Improper offboarding is the first item on the OWASP Non-Human Identities Top 10 because the credential outlives the person who created it. Succession, which moves control once the named person departs, closes that gap, and Entra plus SailPoint both include it.

How do you subscribe background agents to access controls?

Each employee’s entry is subscribed to built-in safeguards: a job defines its permission, periodic audits, a request path, and a sign-off for costly items. It gets no such things unless a person enrolls it. This enrollment includes 4 steps; IAM extending to agents explains the directory work.

Grant a fixed, task-sized scope

Each agent’s access includes only the apps its job calls for, named once and tied to its profile. Persistent access rights remain the norm. In a January 2026 CyberArk study of 500 practitioners, only 1% had fully adopted just-in-time access, 91% had at least half of privileged access always on, and 45% applied the same privilege model to AI identities as to people. Privileged-service vendors have started converging around another way: it is not given a credential at all, the system injects one only when needed, scoped to the job, and then revoked once the job completes. Task-scoped credentials describes the mechanics.

Authorize each tool call

When a token gets created, its access is fixed, so it can’t know details from a request not yet made. Per-call authorization inserts a policy decision point along the request path. Each request carries an agent’s ID, who it represents if anyone, the function label, and the details, and the result is permit, reject, or needs consent. The OpenID Foundation’s AuthZEN Authorization API 1.0 became a final specification in January 2026 for this exchange between decision and enforcement points, and a working group draft published in June 2026 maps MCP tool calls onto it, with the person in the subject, the agent in the context, and the arguments as resource attributes. That is what makes get_invoice and create_refund separate decisions on the same connection, the difference tool-call RBAC draws against a server allowlist.

Gate destructive actions on a person

The MCP specification says there should always be a human in the loop with the ability to deny tool invocations. For that, they aren’t present live, so sign-off has to happen another way. The OpenID client-initiated backchannel authentication flow fits: the agent sends a request with a readable message such as “Approve refund of $240 to order 8821,” the owner approves on their phone or in Slack, and the resulting token is single-use and bound to that request. Microsoft’s least-privilege guidance for agents makes the same call, with step-up controls for destructive or high-impact actions and human approval for bulk updates. Limit by radius, not each request, because a queue with 99% passing makes reviewers rubber-stamp.

Put the grant into review and change management

• Access reviews. Agent grants go into the same certification campaigns as service accounts. Okta added access certifications for AI agents in July 2026, and Microsoft Entra ID Governance runs access reviews over agent identities. The CSA’s May 2026 whitepaper on non-human identity governance sets the cadence at quarterly minimum and monthly for high-privilege agents.
• Change management. An agent’s behavior is its instructions plus its tool set. Editing either is a change to a production system and gets the same review a code deploy does. Microsoft’s pattern is to re-review access when workflows, tools, data scope, or deployment environment materially change and to deny unreviewed tools by default. An MCP server that changes a tool description upstream is a change nobody filed.
• Data controls travel with the principal. When the agent acts for a person, row-level policies and masking apply as they would to that person. When it acts as itself, the agent’s own grant carries them. Either way, an agent that reads private data, processes untrusted content, and can communicate outward has all three legs of Simon Willison’s lethal trifecta, and the access model is what removes one.

How do you audit background agents?

A user’s record is a byproduct of their login. Checks for that bot need planning, because records show a bot, and teams need to know who controls it. The audit record is useful for three reasons.

Every record resolves to a name

The AWS Well-Architected agentic AI lens states the rule: “Each logged action includes attribution to the initiating source (a human user session, an upstream event, a schedule, or another agent).” In practice each tool-call record carries the agent identity, the run or session identifier, the person it acts for when there is one, and the owner of record from the inventory. The act value from the identity section moves the initial pair along a request sequence. Microsoft Entra sign-in logs now tag each event with an agent type and the blueprint it was created from, so an instance correlates back to its definition. When the team checks who made refund around 03:00, it shows the tool, its keeper, and the user tied to it, all together.

The record is complete and outside the agent’s reach

For each use, the log stores its timestamp, the function label and its details, or a hash, plus the ruling and rule set applied when evaluated, the intended asset, and the result. The same AWS guidance adds the constraint that matters most for autonomous systems: “the agent whose behavior you are investigating can’t be the entity that controls its own logs.” Logs land in a store the agent’s runtime role cannot write to or delete from, with object lock or an equivalent. In August 2025, the Salesloft Drift breach made the reason clear. Attackers using stolen OAuth tokens deleted their query jobs to hide activity, but the audit logs still retained the evidence that let more than 700 organizations scope the theft.

The record lands where security already looks

Telemetry matters only when it arrives in SIEM-ready format that SIEM tools can query. Schemas keep converging:

• The OpenTelemetry GenAI semantic conventions define agent and tool spans, with an execute_tool operation carrying the tool name, call id, agent id, and conversation id. The conventions are still marked development status.
• The OWASP Agent Observability Standard extends the OCSF API activity class with the tool call, agent context, and step, so agent events ingest into any SIEM that already speaks OCSF.

Splunk ships a suspicious MCP activities analytic story with detections for prompt injection, sensitive file search, and suspicious GitHub operations over MCP traffic, and CrowdStrike streams AI runtime findings into Falcon Next-Gen SIEM. Landing agent activity in the same SIEM console rather than a separate AI console means the same analyst, with the same correlation rules, sees agent activity next to the sign-in and privilege events it relates to.

Retention follows the regulation that already applies

The EU AI Act requires providers of high-risk systems to keep automatically generated logs for at least six months and deployers to do the same, though the Digital Omnibus package that entered into force in July 2026 moved the Annex III high-risk obligations to December 2027. Colorado’s revised AI law, SB 26-189, takes effect in January 2027 and requires developers and deployers to retain records for at least three years. Lawyers decide if a tool is covered; the proof setup never changes: store each per-call log until the strictest rule demands it, with immutable and attributable data.

IBM’s 2026 Cost of a Data Breach report found that 21% of organizations had an AI-related breach, 92% of those lacked AI access controls, and the average breach took 247 days to identify and contain. Per-call attribution cuts that time to identify and contain by tying every action to a name.

How does the Speakeasy AI Control Plane run the four controls?

You can assembled every safeguard above using the specs and items listed under its heading. With Speakeasy’s AI Control Plane, they come together where they connect to APIs:

• Discovery from traffic and endpoints. Agents reach tools through the MCP gateway, so every sanctioned agent, the servers it connects to, and its last activity are recorded as a side effect of use, and discovery hooks surface the agents and MCP servers that never went through review.
• Identity from the directory. Sessions authenticate through the identity provider the organization already runs. A run that works for a person receives a task-scoped credential naming that person and the agent. A run that works for the organization gets a dedicated identity with a named owner.
• Policy per tool call. Each call is authorized against the principal’s grant when it happens, so a read-only tool and a destructive one are separate decisions rather than one standing credential.
• Audit into the SIEM. Every allow and deny lands in audit logs under a name, with the agent, the run, and the owner on the row, exportable to the SIEM the security team already runs.

To watch the 4 settings work on your own systems, talk to us.