AI Agent Governance: Inventory, Policy, and Audit for Autonomous Agents

AI governance vs. AI agent governance

Traditional AI governance concerns itself with models and data: bias and fairness, training-data provenance, documentation, and conformance with frameworks like the EU AI Act and the NIST AI RMF. That work matters, and none of it goes away. But it governs what a system is: its properties, its risks on paper.

Agent governance governs what a system does. An agent is an actor: it executes shell commands, edits files, installs packages, holds credentials, and connects to other systems, often thousands of times a day, faster than any review process. A model card cannot stop a write to a production config; only a control evaluated at the moment of the action can. Agent governance is therefore an operational discipline, closer to identity and endpoint security than to policy documentation, and it is the slice of AI governance this page covers.

Why agents break existing controls

Every existing governance mechanism assumes properties agents don’t have. Access reviews assume a stable population: agents are created casually, sometimes per task, and offboarded never. Accountability assumes a manager: agents have an owner at best, and often not even that. Approval workflows assume human speed: an agent takes more actions in an hour than a change advisory board reviews in a quarter. And delegation chains blur attribution: an agent spawning sub-agents leaves “who did this” genuinely ambiguous unless capture happens at the runtime.

Regulators, meanwhile, do not exempt non-human actors. Logging, oversight, and risk-management obligations under regimes like the EU AI Act, DORA, and NIS2 apply to actions taken on the organization’s behalf: whoever, or whatever, took them. The gap between “our controls assume humans” and “our actors aren’t” is the problem the three layers below close.

Layer 1, Inventory: agents and non-human identities

You cannot govern what you cannot list. The first layer is a live inventory of every agent and non-human identity , which agents exist, on which machines, run by whom, connected to what. The hard part is the entries nobody registered: the coding agent a developer installed last week, the MCP server added to a local config. Nexus builds the inventory from two directions ( connectors feeding the governance console, and runtime capture from wrapped agents) and its shadow-AI detection surfaces the unregistered remainder as findings rather than leaving it as an unknown unknown.

Layer 2, Policy-as-code, enforced at execution time

The second layer turns policy from prose into code: rules that are declared, versioned, and evaluated automatically. Two evaluation points matter. In the console, policy runs continuously against the inventory and produces findings, which agents drifted out of compliance, and against exactly which rule. In the terminal, policy runs before each action executes: Nexus evaluates every tool call in-flight and denies destructive commands, protected-path writes, and installs from unapproved registries, with a stated reason. Enforce and audit modes per repo make rollout progressive: observe first, block once the policy fits reality. This execution-time posture is zero trust applied to agents, covered further in zero trust for AI agents.

Layer 3, Audit: prompt → change → flag → why

The third layer is the trail regulators and incident responders actually need: for any change, which session produced it, on which terminal, in which repo, triggered by which prompt (fingerprint only on the default privacy tier), and what the policy decision was at each step. Nexus writes this per-session, per-terminal, per-user record to a durable ledger as events occur: sessions, tool actions with blocked flags, file changes with protected flags, dependency installs, token usage and cost. It is the difference between asserting oversight existed and being able to show it. The capture architecture behind this is detailed in agent observability.

Blast-radius analysis

One capability sits across all three layers: the identity graph. Every agent and non-human identity is a node; edges are the credentials and connections that link them to systems. The graph answers the question that matters most in an incident: if this agent’s credential were compromised right now, what could an attacker reach? That is blast radius, and it converts an abstract inventory into a prioritized risk picture: the agent with a stale token into production ranks above fifty sandboxed experiments. It is also the lens that ties agent governance to classic lateral-movement thinking: agents are simply the newest, fastest-multiplying class of privileged identity.

Governance framework mapping

The three layers are not a parallel universe to compliance frameworks . They are the operational mechanics those frameworks assume. Kept deliberately general (see NIST AI RMF, EU AI Act, and AI compliance for the framework detail):

Choosing an AI governance platform for agents

Seven evaluation criteria separate agent-governance platforms from adjacent tools wearing the label:

1. Agent-level visibility: does it see agent actions (sessions, tool calls, file changes, installs), or only SaaS connections?
2. Execution-time enforcement: can it block a violating action before it runs, or does it only raise findings afterward?
3. Identity coverage: are agents and non-human identities first-class inventory with an identity graph and blast radius?
4. Audit depth: does the trail link prompt → change → flag → policy decision, with per-terminal attribution?
5. Privacy model: can you govern without recording developer prompt text? (Metadata-only capture should be the default.)
6. Open-core capture: can you inspect the code that decides what is recorded and what is blocked?
7. Cost accountability: does it attribute token usage and spend per agent, repo, and user?

An honest note on the market: SaaS-governance tools (the SSPM category) govern AI apps through OAuth visibility and are the right choice for that plane. Agent-governance tools instrument the agents themselves. If your teams run coding agents like Claude Code, you need the second kind, and possibly both.

AI agent governance FAQ