Should organisations prioritize securing machine identities before expanding agentic AI use?

Why This Matters for Security Teams

For agentic AI, the security problem is not just the model. It is the autonomous software entity acting with execution authority, tool access, and a growing ability to chain actions in ways that humans do not fully predict. That is why machine identity governance has to come before broad deployment. If a service account, token, or API key can be reused outside its intended task, every agent becomes a force multiplier for exposure.

Current guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward governance, traceability, and contextual controls rather than static trust. That matters because agents rarely operate like human users with stable patterns. They may call tools, request secrets, and pivot across systems based on prompt content or prior outputs. NHIMG research has documented how quickly exposed credentials are abused in the wild, including the AI LLM hijack breach and the broader risk coverage in OWASP NHI Top 10.

In practice, many security teams encounter unsafe agent behaviour only after a tool account, secret, or dataset has already been abused, rather than through intentional design.

How It Works in Practice

The practical sequence is straightforward: inventory the non-human identities first, classify which of them can be used by agents, and remove any assumption that a long-lived credential is acceptable simply because the workload is not human. Static RBAC remains useful for broad boundaries, but it is not enough for autonomous, goal-driven systems. Agents need intent-based authorisation at request time, where policy evaluates what the agent is trying to do, which tool it wants, what data it is requesting, and whether the task context justifies access.

That approach usually combines workload identity, JIT credentials, and short-lived secrets. Instead of embedding static tokens in prompts, configs, or shared vault paths, issue ephemeral credentials per task or per session, then revoke them automatically when the action completes. This is the logic behind workload identity primitives such as SPIFFE/SPIRE and short-lived OIDC-based access. It also aligns with the direction of the CSA MAESTRO agentic AI threat modeling framework, which emphasizes threat-aware design for agentic systems, and with NHIMG’s Ultimate Guide to NHIs — 2025 Outlook and Predictions.

• Use policy-as-code so authorisation is evaluated at runtime, not fixed at deployment.
• Bind each agent to a unique workload identity instead of a shared service account.
• Issue secrets with tight TTLs and automatic revocation on task completion.
• Log tool calls, secret access, and data retrieval separately for audit and containment.
• Segment agent permissions by task class, not by broad job title or application tier.

This guidance tends to break down in legacy automation environments where shared credentials, brittle integrations, and human handoffs are still the operational default.

Common Variations and Edge Cases

Tighter credential controls often increase integration overhead, so organisations have to balance speed of experimentation against the cost of additional policy checks, token issuance, and revocation plumbing. That tradeoff is real, and current guidance suggests it should be managed deliberately rather than ignored. There is no universal standard for every agent pattern yet, especially in multi-agent workflows where one agent delegates to another and the chain of trust becomes harder to follow.

Some teams assume PAM alone is enough, but PAM generally protects privileged humans better than fast-moving agent tasks. Others rely on RBAC alone, which works poorly when the agent’s next step is unpredictable and depends on live context. In those cases, intent-based controls and real-time policy evaluation matter more than fixed role membership. For threat modeling and control selection, the OWASP Top 10 for Agentic Applications 2026 is useful, while Moltbook AI agent keys breach shows how quickly exposed agent secrets can become a large-scale incident.

Best practice is evolving for model-driven workflows that mix browsing, code execution, and privileged API access. In those environments, the right answer is usually not “never expand agentic AI,” but “do not expand until the identities behind it are short-lived, auditable, and recoverable.”

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• When should organisations use AI to help manage NHIs?
• How can organisations govern AI agents that use service accounts and tokens?
• Should organisations prioritise identity governance before expanding agentic AI?