TL;DR: AI systems can be hijacked when exposed to non-human identity secrets, with attackers attempting access to public AWS credentials in an average of 17 minutes and as quickly as 9 minutes, according to Reco AI. The security problem is not prompt content alone but the trust and privilege context wrapped around it, which makes credential governance central to AI risk reduction.
At a glance
What this is: LLMjacking is Reco AI's term for AI system takeover that begins with exposed non-human identity secrets rather than prompt manipulation alone.
Why it matters: It matters because IAM and PAM teams now have to govern how AI systems inherit, store, and expose secrets, not just how users interact with prompts.
Context
LLMjacking is a governance failure around access, not just a misuse of prompts. When non-human identity secrets are exposed, attackers can inherit the trust that sits behind AI-connected workflows, cloud resources, and automation paths. That makes secret handling, privilege scope, and lifecycle control part of AI risk, not a separate infrastructure concern.
The article frames the problem through AI security and identity governance at the same time. That intersection is where many programmes still have a gap: they monitor model behaviour but do not treat the surrounding credentials, service accounts, and delegated access as the real control surface.
Key questions
Q: What fails when exposed NHI secrets are used to access AI systems?
A: The failure is trust inheritance. Once an attacker gets an exposed non-human identity secret, they can authenticate as the trusted workload or integration and use whatever permissions were attached to that identity. The breach is not the prompt alone, but the access path behind it.
Q: Why are exposed service account credentials so risky in AI workflows?
A: Because service account credentials often sit behind cloud access, data access, and automation rights that AI workflows can invoke without human intervention. If the credential leaks, the attacker gains the same delegated authority the workflow uses, which can quickly turn into tool abuse, data access, or control-plane action.
Q: How do security teams know if AI governance is working?
A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.
Q: Should organisations treat AI prompt security and identity security as separate controls?
A: No. Prompt security limits what the model can generate, but identity security limits what the surrounding system can reach and change. If an AI workflow holds privileged secrets, the practical risk sits in authorisation and credential governance, not in prompt content alone.
Technical breakdown
How exposed NHI secrets enable AI system takeover
Non-human identity secrets include API keys, tokens, service account credentials, and similar authenticators used by software, workloads, or AI-connected services. If those secrets are exposed, an attacker does not need to break the model itself. They can authenticate as the trusted workload or integration and then move through the permissions already attached to that identity. In practice, the AI system becomes reachable through the control plane that supports it, which is why exposure and authorisation must be treated as one problem.
Practical implication: Treat exposed AI-adjacent secrets as direct access paths, not only as leaked credentials.
Why prompt safety does not solve delegated access risk
Prompt filtering and content controls address what a model may say or generate, but they do not govern what the surrounding system can do once authenticated. If an AI workflow can call tools, query data, or trigger actions through delegated privileges, the real risk sits in authorisation scope and secret trust, not the prompt text itself. This is the key distinction between model safety and identity security: one controls outputs, the other controls reachable actions and resources.
Practical implication: Align AI security reviews with authorisation paths, not only prompt and output controls.
How fast exposed credentials become exploitable
Credential exposure is dangerous because attackers automate discovery and testing at machine speed. Once a secret is public or otherwise exposed, it can be found, validated, and used far faster than many teams can rotate or revoke it through manual processes. That timing gap is the operational weakness. Even a short exposure window can be enough when the secret authorises cloud access, automation, or AI tooling with meaningful privileges.
Practical implication: Shorten exposure windows with automated detection, revocation, and rotation for AI-linked identities.
Threat narrative
Attacker objective: The attacker wants to use exposed non-human identity trust to control AI-connected systems and reach the data or actions those systems can perform.
- Entry occurs when attackers discover exposed NHI secrets associated with AI-connected systems or cloud automation.
- Credential access follows when the exposed secret is validated and used to authenticate as the trusted non-human identity.
- Impact occurs when the attacker leverages that inherited trust to hijack AI workflows, access connected resources, or abuse privileged actions.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
LLMjacking is an identity governance problem disguised as an AI problem: the attack succeeds because the system trusts a secret, not because the prompt is unsafe. That shifts the centre of gravity from model moderation to credential governance, delegated authority, and privilege containment. The practitioner conclusion is clear: if the secret is reachable, the AI workflow is reachable.
Exposed NHI secrets create an AI trust collapse: once a token or service credential is public, the attacker inherits the same access path as the workload or integration. That collapses the separation between automation and administration, especially where service accounts have broad cloud or data permissions. Teams should treat every AI-connected secret as a governance boundary, not a convenience artifact.
Privilege scope is the named concept here: the real failure mode is not simply leakage, but leakage of credentials that still carry operational authority. When secret exposure and overprivilege combine, the attacker does not need persistence inside the model layer to cause damage. The practitioner takeaway is to reduce both blast radius and exposure lifetime together.
AI security programmes that ignore identity are monitoring symptoms, not causes: prompt abuse, tool misuse, and malicious output matter, but they are downstream of authentication and authorisation decisions. Reco AI's framing reinforces a broader market reality: AI governance now depends on NHI inventory, ownership, and revocation discipline. The practitioner conclusion is to bring AI access paths under the same control model used for privileged infrastructure.
Operational speed is now part of identity security: exposed secrets can be acted on faster than manual workflows can respond, which makes stale review cycles inadequate. That means detection and revocation need to move closer to issuance time, not audit time. The practitioner conclusion is to design for rapid invalidation of AI-linked credentials.
What this signals
LLMjacking is a reminder that AI governance is now credential governance: if a model, agent, or integration can act only because a secret grants that authority, then the secret lifecycle becomes the real control point. Security teams should expect more attacks that target the access layer around AI rather than the model itself.
Access reviews are too slow for exposed AI-linked secrets: manual certification assumes credentials survive long enough to be reviewed, but attackers act on leaked secrets as soon as they appear. That pushes teams toward continuous inventory, rapid revocation, and tighter privilege scope for any identity that can influence AI workflows.
For practitioners
- Inventory AI-linked non-human identities Identify every service account, token, API key, and certificate that can reach AI workflows, model endpoints, or tool integrations. Assign an owner, map the privilege scope, and flag any identity that can trigger data access or automation.
- Rotate and revoke exposed secrets quickly Use automated detection for leaked credentials in code, logs, and configuration stores, then revoke the affected secret and replace it with a new credential path. Prioritise identities with cloud or data access attached to the AI workflow.
- Reduce privilege on AI-connected service accounts Strip AI integrations down to the minimum actions they actually need, especially for data retrieval, workflow execution, and administrative calls. Separate read-only access from write or control functions so compromise cannot become full system control.
- Monitor AI control planes for abnormal use Watch for new geographies, unusual call patterns, repeated authentication attempts, and rapid tool invocation from identities that normally act quietly. Treat these signals as potential credential abuse rather than model misuse.
- Apply conditional access around sensitive integrations Add approval, network, or environment constraints for the identities that can reach production data or execute high-impact actions through AI systems. Make sure the controls apply to the workload identity, not only to human users.
Key takeaways
- The article shows that AI risk can begin with exposed non-human identity secrets, not with prompt injection or model manipulation alone.
- The critical failure is trust inheritance, where a leaked credential still carries the authority to reach data, tools, or cloud actions.
- Reducing blast radius means governing the full lifecycle of AI-linked secrets, from inventory and ownership through revocation and privilege reduction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed secrets as the entry path into AI-connected systems. |
| NHI-04 — Insecure Authentication | LLMjacking relies on compromised credentials still being accepted as valid trust anchors. | |
| NHI-05 — Overprivileged NHI | The impact depends on how much authority the exposed secret carries. | |
| Recommendation — Scan AI-linked repositories and runtime stores for secret leakage and revoke any exposed credential immediately. Harden authentication for AI-linked identities so leaked credentials cannot be reused without additional checks. Reduce AI-linked service account privilege to the minimum actions needed for the workflow. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern maps to credential use followed by movement through inherited access. |
| Recommendation — Map leaked AI credentials to TA0006 and TA0008 to prioritise detection and containment. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly governs credential lifecycle, including the secrets used by AI-connected identities. |
| Recommendation — Apply IA-5 to govern issuance, rotation, and revocation of AI-linked authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether the right secret carries the right authority. |
| Recommendation — Review AI-connected entitlements under PR.AA-05 and remove excess authorisation from service 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.
- Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Privilege Scope: Privilege scope is the set of actions, data, and tools an identity is allowed to use. For AI agents, scope must be defined around the task and the acceptable blast radius, because broad or persistent privileges can turn a small mistake into a production-level incident.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the systems that actually execute access decisions.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org