What happened
A practical framework published by The Hacker News, drawing on guidance from identity security vendor Orchid Security, argues that AI agent governance fails when it stops at the identity provider. The model it sets out treats each agent as a non-human identity with a human owner, a stated purpose, scoped authorization, an expiration date and continuous monitoring.
The problem it describes is a gap between configured access and executed action. Identity platforms record lifecycle events and enforce authentication at the edge of an application, which describes access as intended. What an agent actually did once inside, which tools it invoked and which records it read, often never reaches those same logs. The guide calls the unmanaged middle identity dark matter: agents, credentials, application local accounts and authentication paths that central identity data does not report.
It lists the recurring lifecycle failures it sees. Agents with no named owner and therefore no accountability for their continued existence. Static API keys and tokens that persist across deployments with no rotation tied to retirement. Agents that inherit a user or service account's permissions wholesale instead of receiving task scoped authority. Agents spawned by other workloads that never register with the identity provider. OWASP's Top 10 for LLM applications names the same pattern as excessive agency.
The controls it recommends are mostly borrowed from human identity programmes. Task scoped grants that expire with the task, tool allowlisting, constrained retrieval sources, and an approval threshold for high consequence actions. Credential design should favour workload identity federation and short lived, automatically rotated credentials, with OAuth 2.0 Token Exchange used where an agent acts on a user's behalf so that the agent's own identity stays separate from the authority lent to it.
The audit argument is the sharpest part of the guide. NIST SP 800-53's audit and accountability controls assume records sufficient to reconstruct a sequence of actions, not a record showing a policy existed. Because valid accounts abuse and privilege escalation generate normal looking authentication events, monitoring has to compare the agent's intended task against its actual execution across applications and infrastructure, and to revoke delegated authority when the two diverge.
Why this is a GRC story
An agent without an owner is unowned risk. Every other control depends on being able to name the person accountable for the agent's purpose. Without that, access reviews have nobody to ask.
Inventory is the first audit question. If you cannot list the agents running in your environment, their owners and their expiry dates, then no certification statement about identity controls is verifiable.
Intent, entitlement and execution are three different records. Regulators and auditors increasingly want the third. A screenshot of a role definition proves the least interesting of the three.
What to watch
Whether credential standards for verifiable agent identity and constrained delegation firm up enough to be procured against, and whether IAM vendors keep shipping discovery that reads application and infrastructure state rather than configuration alone. Watch too for regulatory guidance that asks for agent level audit records by default.
A useful exercise this quarter: ask for a list of every agent running in your environment, who owns each one, when its access expires and what evidence you hold of what each agent executed last month. If that list takes more than a day to assemble, the gap is real.
Attribution: Analysis based on The Hacker News and related public reporting. This article is original commentary, not a repost of the source material.