AI machine identity attack surface is outpacing IAM controls

At a glance

What this is: This analysis argues that AI machine identities are becoming a distinct and rapidly expanding attack surface, with trust-based attacks against chatbots, assistants, and LLM-powered workflows.

Why it matters: IAM and NHI teams need to govern AI identities as privileged non-human identities because model access, sensitive data reach, and weak enforcement boundaries create new abuse paths.

By the numbers:

• 68% of security professionals indicate that up to 50% of all machine identities across their organizations have access to sensitive data.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read CyberArk's analysis of the AI machine identity attack surface

Context

AI machine identity risk is the problem of software entities, including chatbots, assistants, and LLM-enabled services, being granted access that can be manipulated or abused. The primary issue is not model intelligence alone, but the trust decisions around what the model can read, summarize, act on, and expose inside enterprise systems.

For IAM and NHI practitioners, this matters because AI services are inheriting privileges that were designed for deterministic software, not autonomous or semi-autonomous behaviour. Once an AI identity can touch sensitive data or trigger actions, traditional account review and MFA assumptions stop being sufficient on their own.

Key questions

Q: How should security teams govern AI identities that can access business data?

A: Security teams should treat AI identities as privileged non-human identities and scope them with the same discipline used for service accounts. That means defining an owner, limiting read and action rights, logging every downstream tool call, and revoking access when the use case ends. Broad access without lifecycle controls creates hidden exposure.

Q: Why do AI assistants create more risk than traditional service accounts?

A: AI assistants create more risk because they can be influenced by inputs, context, and hidden instructions after authentication succeeds. A traditional service account usually executes fixed logic, while an AI identity may summarize, retrieve, or act in ways that are harder to predict. That makes access scope and behavioral testing equally important.

Q: What is the difference between prompt injection and credential theft?

A: Credential theft steals a secret so an attacker can impersonate an identity. Prompt injection manipulates the AI identity itself so it follows attacker instructions while still using valid access. The second problem is harder to detect through normal login controls because the compromise occurs through content and model behavior, not stolen credentials.

Q: When should organisations restrict an AI system from taking direct action?

A: Organisations should restrict direct action whenever the AI system can reach sensitive data, external communication channels, or production workflows. If a wrong answer could create a security, legal, or customer impact, require approval or human confirmation. The more autonomy the identity has, the more tightly its entitlements and outputs should be constrained.

Technical breakdown

Why AI machine identities create a different trust model

AI machine identities are not just another service account. They often sit between users, data sources, and downstream applications, which means they can inherit broad access while operating with unpredictable outputs. That matters because security controls built for deterministic systems assume clear input, clear policy enforcement, and clear output. LLM-based systems can instead be influenced by prompt content, context size, and hidden instructions embedded in data sources. The result is a trust model where the identity is legitimate, but the model behaviour can still be steered into unsafe action. Practical implication: classify AI services as privileged non-human identities and review their data reach before deployment.

Practical implication: Classify AI services as privileged non-human identities and review their data reach before deployment.

Indirect prompt injection and why it matters to NHI governance

Indirect prompt injection occurs when malicious instructions are hidden in content the model later reads, such as a document, page, or message. The AI identity then processes that content and may follow the attacker’s embedded instructions even though the attacker never authenticated directly to the model. This is an NHI governance problem because the compromise path is through the machine’s access and processing authority, not through a human login event. It also collapses the boundary between content security and identity security. Practical implication: treat content ingestion pathways as part of the identity control plane and restrict what AI systems can retrieve and summarise.

Practical implication: Treat content ingestion pathways as part of the identity control plane and restrict what AI systems can retrieve and summarise.

Why model-aware security requires continuous testing

Model-aware security focuses on how AI systems behave under adversarial input, not just whether they authenticate. Techniques such as fuzzing and adversarial prompt testing probe for jailbreaks, context drift, and instruction-following failures that normal application testing misses. The technical issue is that the security boundary is partly probabilistic, so controls must validate behaviour repeatedly rather than assume a one-time configuration is enough. This is especially important for systems that can access business data, code repositories, or workflow automation. Practical implication: add adversarial testing to pre-production and recurring control validation for every AI identity with execution authority.

Practical implication: Add adversarial testing to pre-production and recurring control validation for every AI identity with execution authority.

Threat narrative

Attacker objective: The attacker aims to exploit legitimate AI access so the model itself becomes the path to sensitive data exposure or unsafe automated actions.

1. Entry occurs when a threat actor seeds malicious instructions into content that an AI service later ingests or when a user tricks the model through deceptive prompts.
2. Escalation happens when the AI identity follows the injected instructions and uses its legitimate access to read restricted content or manipulate workflow logic.
3. Impact follows when the model exposes sensitive information, produces malicious outputs, or performs unauthorized actions under the cover of trusted automation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI identities are now privileged actors, not auxiliary features. Once an enterprise lets an AI system read, summarize, or act on business data, it has created a non-human identity with meaningful authority. That authority can be abused even when the underlying model is not technically ‘hacked’ in the classic sense. The governance issue is therefore identity scope, not just model quality. Practitioners should manage AI services through the same privilege lens applied to service accounts and automation accounts.

Indirect prompt injection exposes a control gap between content security and identity security. Traditional IAM models assume credentials and user sessions are the primary enforcement point. AI systems break that assumption because the attack often arrives through trusted content rather than login credentials. That means access review alone will miss a large part of the risk. Practitioners should map what the model can ingest, infer, and forward, then limit those pathways by design.

Model-aware testing should become part of the NHI security lifecycle. If an AI identity can be redirected by crafted prompts, the real question is not whether the model is useful but whether its permissions are too broad for its failure modes. Continuous testing, scoped entitlements, and tighter data boundaries are now baseline requirements. The practitioner takeaway is clear: validate AI identities as continuously as you validate any other privileged non-human workload.

Ephemeral trust without behavioral controls creates ephemeral risk debt. Short-lived credentials reduce exposure windows, but they do not solve the fact that an AI identity may still misuse valid access during that window. This is the new trust debt in agentic systems: access can be temporary while consequences remain immediate. Practitioners should pair ephemeral access with policy constraints, content filtering, and action approval thresholds.

AI governance will converge with NHI governance, not sit beside it. The distinction between ‘AI risk’ and ‘machine identity risk’ is already eroding because the same objects are now driving both categories. Security teams that keep these programs separate will duplicate controls and miss interdependencies. Practitioners should fold AI identities into the same governance, review, and offboarding model used for other high-risk NHIs.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That is why the NHI Lifecycle Management Guide matters: lifecycle discipline is the control plane for AI and machine identity sprawl.

What this signals

AI machine identity risk will push governance teams to merge identity and application controls. The practical programme change is that access review, secrets handling, and runtime monitoring can no longer live in separate workstreams. As AI systems gain tool access, the security team must define where identity ends and content-processing risk begins, then enforce that boundary with policy.

Identity blast radius becomes the more useful metric than model capability. A system can be technically accurate and still be unsafe if it can reach the wrong data set or trigger the wrong action. Teams should prioritize limiting the scope of each AI identity, because the business impact of one misuse event now depends on how much authority the model already holds.

With 68% of organisations saying they do not know how to fully address NHI risks, per the Ultimate Guide to NHIs, AI governance programmes cannot assume mature identity process coverage. The path forward is to bring AI assistants, LLM tools, and automation services into the same review cadence used for other high-risk NHIs. That gives security teams a manageable operating model before agentic use cases scale further.

For practitioners

• Inventory AI identities and their entitlements Identify every AI assistant, chatbot, model-backed workflow, and automation service with access to sensitive systems. Document read, write, and action permissions, then tie each identity to a named owner and business purpose.
• Restrict content ingestion pathways Limit which repositories, pages, tickets, and messages an AI identity can ingest or summarize. Segment sensitive sources and prevent unrestricted retrieval across departments or data classes.
• Apply least privilege to model actions Separate summarization, retrieval, and execution rights so one AI identity cannot both discover data and take downstream action. Use approval gates for high-impact steps such as external messaging or record changes.
• Add adversarial prompt testing to release gates Test for jailbreaks, prompt injection, context drift, and unsafe tool use before production rollout and after major prompt or model changes. Treat failed tests as control failures, not edge cases.
• Connect AI governance to NHI lifecycle controls Require provisioning, rotation, review, and offboarding for AI identities just as for other high-risk non-human accounts. Use the NHI Lifecycle Management Guide to anchor ownership and expiry discipline.

Key takeaways

• AI machine identities create a separate attack surface because they can be steered through content, context, and tool use, not just credentials.
• The scale of NHI exposure is already material, with privileged access and low visibility combining to widen the blast radius of AI-enabled systems.
• Practitioners should govern AI identities through lifecycle controls, least privilege, and adversarial testing before autonomy expands further.

Key terms

• AI Machine Identity: An AI machine identity is the non-human account, credential set, or service identity used by an AI system to access tools and data. It can include tokens, service accounts, and delegated permissions. In practice, it should be governed like any other privileged NHI with clear ownership and expiry.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system later reads and obeys. The attacker does not need direct access to the model’s prompt input. The risk is that trusted data becomes the delivery mechanism for untrusted instructions.
• Model-Aware Security: Model-aware security is the practice of testing and controlling AI systems based on how they behave under adversarial or unexpected inputs. It goes beyond standard application security by focusing on prompt manipulation, context drift, and tool misuse. The goal is to reduce unsafe model behaviour before it reaches production.

Deepen your knowledge

AI machine identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI assistants and model-backed workflows, it is worth exploring.

This post draws on content published by CyberArk: The Rise of the Machines and the Growing AI Identity Attack Surface. Read the original.