LLMjacking shows how compromised NHIs can hijack AI systems

At a glance

What this is: This is an API security and AI security analysis of LLMjacking, with the key finding that compromised NHIs can be used to gain unauthorized access to AI services and related cloud assets.

Why it matters: It matters because IAM and PAM teams increasingly have to govern machine credentials, service access, and AI-connected workflows as one attack surface rather than separate control domains.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read LEVO's analysis of LLMjacking and compromised NHI abuse

Context

LLMjacking is the abuse of leaked or compromised machine credentials to reach AI systems, cloud services, or supporting data flows. In practical terms, it turns secret exposure into a live access problem, because the attacker does not need to defeat the model, only the identities and tokens that control access around it.

For IAM, PAM, and NHI teams, the important issue is that AI services are now part of the credential estate. The same controls that limit standing privilege, scope secrets, and revoke exposed tokens are increasingly determining whether an AI workflow becomes a security asset or an attack path.

Key questions

Q: How should security teams govern API keys used for generative AI access?

A: Treat them as machine identities with lifecycle controls, not as disposable developer conveniences. Each key should have an owner, a specific purpose, an expiry date, and a revocation path. Security teams should also scan repositories, CI/CD pipelines, logs, and collaboration tools so leaked keys are discovered before they become standing access.

Q: Why do compromised non-human identities create such a fast risk window?

A: Because machine credentials are designed for automated use, attackers can exploit them as soon as they are found. A valid token or API key often bypasses interactive checks and gives direct access to services, so the main control is how quickly the secret can be rotated or revoked after exposure.

Q: What signs show that AI-connected credentials are being abused?

A: Look for unusual request sources, unexpected API call volume, connector activity outside normal schedules, and access to data sets the identity does not usually touch. Those signals matter because legitimate AI traffic can look automated, so anomaly detection must focus on source, scope, and timing rather than simple login failure counts.

Q: Should organisations treat MCP connectors like ordinary integrations?

A: No. MCP connectors often carry delegated access into multiple tools and data stores, which makes them part of the identity control plane. They should be registered, scoped, monitored, and offboarded like any other privileged machine identity, otherwise a compromise in one connector can expand into broader system access.

Technical breakdown

How compromised NHIs become AI access paths

AI services are commonly reached through API keys, service accounts, OAuth tokens, and cloud credentials rather than interactive human login. If those non-human identities are exposed, attackers can call the AI service, retrieve data, or pivot into adjacent cloud resources without ever touching a user account. The important mechanism is not model compromise, but identity compromise at the control plane that surrounds the model. That makes secret lifetime, scope, and revocation speed the real security variables. Once a token is valid, the attacker can often operate like a legitimate automation workflow.

Practical implication: Map every AI integration to a governed NHI identity and remove any credential that can reach the service without clear scope or expiry.

Why runtime abuse is harder to spot than secret theft

Secret theft and secret use are different phases. A leaked credential may sit dormant in code, logs, or a config file until an attacker or automated scanner finds it, then be used quickly to generate requests that look legitimate. In AI environments, that abuse may blend into normal service traffic because the calls are automated and high-volume by design. This is why detection limited to repository scanning is incomplete. Runtime visibility needs to cover unusual source IPs, unusual request cadence, abnormal model invocation patterns, and unexpected data retrieval from connected systems.

Practical implication: Correlate secret discovery with runtime telemetry so exposed credentials can be revoked before the first successful AI API call.

How MCP and AI-connected tooling widen the credential surface

Model Context Protocol, or MCP, connects AI agents to tools and data sources. That makes it a useful integration pattern, but also a concentrated trust boundary because each connector may rely on its own tokens, secrets, or delegated permissions. The risk is credential multiplication, where a single AI workflow depends on several machine identities across repositories, databases, ticketing systems, and cloud services. If those identities are not lifecycle-managed, a compromise in one layer can cascade into broader access. This is a classic NHI governance problem expressed through AI architecture.

Practical implication: Inventory MCP connectors and the machine identities behind them, then enforce per-connector least privilege and fast revocation.

Threat narrative

Attacker objective: The attacker wants to turn exposed non-human credentials into unauthorized AI access, data retrieval, and broader cloud compromise.

1. Entry occurs when attackers harvest exposed API keys, cloud credentials, or tokens from public code, logs, leaked files, or exposed databases.
2. Escalation follows when the compromised NHI is trusted to reach AI services or adjacent cloud resources, allowing the attacker to submit legitimate-looking requests and expand access.
3. Impact is achieved through unauthorized model use, data exposure, or downstream cloud abuse that converts identity compromise into operational and information loss.

NHI Mgmt Group analysis

Compromised NHI credentials are becoming the primary control plane for AI abuse. The attacker does not need to break the model if the service account, API key, or delegated token already grants access to it. That changes the centre of gravity for AI security from content safety to identity governance. IAM and PAM teams need to treat AI workloads as credential-bearing systems with full lifecycle control, not as isolated applications.

LLMjacking is really a secret-lifecycle failure, not just an exposure event. The source problem is that many organisations still detect leakage after the secret has already become operationally useful. A leaked token with standing validity creates a time window that attackers can exploit quickly, especially when secrets are copied across code, configs, and runtime connectors. The governance assumption that discovery alone is enough has clearly failed, and fast revocation is now part of the control requirement.

Model Context Protocol expands the NHI problem into a delegated access graph. Each connector can represent another identity, another secret, and another trust decision, which makes AI toolchains harder to govern than a single SaaS integration. This is where the identity bridge becomes operationally important: if the connector identities are not scoped and rotated, AI orchestration becomes a route to lateral movement rather than productivity. Practitioners should manage MCP as identity infrastructure, not just integration plumbing.

AI-related credential exposure is now a category-level risk, not an edge case. The pace of exposed keys and secrets tied to AI services shows that guardrails are lagging adoption. That reinforces the need to align AI governance with OWASP-NHI, NIST-CSF, and lifecycle-based access controls, because the primary failure mode is still trust in persistent machine access. Practitioners should expect secret sprawl to increase before it decreases.

What this signals

AI security teams should expect the credential estate around models, agents, and connectors to grow faster than manual review can keep pace. The practical response is to make secret revocation, runtime telemetry, and connector inventory part of the same control loop instead of separate workstreams.

Credential blast radius: the decisive question is no longer whether a secret leaked, but how far a leaked secret can reach before it is disabled. That makes lifecycle controls, scope minimisation, and offboarding discipline the relevant programme signals, especially where AI workflows span multiple systems.

For practitioners

• Inventory every AI-connected NHI Build a complete register of API keys, service accounts, tokens, certificates, and delegated identities used by AI tools, including MCP connectors and hidden integrations. Classify each by scope, owner, rotation method, and revocation path.
• Shorten credential exposure windows Rotate exposed or long-lived credentials immediately, and replace persistent access with short-lived tokens wherever the workflow supports it. The goal is to reduce the usefulness of any secret that escapes into code, logs, or configuration.
• Correlate secret discovery with runtime use Tie secret-scanning alerts to request telemetry so a newly exposed credential can be disabled before an attacker successfully calls the AI service. Watch for unusual source locations, request bursts, and connector activity outside normal job patterns.
• Govern MCP connectors as privileged integrations Treat each MCP connector as a distinct trust boundary with its own identity, least-privilege scope, and lifecycle controls. Review which connectors can reach sensitive systems and remove any default or inherited permissions that are broader than necessary.

Key takeaways

• LLMjacking shows that AI abuse often starts with compromised machine credentials, not model-level exploitation.
• The attack window can be measured in minutes, which means detection without rapid revocation is not enough.
• AI connectors, service accounts, and API keys need the same lifecycle governance that IAM teams already apply to other high-risk non-human identities.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• LLMjacking: Abuse of cloud AI services through stolen machine credentials rather than human user accounts. The attacker uses valid non-human identities such as API keys or tokens to enumerate model access, invoke endpoints, and create cost, data, or policy exposure under the victim's tenancy.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

LEVO's full article covers the operational detail this post intentionally leaves for the source:

• The source breaks down specific LLMjacking abuse paths and how compromised credentials are used against AI workloads.
• It includes the experimental or observed timing data behind public credential abuse, which is useful for response planning.
• It expands on the AI-related secret exposure patterns that create the attack surface in the first place.
• It gives the underlying context for how AI services, cloud credentials, and exposed secrets intersect in real environments.

👉 LEVO's full article covers the attack pattern, timing evidence, and AI credential exposure context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to real operational risk across modern programmes.