The risk that an AI agent or skill is safe when first approved but becomes dangerous later through updates, dependency changes or malicious repackaging. It is a governance problem because the original trust decision no longer matches the agent’s current behaviour.
What Sleeper Agent Risk Means
Sleeper agent risk describes a trust gap: an AI agent, skill, or toolchain can look safe at approval time, then later behave differently because it has been updated, repackaged, or altered through dependency changes.
The governance challenge is that a one-time review cannot stay valid forever. A seemingly benign capability can accumulate new permissions, new code paths, or new external dependencies after it has already been trusted and embedded into workflows.
Why Sleeper Agent Risk Matters
This risk is dangerous because the original approval decision becomes stale. A later version may introduce broader access, hidden data flows, or instructions that change how the agent uses tools, handles content, or interacts with systems.
For organisations, the issue is not only whether the agent was safe when first evaluated, but whether the current deployed version still matches the scope, purpose, and controls that justified approval. That makes version drift and repackaging a governance problem, not just a software maintenance issue.
How Sleeper Agent Risk Emerges
Sleeper behaviour can arise through ordinary software updates, dependency substitutions, poisoned package changes, or malicious repackaging that preserves the original name while altering runtime behaviour. The most difficult cases are those that keep the same outward label while changing the internal trust profile.
Because agentic systems often combine prompts, tools, memory, plugins, and external services, a change in any one layer can create a new effective behaviour even when the agent name or interface appears unchanged. That makes provenance, change control, and supply-chain scrutiny part of the security model.
How Organisations Reduce Exposure
Exposure checks should start with inventory: which agents and skills are approved, where they are deployed, which dependencies they load, and who owns them. Organisations should also compare the approved version against what is actually running, especially when agents are sourced from external marketplaces or frequently updated repositories.
Control should focus on revalidation after updates, dependency review, and scoped permissions that limit what a changed agent can reach. A useful reference point for this kind of evaluation is Threat Modelling AI Agents, which helps teams reason about trust boundaries and attack paths before they approve runtime access.
Teams responsible for agent governance should also understand how trust, delegation, and approval conditions evolve over time, which is why Agentic AI Identity Guide is useful when an agent’s authority depends on its current identity and delegation model. When the main concern is choosing and comparing controls, AI Agent Authorisation Guide is a practical companion for limiting the blast radius of changed behaviour.
Risk and Threat Considerations
Sleeper agent risk creates a delayed compromise pattern: a trusted agent can remain benign long enough to pass review, then become harmful after a benign-looking update or dependency shift. That makes the threat especially hard to catch with one-time approvals and static trust assumptions.
Failure mechanism: A trusted agent or skill is altered after approval, either through legitimate updates that change behaviour or through malicious repackaging that preserves the original trust wrapper while changing what the code, prompts, or dependencies actually do.
Impact: The organisation continues to grant access and operational trust to something that no longer matches the approved security posture, increasing the chance of misuse, data exposure, tool abuse, or broader compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Sleeper agent risk centers on changed behaviour through updates or repackaging. |
| ASI03 — Identity & Privilege Abuse | A changed agent can inherit or abuse the authority it was originally granted. | |
| Recommendation — Verify agent supply chain integrity and re-evaluate trust after every dependency or package change. Constrain agent authority so updated behaviour cannot use excess privilege without reapproval. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party agent components can become unsafe after upstream changes or tampering. |
| NHI-09 — NHI Reuse | A trusted agent identity or package may be reused after its risk profile has changed. | |
| Recommendation — Revalidate third-party agent components and block unreviewed version drift. Treat reused agent identities and packages as new trust decisions when behaviour changes. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Inventory is needed to know which agents and skills are approved and where they run. |
| CIS-16 — Application Software Security | Changed agent software must be reviewed as part of software security and change control. | |
| Recommendation — Maintain an authoritative inventory of approved agents, skills, and their deployed versions. Apply secure change control and revalidation to agent updates and repackaged software. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Malicious repackaging and dependency changes are classic supply-chain compromise paths. |
| Recommendation — Map altered agent behaviour to supply-chain compromise and hunt for tampering indicators. | ||
Practitioner Guidance
Why practitioners should care: Approval should be treated as conditional on version, provenance, and dependency state, not just on the original vendor or package name. If those change, the trust decision should be re-opened.
What to watch for: New dependencies, silent repackaging, expanded tool permissions, and behaviour changes after routine updates are all signals that the agent may no longer be the same security object that was originally reviewed.
Practitioner takeaway: The safest posture is to govern AI agents as mutable software with a living trust profile, not as fixed assets whose approval remains valid indefinitely.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org