How should security teams secure machine and AI identities as the attack surface grows?

Why This Matters for Security Teams

Machine and AI identities now sit on the same critical path as user identities, but they often outnumber them and move faster. Each service account, API key, workload token, agent credential, and model connector can become a control point for lateral movement or data exposure. Current guidance suggests treating these identities as governed assets rather than implementation details, because attackers increasingly target the identity layer instead of the perimeter.

That shift is visible in the research. NHIMG’s 52 NHI Breaches Analysis shows how compromise patterns cluster around exposed secrets, weak ownership, and privilege that outlives its purpose. For AI-specific risk, the AI Agents: The New Attack Surface report shows why the problem grows quickly as deployment scales. External threat research from the CISA cyber threat advisories and the MITRE ATT&CK Enterprise Matrix reinforces the same point: once credentials are reused or overbroad, attackers do not need to break the model, only the identity behind it. In practice, many security teams discover this only after an agent or workload has already been used to access data it was never meant to reach.

How It Works in Practice

Securing these identities starts with a complete inventory, but inventory alone is not enough. Teams need to know what each identity is for, who owns it, what it can reach, and whether it is still required. That includes service principals, CI/CD bots, cloud workload identities, embedded API keys, model-to-tool connectors, and autonomous agents. The objective is to replace implied trust with explicit policy, especially where systems can act without human approval.

For machine identities, best practice is to minimize standing privilege, rotate secrets automatically, and prefer short-lived credentials over durable keys. For AI agents, the bar is higher because access often changes by task. That is why workload identity and runtime authorization matter: the agent should prove what it is using cryptographic identity, then receive only the access needed for the current action. Standards and implementation patterns such as SPIFFE, OIDC, and policy-as-code help security teams make decisions at request time instead of relying on stale roles.

• Assign an owner to every non-human identity and require a business or technical purpose.
• Use just-in-time credentials with short TTLs, then revoke them on task completion.
• Separate human admin access from machine and agent access paths.
• Evaluate authorization at runtime, not only during provisioning.
• Log token issuance, tool use, and downstream data access for auditability.

This aligns with the direction of OWASP NHI Top 10 and the Anthropic report on AI-orchestrated cyber espionage, which both underline how quickly tool access can be chained once an identity is compromised. These controls tend to break down in legacy environments where long-lived service accounts are embedded in code, shared across teams, or tied to applications that cannot yet support short-lived token exchange.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance automation against compatibility with older systems. That tradeoff is real, especially when agents and workloads must interact with mainframes, legacy SaaS integrations, or batch jobs that were never designed for ephemeral credentials. Best practice is evolving here, and there is no universal standard for every environment yet.

For high-frequency workloads, teams may need a layered model: short-lived credentials for runtime use, bounded scopes for tool access, and compensating controls where true JIT is not possible. For AI agents, the key edge case is the gap between what the agent can do and what the policy assumes it will do. The agent may chain tools, retry tasks, or pivot into adjacent systems, so static RBAC alone is usually insufficient. That is why real-time policy evaluation and context-aware authorisation are becoming the practical default, not a future aspiration.

Edge cases also appear in shared platforms, where multiple agents use the same backend services, and in regulated environments where data locality or approval workflows slow down credential issuance. In those cases, teams should document exceptions, enforce compensating monitoring, and revisit privilege scope frequently. The Top 10 NHI Issues and JetBrains GitHub plugin token exposure show how quickly hidden secrets and unattended identities turn into enterprise-wide exposure when governance lags behind deployment.

Related resources from NHI Mgmt Group

• How should security teams manage machine identities before they create audit and breach risk?
• What breaks when identity teams do not maintain continuous visibility into machine and AI identities?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?