AI agents often appear outside formal onboarding through shadow AI, scripts, or workflow tools, so they never enter the normal identity inventory. Without discovery across browsers, endpoints, and automation layers, IAM teams cannot enforce policy, certify access, or prove accountability.
Why This Matters for Security Teams
AI agents create a visibility problem because they do not arrive as a single, neatly provisioned identity. They emerge through browser automation, plugins, scripts, workflow engines, and embedded tools, which means the IAM team often sees activity before it sees an owner. That breaks identity inventory, access certification, and accountability. It also makes policy enforcement reactive, because the agent’s execution path can change from one task to the next.
This is why current guidance increasingly treats agentic systems as a distinct security surface rather than a normal user population. The AI Agents: The New Attack Surface report found that only 52% of companies can track and audit the data their AI agents access, leaving a large compliance blind spot. In parallel, the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both reinforce that discovery, governance, and runtime control have to account for autonomous behaviour, not just authenticated sessions. In practice, many security teams encounter agent visibility gaps only after an agent has already accessed data or chained actions across systems, rather than through intentional onboarding.
How It Works in Practice
The practical issue is not just “who logged in,” but “what autonomous workload is acting, with what authority, and under what context.” For AI agents, identity should be anchored to the workload itself, then paired with short-lived credentials and runtime policy. That is why many architectures are moving toward workload identity primitives such as SPIFFE or OIDC-based service tokens, where the system proves what the agent is before it requests access. Static IAM roles alone are too blunt because the same agent may need different permissions depending on task, data sensitivity, model output, or approval state.
In a workable model, discovery spans endpoints, browser sessions, orchestration tools, CI/CD pipelines, and API gateways. IAM then correlates those signals to the agent’s owner, purpose, and scope. The NHI lifecycle perspective in NHI Lifecycle Management Guide is useful here because onboarding, rotation, revocation, and review must happen continuously rather than at human hire time. Practitioners should expect:
- Per-task or per-session authorization, not broad standing entitlements.
- Ephemeral secrets with tight TTLs and automatic revocation.
- Policy-as-code decisions evaluated at request time, using current context.
- Audit trails that preserve both the initiating human and the autonomous agent path.
That approach aligns with the threat findings in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where exposed credentials are rapidly abused once discovered, and it is consistent with the runtime governance emphasis in CSA MAESTRO agentic AI threat modeling framework. These controls tend to break down when agents are embedded in unmanaged browser automation or citizen-developed workflows because the identity trail fragments before central IAM can enforce policy.
Common Variations and Edge Cases
Tighter agent visibility often increases operational overhead, requiring organisations to balance audit depth against deployment speed and developer friction. That tradeoff is especially visible in environments with many short-lived agents, such as support copilots, code assistants, and multi-agent orchestration chains. Best practice is evolving, but there is no universal standard for this yet.
One common edge case is shadow AI, where an agent is launched through a browser extension or local script and never enters the identity registry. Another is delegated automation, where a human approves the workflow once, then the agent continues acting under stale assumptions. A third is cross-domain movement, where an agent switches from chat to ticketing, source control, and cloud APIs. In those environments, simple login monitoring is not enough; teams need event-level correlation and explicit scoping. The NIST AI Risk Management Framework is useful for structuring that governance, but it does not remove the need for local detective controls. NHIMG’s broader analysis in Top 10 NHI Issues also highlights that missing ownership and weak lifecycle control remain the most common causes of blind spots. The visibility problem worsens when teams treat an agent as a single account instead of a fleet of runtime events tied to changing intent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic systems create hidden access paths and runtime risk. |
| CSA MAESTRO | T1 | MAESTRO addresses agent threat modeling and control coverage gaps. |
| NIST AI RMF | AI RMF governs accountability, measurement, and monitoring for AI systems. |
Use AI RMF to assign ownership, monitor behaviour, and document agent risk decisions.
Related resources from NHI Mgmt Group
- Why do AI agents create more IAM risk than ordinary developer tools?
- Why do AI agents create a governance problem for IAM teams?
- What should teams do when AI agents or NHIs create access patterns that provisioning did not anticipate?
- Why do AI agents create new risk in non-human identity management?
