Why do organisations struggle to secure AI agents and other non human identities in day to day operations?

Why This Matters for Security Teams

Security teams struggle with AI agents and other non human identities because the control model was built for people, not autonomous software that can chain tools, retry actions, and operate at machine speed. Human-centric IAM assumes predictable sessions and review cycles. Agents often use secrets directly, create fresh execution paths, and take actions that no access matrix anticipated. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same operational truth: identity, context, and runtime behaviour now have to be governed together.

This is why traditional reviews often miss the real issue. A credential may be valid, but still be misused by an agent that was never supposed to reach a downstream API, database, or support workflow. NHIMG research on AI agents: the new attack surface shows how quickly these gaps become material: 80% of organisations report agent actions beyond intended scope, and only 52% can track and audit the data their agents access. In practice, many security teams encounter agent misuse only after the data has already moved or the credentials have already been abused.

How It Works in Practice

Securing these identities starts by treating each agent as an active workload with its own identity, not as an extension of a user account. Best practice is evolving toward workload identity, runtime policy evaluation, and just-in-time credential issuance. That means an agent should receive the minimum access needed for a specific task, for a short window, with revocation tied to task completion rather than a human ticket queue. In mature designs, the agent proves what it is using cryptographic workload identity, while policy decides what it may do based on current context.

Operationally, this is where NIST AI Risk Management Framework governance and the CSA MAESTRO agentic AI threat modeling framework are useful. Teams define the agent’s objective, enumerate the tools it can call, classify the data it may touch, and enforce policy at request time. Where NHI programs mature, they also rotate secrets aggressively, separate human and machine entitlements, and use short-lived tokens instead of static keys. NHIMG’s LLMjacking research underscores why: exposed credentials can be targeted within minutes, which makes long-lived secrets a poor fit for autonomous systems.

• Use workload identity for the agent, not a shared service account.
• Issue ephemeral credentials per task and revoke them automatically.
• Evaluate access with policy-as-code at runtime, not only during provisioning.
• Log tool calls, data access, and downstream actions as separate audit events.
• Segment high-risk tools so an agent cannot move from one benign action to lateral privilege escalation.

These controls tend to break down when agents are embedded in legacy automation that still depends on long-lived API keys, broad service roles, and manual exception handling.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance stronger containment against delivery speed and support burden. That tradeoff is real, especially in environments where teams have many short-lived agents, vendor-hosted copilots, or rapid integration work. There is no universal standard for this yet, but current guidance suggests separating low-risk retrieval tasks from high-risk action-taking workflows so policy can be stricter where blast radius is larger.

Edge cases are common. A read-only agent can still be dangerous if it can exfiltrate sensitive context into another system. A “trusted” internal agent can still be compromised through prompt injection, token theft, or hidden tool chaining. This is why NHIMG’s OWASP NHI Top 10 and the broader AI agents research matter in day-to-day operations: they frame the issue as identity misuse, not just model misbehaviour. In the hardest cases, such as multi-agent pipelines that inherit each other’s context, security teams need to assume that one weak link can propagate risk across the whole workflow.

For that reason, the most resilient programmes do not rely on a single control. They combine identity proof, short-lived secrets, scoped tools, and continuous review of what each agent has actually done, not what the design document said it should do.

Related resources from NHI Mgmt Group

• Why do AI agents and other non-human identities complicate trust assumptions in enterprise environments?
• How should organisations govern SCIM for AI agents and other non-human identities?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?