What do security teams get wrong about agentic identity?

Why Security Teams Misread Agentic Identity Risk

Security teams often frame an agent like a service account with a nicer interface, then miss the part that matters most: the agent is autonomous, goal-driven, and capable of changing tools mid-task. That makes static RBAC and credential-centric reviews too shallow. The real question is not only what the identity can do, but what the agent is trying to do right now, under what context, and with which upstream signals.

This is why current guidance is shifting toward runtime authorisation, tighter session boundaries, and short-lived credentials rather than long-lived secrets. It is also why the attack surface expands quickly when teams do not separate workload identity from the permission model. The OWASP Agentic Applications Top 10 and NIST AI Risk Management Framework both point practitioners toward governance that evaluates behaviour, context, and accountability together. NHIMG research shows the scale of the problem: 80% of organisations report AI agents have already acted beyond intended scope, including unauthorised system access and credential exposure, which mirrors what happens when teams assume a single policy can describe an entire agent session. In practice, many security teams encounter agentic overreach only after sensitive data has already moved or tools have already been chained, rather than through intentional control design.

How Agentic Governance Actually Needs to Work

For autonomous agents, governance has to move from static entitlement review to intent-based authorisation. That means the system evaluates each request at runtime, using the task objective, data sensitivity, environment, and current state of the session. A policy engine can still enforce RBAC and ZTA principles, but it should do so at decision time, not as a one-time assignment. This is where CSA MAESTRO agentic AI threat modeling framework is useful: it encourages teams to model agent behaviour, tool access, and trust boundaries as a dynamic workflow, not a fixed user profile.

In practice, the strongest pattern is JIT credential provisioning with ephemeral secrets. The agent should receive the minimum access needed for the current task, for the shortest feasible time, and the secret should be revoked when the task ends or the state changes. Workload identity is the identity primitive here: cryptographic proof of what the agent is, not just what token it borrowed. Teams implementing SPIFFE/SPIRE or OIDC-based workload identity can bind the agent to a controlled execution context, then layer policy-as-code on top for real-time evaluation. That matters because many failures start with secrets that live too long or travel too far; NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is a poor fit for a system that can keep acting after a task has logically ended.

• Use intent-based authorisation for each tool call, not one broad role for the whole agent.
• Issue JIT credentials per session or per task, with automatic expiry and revocation.
• Separate workload identity from secrets so the agent’s runtime state is verifiable.
• Log every tool invocation and downstream access for audit and containment.

These controls tend to break down in multi-agent pipelines where one agent can pass authority to another without preserving the original intent and context.

Common Variations and Edge Cases

Tighter control often increases orchestration overhead, so organisations have to balance security gain against latency, complexity, and developer friction. That tradeoff is real, especially in environments that need high throughput or continuous tool use. Best practice is evolving, but there is no universal standard for how often an agent should re-authorise inside a long-running workflow.

One common edge case is delegated autonomy: an agent may be allowed to plan, but not execute, or to retrieve data but not write it. Another is multi-step escalation, where each step looks harmless until the chain becomes sensitive. In those cases, broad allowlists are too blunt, and pure denial can block legitimate work. Current guidance suggests using policy tiers, stronger approvals for high-risk actions, and explicit separation between read, transform, and act permissions. For implementation detail, practitioners should compare the OWASP Agentic AI Top 10 with NHIMG’s Analysis of Claude Code Security, because code-assist and agentic execution share the same failure pattern: the system is trusted to decide its next move, then given too much authority to do it. The key exception is regulated or safety-critical environments, where even short-lived credentials may need additional human approval before the agent crosses a privilege boundary.

Related resources from NHI Mgmt Group

• What do teams get wrong about per-seat licensing in agentic environments?
• What do security teams get wrong about prompt filtering for AI agents?
• How should security teams govern machine identity credentials in agentic AI environments?
• What do security teams get wrong about workload identity in cloud and CI/CD environments?