Defender Impact
Enterprise IAM programs were architected for humans: verify once at hiring, provision credentials, trust indefinitely. Agentic AI identities shatter that model — and this governance framework gives defenders the conceptual and operational scaffolding to treat every AI agent as a first-class, continuously verifiable identity rather than a privileged proxy of a human account. For organisations now operating hundreds or thousands of agents, this is the difference between auditable accountability and a fog of authorised-but-unattributable machine actions.
Capability Overview
The framework, surfaced in Danelle Au’s SecurityWeek analysis, centres on a deceptively simple but operationally significant reframe: every autonomous AI agent inside your perimeter is a proxy identity — not a tool, not a service, not an extension of its sponsoring user. It holds credentials, chains tools, queries sensitive datastores, and executes at machine speed. Under the legacy trust model, all of this activity is logged as routine authorised action by the human whose account the agent inherits. The agent is invisible as an identity.
The governance framework addresses this by asserting that agents must be provisioned with discrete, least-privilege identities scoped to their specific task surface. Human-inherited permission sets are explicitly out of scope. Each agent identity should carry its own API keys, role bindings, and audit trail — making agent actions attributable to the agent, not laundered through a human principal.
Critically, the framework also names the mid-session threat explicitly: agent trust can be subverted after provisioning through prompt injection, poisoned external tools, or hidden instruction injection. This means static provisioning-time controls are necessary but insufficient. The framework calls for continuous session-level verification — monitoring whether the instructions driving an agent at runtime are consistent with its authorised purpose.
The North Korean IT worker analogy is deliberate and instructive. Those operatives passed onboarding controls but were never re-verified during the session. AI agents face the same structural vulnerability. The governance answer is the same: shift from perimeter trust to continuous verification.
Defensive Advances
Discrete agent identity provisioning means security teams can now scope blast radius at the agent level. A compromised agent can be revoked without touching the human account it previously inherited, and forensic teams can reconstruct exactly what that agent accessed rather than sifting through a shared human principal’s logs.
Behavioural baselining per agent identity becomes achievable once agents have their own identity surface. Teams can establish what a given agent’s normal tool invocation pattern looks like and alert on deviations — a concrete early-warning signal for mid-session instruction hijacking.
Agent identity registers (analogous to CMDBs) give security operations a queryable inventory of what agents exist, what credentials they hold, what tools they can invoke, and who sponsored their deployment. This directly closes the asset-visibility gap that makes agentic sprawl undetectable today.
Residual Gaps
The framework is conceptually mature but tooling support is uneven. Most enterprise IAM platforms — Okta, Entra ID, SailPoint — have nascent or no native support for non-human agent identity schemas. Organisations will need to implement agent registries and monitoring pipelines as custom integrations until vendor support matures.
Continuous session-level verification remains a research-adjacent capability. Behavioural baselining for agents is achievable in principle but requires sufficient agent operational history to establish reliable baselines, and threshold-tuning for heterogeneous agent populations is non-trivial.
Standardisation is absent. There is no cross-vendor agent identity schema — meaning agent identities provisioned in one cloud environment are opaque to another, complicating multi-cloud and SaaS-integrated agent governance.
Framework Mapping
- AML.T0012 (Valid Accounts) — the framework directly addresses agents operating under borrowed human credentials, closing the attribution gap this technique exploits.
- AML.T0051 / AML.T0080 (Prompt Injection / Agent Context Poisoning) — continuous session verification is the defensive response to mid-session instruction subversion.
- AML.T0083 / AML.T0098 (Credentials from Agent Configuration / Tool Credential Harvesting) — discrete agent identity provisioning limits credential exposure scope.
- LLM08 (Excessive Agency) — least-privilege agent identities are the structural control that bounds excessive agency at the identity layer.
Deployment Considerations
Organisations should sequence adoption in three phases: (1) Inventory — build an agent register before attempting any governance controls; you cannot govern what you cannot see. (2) Isolate — decouple agent credentials from human accounts for all agents with write access to sensitive systems first. (3) Monitor — instrument agent sessions with SIEM or XDR pipelines using the agent identity as the primary correlation key.
Prerequisite: executive alignment that AI agent deployment is an IAM event, not solely a development or business unit decision.
Defender Checklist
- Enumerate all deployed AI agents and document their current credential bindings
- Stand up an agent identity register with fields for scope, sponsoring team, tool access, and credential type
- Revoke human-inherited credentials from agents with access to sensitive or regulated data stores
- Assign discrete service accounts or API keys scoped to each agent’s task surface
- Configure SIEM alerting on agent identity anomalies — unexpected tool invocations, off-hours execution, or lateral credential use
- Establish a review cadence (quarterly minimum) for agent identity access rights as agent scope evolves
- Engage IAM vendors on roadmap for native non-human / agent identity schema support