Agentic AI identity governance, a framework for the enterprise.

What needs governing

Agentic AI governance has three distinct surfaces. Confusing them leads to governance documents that read well and change nothing:

• The model. The underlying LLM, its training data, capabilities, evaluations, safety posture. This is AI risk management territory: NIST AI RMF, ISO/IEC 42001, model cards. Covered elsewhere in detail; not this article's focus.
• The agent's identity. Who the agent is, what it can access, how it authenticates, what trail it leaves. The NHI governance surface, this article.
• The agent's actions. What it did, whether it was right, who is accountable if it wasn't. The operational governance surface, partly identity, partly process, partly legal.

An effective enterprise governance program addresses all three, and is explicit about which layer a given control lives at. Mixing the layers is the most common failure mode we see.

Lifecycle

Every agent identity in the enterprise should have a defined lifecycle:

1. Proposal and classification

• A team proposes a new agent deployment. The proposal describes: purpose, model used, tools/data accessed, who it acts on behalf of, expected volume, risk classification.
• Classification under the EU AI Act or equivalent: is this high-risk? general-purpose? limited-risk? Each class carries a different obligation set.
• Data classification: what sensitivity of data may the agent access? Regulated data triggers additional controls.

2. Design review

• Identity design: which IdP, which workload-identity mechanism, which scope model.
• Delegation model: which users the agent acts for, under what authorisation.
• Tool set: which MCP servers or APIs, with what permissions.
• Audit design: what is logged, where, for how long.
• Kill-switch design: how is the agent stopped if it goes wrong.

3. Provisioning

• Agent identity issued with bounded scope. Workload-attested where runtime permits.
• Tool authorisations granted (fine-grained, per-tool OAuth consents).
• Audit pipelines configured.
• Monitoring dashboards live before production traffic.

4. Runtime

• Per-session ephemeral credential issuance (not per-agent long-lived).
• Real-time policy enforcement on each tool call.
• Telemetry flows to audit systems.
• Anomaly detection (unusual tool sequences, off-hours activity, unexpected data volumes).

5. Change

• Agent definition changes (new tools added, model upgraded, scope expanded) trigger re-review.
• Model upgrades specifically treated as a change event, not a silent deploy.
• Version pinning and rollback paths.

6. Retirement

• When an agent is retired, all its credentials are revoked (workload identities, OAuth consents, API keys).
• Associated tool authorisations are withdrawn.
• Audit data is preserved per retention policy.
• Dependent processes documented and migrated.

Scope and policy

Agent scope is where governance meets engineering. The principle is simple: an agent's authorised actions at any moment should be the minimum needed for the immediate task, not the maximum it might ever need.

Implementation mechanisms:

• Fine-grained OAuth scopes per tool. Not "write to the CRM" but "create contacts in the CRM".
• Just-in-time scope elevation. Start with read-only. Elevate to write only when the task requires it, with user confirmation for sensitive writes.
• Tool-level policy at the server. Policy decisions enforced where tools execute, not only where they're requested. An agent with a token nominally permitting X can still be denied X by a tool-server policy.
• Tenant isolation. Agents scoped to specific tenants cannot accidentally cross tenant boundaries, even if the IdP token would technically permit it.
• Data-sensitivity gating. Agents classified for handling regulated data run in environments that materially enforce that classification (data-labelled tool responses, DLP egress, etc.).

Audit and accountability

The audit model for agents has to answer harder questions than the audit model for service accounts. An auditor will ask:

1. Who instantiated this agent? (tenant + user)
2. What model was it running? (model provider + version)
3. What did the user prompt it with?
4. What tools did it call, in what order, with what arguments?
5. What did each tool return?
6. What was the final output to the user?
7. Was any output of a regulated nature (legal advice, financial recommendation, medical guidance)?
8. Did any step receive human confirmation? If yes, from whom?

Building logs that support this reconstruction is non-trivial. Key design choices:

• Correlation IDs flow through every layer, session start, each LLM call, each tool invocation.
• Session-scoped retention of prompts and outputs for regulated classifications; shorter retention otherwise.
• Sensitive-data redaction at the log boundary, not at query time. Redact before persistence.
• Tamper-evident storage (append-only logs, hash-chained segments) for high-assurance contexts.
• Explicit data-classification tagging on every tool response so downstream analytics inherit the classification.

Human oversight

EU AI Act Article 14 imposes explicit human oversight obligations for high-risk AI systems. Operationally, this translates to:

• A human is able to monitor agent operation in real time (or near-real-time).
• A human can intervene in the agent's output before it is acted upon.
• A human can stop the agent, reverse its actions where possible, and escalate.
• The oversight role is defined, trained, and resourced, not a notional assignment on an org chart.

Engineering implications: agent actions that affect users or external systems need an approval layer that a human can interpose. For critical actions, the approval is synchronous (agent blocks until approved). For lower-risk actions, it may be asynchronous review with the ability to roll back. The identity layer enforces the boundary.

Kill-switches

Every production agent deployment needs an identity-layer kill-switch, a mechanism to revoke the agent's ability to act within seconds, reliably, from a named operator role.

Components of a working kill-switch:

• Token revocation endpoint that propagates to downstream consumers in seconds, not minutes.
• Workload identity revocation via SPIRE's registration API, OIDC IdP, or equivalent.
• Tool-server allow-lists keyed on agent identity that can be flipped to deny-all.
• Authorised operator role with clear escalation path and documented practice.
• Scheduled drills (quarterly) that exercise the kill-switch end-to-end under realistic conditions.

Regulatory intersections

Agent governance maturity model

Most enterprises in April 2026 sit at level 0 or 1 for agent deployments. Level 2 is the minimum consistent with regulated-industry defensibility. Level 3 is where organisations serious about scaling agent deployments need to be within 12 months.

Frequently asked questions

What is agentic AI governance in the identity context?

It is the discipline of ensuring that autonomous agents have distinct identities, bounded authority, traceable delegation, and a revocation path that works faster than they act. It is narrower than AI governance generally, which also covers model behaviour, bias and safety. The identity slice is where accountability is established, and it is the slice auditors reach first because it produces records.

How does NHI governance relate to responsible AI?

Responsible AI commitments generally include accountability, transparency and human oversight. None of those can be evidenced without identity: accountability requires knowing which agent acted, transparency requires a reconstructable record, and oversight requires that a human's authority is separable from the agent's own. Identity governance is therefore the mechanism through which several responsible AI principles become auditable rather than aspirational.

What is the biggest governance gap in agent deployments?

The delegation chain. Most deployments can say which service principal made a call; very few can say which agent acted for which human under which consent. That gap is invisible until an auditor or an incident asks the question, and it is extremely difficult to retrofit because it requires changes at both the token-issuance and logging layers.

How should agents be classified for risk?

By what they can reach and whether a human is in the loop, not by model capability. An agent with read-only access to a public dataset is low risk regardless of how sophisticated it is; an agent with write access to a financial system is high risk even if it is simple. Classification by reach also has the advantage of being verifiable from your own configuration rather than from vendor claims.

Does the EU AI Act require agent identity controls?

Not by name. The Act does not use the term non-human identity. Its logging, record-keeping and human-oversight obligations for in-scope systems cannot be satisfied without being able to attribute actions and demonstrate oversight, which in practice requires identity and delegation records. Note that the Digital Omnibus deferred the high-risk obligations to 2 December 2027 for Annex III systems.