AI agent governance is the operating model that keeps AI agents accountable: an inventory of every agent, an owner for each one, a sanctioning decision, least-privilege credentials, continuous monitoring of what the agent actually did, bounded remediation, and exceptions that expire. A program that cannot answer what an agent did and which sensitive data it touched is a policy document, not governance. Strac runs that operating model on one graph (Agent → Principal → Permissions → Resources → Sensitive data) across Google Workspace, AWS Bedrock AgentCore, GitHub Copilot, Slack, Salesforce Agentforce, Claude, ChatGPT and Cursor, turning each policy rule into a finding with proof and a fix.
Most companies already have an AI policy. It says which models are approved, what employees may paste into a chatbot, and who signs off on new vendors. Almost none of those policies say anything useful about the Claude Code session an engineer connected to Google Drive last Tuesday, the Agentforce bot that runs as an integration user nobody remembers creating, or the Bedrock agent whose IAM role can read production secrets and invoke Lambda.
AI agent governance is the operating model that closes that gap. It is the set of decisions, controls and measurements that keep every AI agent in the business accountable to a named owner, limited to the access it needs, observed while it works, and fixable when it drifts. It sits on top of the four questions that define AI agent security: what is acting and as which identity, what can it do, what did it actually do, and what sensitive data can it reach and did it touch.
The test for whether you have governance or just a document is simple. Pick any agent in the company and ask what it did yesterday and which sensitive data it touched. If the answer is a shrug, the policy is not enforced, and an auditor will reach the same conclusion in ten minutes.
This guide lays out the operating model end to end: the definition, why agents are a different problem from the SaaS apps and service accounts you already govern, the seven-stage lifecycle, the policy rule by rule with the finding each rule produces, the metrics that prove the program, how it maps to NIST AI RMF, ISO 42001, the EU AI Act and your existing SOC 2 and ISO 27001 controls, and what to skip in year one.
AI agent governance is the practice of maintaining an accurate inventory of every AI agent and AI-enabled automation in an organization, assigning each one an accountable owner, deciding which agents are sanctioned for which data, scoping each agent's credentials to least privilege, monitoring what agents actually do, remediating findings through bounded and reversible actions, and recording exceptions with an expiry date.
That definition has two halves, and most programs only build the first.
The first half is posture: inventory, ownership, sanctioning and permissions. It answers what could happen. The second half is activity and data: what the agent actually did, which resources it touched, and which of those resources contain PII, PHI, PCI, secrets, source code or financial data. It answers what did happen and what it exposed.
Posture alone is where identity-security, SaaS-posture and non-human-identity tools stop, and it is where a governance program quietly fails. An agent with a perfectly scoped credential can still be prompt-injected into exporting a customer list, and an inventory that says the agent "can read Drive" says nothing about whether it read payroll.xlsx at 10:04 this morning. Governance that cannot distinguish can from did cannot verify that its own rules are being followed.
A useful shorthand: AI governance decides which AI systems the company builds and buys. AI agent governance decides how each agent, once it exists, is identified, permissioned, watched and corrected. The first is a committee. The second is an operating model that runs every day.
The company already governs service accounts, OAuth apps and SaaS integrations. Why does an agent need a different model?
Because an agent chooses its own next action. A SaaS integration does what its code says. An agent interprets an instruction in natural language, picks tools, chains calls, and reads or writes whatever its credential allows. Its blast radius is the union of every permission behind every credential it can borrow, and its behavior changes with every prompt it receives, including prompts injected by the data it reads. You cannot review the code and sign it off, because the instructions arrive at runtime.
Three things follow, and each one breaks the governance model inherited from SaaS and NHI programs.
Agents do not have one kind of identity. They have six. How well you can attribute an action to an agent, and revoke its access, depends entirely on which pattern it uses:
.webp)
client_id and user
The fastest-growing agents leave no footprint in any admin API. A computer-use agent that drives Alice's open Salesforce tab creates no OAuth grant and no service account. A local Claude Code or Cursor session with an MCP server on a laptop never appears in a SaaS posture scan. Salesforce's audit log says Alice exported the report, and it is correct, and it is useless for governance. The only way to govern patterns E and F is evidence from where the agent runs: the browser and the endpoint. This is the same reason shadow AI programs that rely on SSO logs alone undercount badly.
Permission is not behavior. A grant tells you what the provider would allow. Only the audit log, the compliance API, or an MCP, browser or endpoint sensor tells you what the agent did. Programs that infer did from can alarm on agents that never touch sensitive data and miss the agent whose narrow scope was enough to export the one file that mattered. The deeper treatment of attribution confidence is in AI agent identity governance.
Governance is a loop, not a list. These seven stages run continuously, and each one feeds the next. The sequence mirrors how a mature program is built and how a platform should expose it.
Three notes on running the loop.
Inventory decides whether the rest is real. Discovery has to cover the systems where agents, credentials and sensitive data overlap most: Google Workspace OAuth grants, AWS and Bedrock AgentCore runtimes, GitHub Apps and Copilot agent sessions, Slack apps, Salesforce connected apps and Agentforce bots, the Anthropic and OpenAI compliance feeds, and Cursor. It also has to cover the laptop, because that is where local agents and MCP servers live. The playbook is in how to discover AI agents.
Ownership before permissions. Teams often start by arguing about scopes. Start by finding the owner. An agent with no accountable owner cannot be scoped, sanctioned or safely turned off, because there is nobody to ask what it is for.
Separate "is an agent" from "is a non-human identity." In the inventory used throughout this guide, 4,112 non-human identities existed and 214 were used by AI agents. Treat every CI bot and backup service account as an agent and the real risk disappears into noise, and owners stop answering requests.
A policy that cannot be evaluated against the inventory is a wish. Each rule below is written so that a platform can check it continuously, and each one maps to a specific finding with a default severity. The severity logic is deterministic and visible: sensitivity × action capability × breadth × sanctioning × observed use × attribution confidence. No opaque score.
* resources behind the credentialOne further finding is less a rule than the evidence that the rules are working. Agent observed accessing sensitive data (High; Critical for secrets or highly regulated data combined with a risky capability) is what monitoring produces when a sanctioned agent does its job on classified resources. It is the record the sanctioning decision was supposed to anticipate, and the row an auditor will ask to see.
Some practical guidance on tuning these rules:
A governance program is measured by a small number of outcomes, not by the number of rules it has. If you report three numbers to the board, report these.
1. Percentage of agents with an accountable owner. The single most predictive metric for whether anything else works. A program that starts at 40 percent and reaches 90 percent in a quarter has done the hardest part. One stuck at 60 percent has a discovery problem or an org-chart problem, and both are fixable.
2. Median time to remediate a High or Critical finding. Measured from the finding's creation to the provider resync that confirms the change. This separates a platform with bounded remediation from one that files tickets. In the program dashboard at the top of this guide, the median fell from 9.4 days to 2.1 days once one-click revocation and policy deltas replaced manual tickets.
3. Count of unsanctioned agents with sensitive reach. The number that should trend to zero and stay there. It combines the inventory, the sanctioning decision and the data join in one figure, which is why it is hard to fake.
Four supporting metrics belong on the same dashboard: the share of agents found only by browser or endpoint sensors (if it is zero, the inventory is missing patterns E and F); the granted-versus-used ratio per agent, which should rise as reductions land; the count of agents on shared human identities, which should fall to zero; and exceptions past expiry, which should always be zero.
One rule for all of these: show coverage alongside the number. Seventeen agents with sensitive reach means something different when Drive, GitHub and S3 classifications are complete than when half the S3 buckets have never been scanned. A number without its coverage is a guess with a decimal point.
No framework names "AI agents" as a control category yet. Every one of them already covers agents through the identities they use and the data they touch, and auditors have started asking for the agent inventory first because it is the fastest way to see whether the identity and logging controls are real. The mapping below is intentionally generic. The detailed crosswalk is in AI agent governance frameworks.
The frameworks differ in vocabulary and agree on substance: an inventory, an owner, a least-privilege credential, a log of what happened, and a documented way to fix it. None of them accept "we cannot see that agent" as a control. The identity and logging requirements apply to a computer-use agent driving a browser session exactly as they apply to a service account, which is why governance has to be built on sensors as well as APIs.
For companies that also run a broader AI data governance program, the agent inventory is a new set of principals pointed at the same classified-data map. The two programs share the data layer and should share the platform.
Governance programs fail from ambition about as often as from neglect. These are the traps we see most, and the ones we chose not to build first.
Strac already runs the data layer for AI at hundreds of companies: browser and endpoint AI DLP, MCP DLP for agent tool calls, shadow AI discovery, and a classified inventory of sensitive data across SaaS, cloud and endpoints. AI agent governance runs the seven-stage operating model on top of that inventory, on one graph: Agent → Principal → Permissions → Resources → Sensitive data, with activity joined through evidence.
What the operating model looks like in the product:
For larger organizations the same model extends to multiple tenants, business units and approval chains, covered in enterprise AI agent governance. Deploy it read-only in an afternoon. The first policy preview is usually the moment the program stops being a document.
👉 Book a demo and we will run the agent inventory read-only against your Google Workspace or GitHub tenant on the call, then preview the full governance policy against it so you can see the owner requests, findings and reductions before anything changes.
AI agent governance is the operating model that keeps every AI agent in an organization accountable: an inventory of all agents, a named owner for each, a sanctioning decision per agent and data category, least-privilege credentials, continuous monitoring of what each agent actually did and which sensitive data it touched, bounded remediation, and exceptions that expire. It is built on top of AI agent security's four questions (identity, authorization, activity, data) and turns them into rules, findings and metrics.
AI governance decides which AI systems the company builds and buys, how they are evaluated, and who is responsible for them at the portfolio level. AI agent governance is the day-to-day control of each agent once it exists: who owns it, what identity it runs as, what it may reach, what it did, and how it is corrected. The first is typically a committee and a set of documents. The second has to be a continuously evaluated policy, because agents change behavior with every instruction they receive.
At minimum: a discovered inventory covering SaaS, cloud, AI vendors and endpoints; an owner on every agent; sanctioning tied to data categories; a least-privilege rule measured against observed use; activity monitoring joined to a sensitive-data inventory; a remediation model that states what changes and whether it is reversible; exceptions with expiry; and three reported metrics (ownership rate, median time to remediate, unsanctioned agents with sensitive reach). If the framework cannot say what a given agent did yesterday, it is incomplete.
Identity-security, SSPM and NHI tools inventory principals and permissions, which answers what an agent could do. An AI agent governance platform adds what the agent actually did, which sensitive data it touched, and attribution for agents that never appear in an admin API, such as computer-use agents driving a human's browser session or local agents with MCP servers on a laptop. It joins all of that to a classified-data inventory so every finding comes with proof.
Through sensors, because nothing else can see them. A local Claude Code, Cursor or Codex session, its MCP configuration, and a computer-use agent controlling a logged-in SaaS tab produce no OAuth grant and no service account. Endpoint and browser evidence (process, session, domain, file movement, timing, AI session ID where available) is correlated with the provider's audit log, and the attribution is labeled as correlated rather than provider-native. Shadow MCP servers are the most common thing this surfaces in the first week.
Read-only discovery across Google Workspace, AWS, GitHub, Slack, Salesforce, Claude and ChatGPT takes an afternoon, and the first inventory and policy preview follow in the same session. Reaching a high ownership rate and working the first wave of High and Critical findings is a quarter of work for most teams, driven mostly by how quickly owners respond. Enforcement rules should run in monitor mode for a couple of weeks before being turned on.
.avif){kind=icon}
.gif)
