AI credentials are now a primary attacker target, not a byproduct

At a glance

What this is: Anthropic’s September 2026 threat report says attackers are now stealing AI API keys on purpose and bypassing single-session safeguards by splitting work across smaller sessions.

Why it matters: This matters because IAM, PAM, and SOC teams must treat AI credentials, tokens, and session boundaries as governable access assets, not just model-adjacent noise.

By the numbers:

• The report runs 154 pages and documents activity disrupted between December 2025 and August 2026 across seven harm areas.

👉 Read D3’s analysis of attackers stealing AI API keys and fragmenting abuse across sessions

Context

AI credential abuse is becoming a direct security problem, not a side effect of model adoption. When API keys, session tokens, and agent credentials are stolen, attackers can reuse legitimate access paths to hide activity, consume compute, and extend campaigns without triggering obvious perimeter alarms. For identity teams, the issue is less about the model itself and more about who can act through it, when, and under what control.

The report’s central point is that fragmented AI tasks weaken controls that look effective when evaluated per session. That creates a governance gap across IAM, PAM, and SOC workflows because the unit of review shifts from a single request to a campaign spread over many smaller ones. For teams managing NHI estates, this is a familiar pattern: the credential is legitimate, but the abuse is in how it is used.

Key questions

Q: What breaks when AI agent access is reviewed only after the fact?

A: After-the-fact review leaves a gap between action and containment. If an agent can already reach a dataset, API, or SaaS system, the damage may be done before a human sees the alert. Runtime checks reduce that gap by stopping unauthorized actions before they execute.

Q: Why do stolen AI API keys create the same risk pattern as NHI compromise?

A: Because the key becomes a reusable identity with delegated authority, not just a technical secret. If an attacker can run workloads, consume compute, or act under the victim’s access path, the credential has operational value and governance impact. That is why AI keys belong in the NHI lifecycle, with ownership, inventory, and revocation.

Q: How can security teams detect AI credential abuse before it becomes a campaign?

A: Look for abnormal model usage, sudden changes in call volume, repeated access from unfamiliar contexts, and activity that crosses normal session boundaries. Combine those signals with token inventory and ownership data so the investigation can move from a single alert to a credential-level view of likely abuse.

Q: Should organisations prioritise AI credential governance or prompt safety first?

A: Credential governance should come first when access keys, tokens, or embedded secrets are already exposed. Prompt safety matters, but it cannot compensate for stolen credentials that let attackers operate through legitimate channels. Once access is governed, prompt controls and abuse detection become much more effective.

Technical breakdown

AI API keys as operational access, not just secrets

AI API keys and session tokens function like machine credentials. They authorise model calls, consume metered resources, and often sit in applications, containers, mobile builds, or public code where they can be copied and reused without direct compromise of the model vendor. Once stolen, the key gives an attacker legitimate-looking access that can be sold, used for compute, or blended into normal traffic. In identity terms, the problem is not only secret exposure. It is unmanaged authorization scope and weak lifecycle control over credentials that now have business and security impact.

Practical implication: Treat AI keys as governed NHI credentials with inventory, scoping, and revocation controls.

Why fragmented sessions evade single-request safeguards

A request-level refusal model works when malicious intent is obvious in one prompt or one transaction. It performs less reliably when the attacker breaks the objective into smaller, apparently benign steps across later sessions. That matters because many AI systems, agents, and analyst workflows review prompts in isolation, while the attacker’s true objective only emerges when the steps are combined. This is a campaign problem, not a prompt problem. The control gap is the absence of session continuity, correlation, and campaign-level detection across a series of actions that each look low risk on their own.

Practical implication: Correlate AI activity across sessions so abuse is judged as a chain, not a single prompt.

AI supply chain abuse and credential reuse

The report shows attackers treating the AI supply chain as both target and resource. That includes stealing customer-held keys, routing workloads through compromised credentials, and using legitimate access to continue attacking other targets. This is similar to living off the land in conventional security, except the tools are AI services and the value being stolen is compute plus trust. The security issue is delegated authority without strong provenance, monitoring, or channel control. When access is bought, borrowed, or embedded through indirect paths, governance weakens fast.

Practical implication: Monitor where AI access originates and restrict credential use to approved procurement and runtime paths.

Threat narrative

Attacker objective: The attacker wants durable, legitimate-looking access to AI services that can be monetised, operationalised, and used to conceal follow-on activity.

1. Entry occurs when attackers obtain exposed or reused AI credentials from customer environments, applications, repositories, or bulk scanning of public assets.
2. Escalation follows when those credentials are used to run workloads under the victim’s identity, hiding activity while consuming compute and extending access.
3. Impact lands as sustained campaign execution, credential resale, and broader abuse of AI infrastructure against the victim and third parties.

NHI Mgmt Group analysis

AI credentials have become a first-class identity governance problem: when a model key can be stolen, resold, and reused for covert compute, it behaves like an NHI with operational blast radius. The governance question is no longer whether the model is trusted, but whether the credential lifecycle is bounded, inventoried, and revocable across all environments where it lives. Practitioners should treat AI access as part of the NHI estate, not a separate engineering concern.

Session-level refusal is not a sufficient security boundary for AI abuse: the report shows that attackers can fragment malicious intent across smaller tasks until the abuse no longer looks malicious in any single interaction. That undermines review models built around one prompt, one decision, or one alert. The control gap is campaign correlation, which means SOC and AI governance teams need shared visibility into sequences, not isolated events.

AI supply chain abuse exposes a delegated trust gap: the attacker does not need to break the model if they can inherit access through customer keys, embedded tokens, or third-party workflows. That is the same structural problem NHI programmes face when offboarding, provenance, and scope are weak. Delegated access drift: once access is passed through indirect channels, ownership and control diverge. Practitioners should map every AI credential to a business owner and a revocation path.

The economics of attack automation have changed faster than defender workflows: the report shows a small number of operators driving parallel activity at scale, which pushes SOCs toward machine-speed triage and stronger identity controls around AI systems. This does not remove human oversight. It makes oversight dependent on better context, tighter access scope, and faster detection of abnormal credential use. Teams should align AI monitoring with existing identity and PAM governance rather than bolting it on separately.

What this signals

AI credential governance is now a SOC and IAM joint problem: the attack path no longer stops at secret exposure, because stolen keys can be used as live operational access. Teams should expect AI abuse to look more like identity compromise than traditional malware, which means monitoring, revocation, and ownership data need to travel together. See also MITRE ATT&CK Enterprise Matrix for attack-chain mapping and NIST SP 800-53 Rev 5 Security and Privacy Controls for access control and audit alignment.

Fragmented AI workflows create a detection gap that will widen if programmes stay prompt-centric: the report suggests the real unit of abuse is the campaign, not the query. That pushes practitioners toward correlation across identities, credentials, and runtime behaviour, especially where AI agents inherit permissions from surrounding systems. Campaign-aware control plane: a governance layer that evaluates sequences of actions, not isolated interactions, is becoming necessary.

If your environment already uses AI services inside applications or agent workflows, the next control question is whether those credentials can be discovered, scoped, and revoked as fast as they are created. Without that, the organisation is relying on the assumption that no attacker will intentionally mine its own AI access paths. That assumption is already broken.

For practitioners

• Inventory every AI credential and token Catalogue API keys, session tokens, and embedded secrets across applications, containers, mobile builds, and code repositories. Tie each credential to an owner, an approved use case, and a revocation path.
• Correlate AI activity across sessions Feed model calls, agent actions, and token use into monitoring that can detect multi-step campaigns rather than single suspicious prompts. Review activity by actor, workload, and time window, not just by request.
• Restrict AI access to approved channels Block unofficial resale or shadow procurement of AI services and require authorised purchase paths for external model access. Treat unauthorised access channels as a governance defect, not a procurement detail.
• Add egress monitoring on model endpoints Alert on unusual volume, destination changes, or repeated calls that indicate stolen credentials are being used to run attacker workloads. Use those signals to trigger credential revocation and scope review.
• Align AI credentials with NHI controls Apply the same lifecycle discipline used for service accounts and tokens to AI keys, including rotation, revocation, and least-privilege scoping. Where possible, reduce standing access and shorten credential lifetime.

Key takeaways

• AI API keys are now active attack assets, and once stolen they can be monetised, hidden, and reused like any other privileged credential.
• Fragmenting malicious work across smaller sessions weakens controls that only evaluate one request at a time, creating a campaign-level blind spot.
• The practical response is identity-led: inventory AI access, correlate activity across sessions, and make revocation fast enough to matter.

Key terms

• AI Credential: A credential used by an AI service, model, or pipeline to access data, tools, or billing systems. In practice, it functions like a privileged machine secret and should be governed with ownership, scope, rotation, and revocation controls rather than treated as ordinary configuration.
• Campaign-Level Detection: A detection approach that correlates actions across multiple sessions, prompts, and identities rather than judging each event in isolation. It is essential when attackers fragment malicious intent so that no single interaction looks obviously harmful.
• Delegated access drift: The point at which a valid token or OAuth grant begins being used in ways that no longer match the original user intent. In practice, this shows up as mailbox reconnaissance, inbox-rule changes, or data access that follows the sign-in event but does not fit normal user behaviour.
• AI supply chain: The AI supply chain is the full chain of models, datasets, prompts, tools, and vendors that influence a deployed AI system. It matters because trust cannot be assigned to the application alone. Practitioners need provenance, ownership, and dependency visibility to govern risk.

What's in the full article

D3's full analysis covers the operational detail this post intentionally leaves for the source:

• The full breakdown of AI credential abuse patterns, including where keys were found and how they were reused
• Operator-level examples of AI supply chain misuse and the access paths attackers inherited
• Detailed discussion of how fragmented AI tasks bypass single-session safeguards
• The report's broader seven-area threat intelligence coverage beyond the AI credentialing angle

👉 D3’s full post covers the AI supply chain, the sandbox compromise examples, and the SOC implications in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps practitioners connect identity controls to the access paths that modern AI and automation now depend on.