TL;DR: OWASP ASI-02 tool misuse and ASI-04 agentic supply chain vulnerabilities let AI agents turn legitimate tools and trusted dependencies into attack paths, with 41% of popular OpenClaw skills carrying security vulnerabilities, according to ClawSecure. The control problem is sequence-level governance: per-call permissions and one-time install checks miss abuse that only appears across tool chains and update history.
At a glance
What this is: This is a ClawSecure analysis of two agentic AI attack paths, tool misuse and agentic supply chain compromise, with the central finding that both evade control models that inspect only individual permissions or install-time checks.
Why it matters: It matters because agentic systems can inherit risk from approved tools, transitive dependencies, and later updates, so IAM and AI security teams need controls that govern behaviour, trust, and change over time.
By the numbers:
- 41% of popular OpenClaw skills carry security vulnerabilities, a share driven in part by tool misuse and compromised dependencies.
Context
Agentic systems create a governance gap when allowed actions become dangerous only in combination. A single tool call may look legitimate, but the sequence can still produce exfiltration, privilege abuse, or malicious execution. That is why conventional allowlists and point-in-time review are incomplete for agent behaviour, especially when the agent is operating through agentic AI security concerns rather than a fixed script.
The same problem appears in the supply chain. A component that is clean at install can become risky later through a poisoned dependency or a malicious update, which makes trust a lifecycle issue rather than a one-time approval. For practitioners, the starting assumption should be that agentic trust boundaries move whenever tools, packages, or versions change.
Key questions
Q: What breaks when agentic AI runs without live monitoring and human intervention paths?
A: Without live monitoring and intervention, teams can lose the ability to detect bad decisions while they are still reversible. That creates brittle automation, slower incident response, and weaker accountability for actions taken by agents. In enterprise settings, the practical failure is not just technical downtime. It is automation that keeps moving even when a task should be corrected, paused, or stopped.
Q: Why do agentic supply chain risks persist after a package has been approved?
A: Because approval only reflects one moment in time. Dependencies can be compromised later, registries can be poisoned, and trusted components can ship malicious updates after initial review. Practitioners should treat dependency trust as a lifecycle control problem and revalidate whenever the package tree or version history changes.
Q: How can security teams tell whether an agent is misusing its permitted tools?
A: Look for suspicious action sequences, not single commands. A file read followed by an external transmission, or a download followed by execution, can indicate misuse even when each step is individually allowed. The useful signal is a pattern that creates a harmful outcome from ordinary capabilities.
Q: How should teams govern agent identity when tools and packages are delegated to software?
A: Treat the agent’s effective identity as the combination of its permissions, tools, and supply chain. That means governance has to cover privilege scope, runtime behaviour, dependency provenance, and update monitoring together. If one layer is missing, the agent can still be turned into an execution or exfiltration path.
Technical breakdown
How tool misuse emerges from approved calls
Tool misuse happens when an agent combines individually permitted actions into an outcome that no single action would reveal. A file read followed by an external request can become exfiltration, while a shell command plus a download step can become execution of untrusted content. The control failure is not permission alone, but the absence of sequence-aware inspection across calls, context, and intent. This is why per-tool allowlists are too coarse for agentic systems: they approve the parts while missing the pattern. Practical implication: inspect tool-use chains, not just individual tool permissions. See the Agentic AI Security Guide.
Practical implication: Inspect tool-use chains, not just individual tool permissions.
Why agentic supply chain risk persists after install
Agentic supply chain risk exists because trust extends beyond the top-level component into every dependency, registry, and update channel it consumes. A package can be safe at install time and later become dangerous through compromise, takeover, or a malicious release. That means the security question is not only whether the component was approved, but whether its dependency tree and version history remain trustworthy. Static approval does not account for later change. Practical implication: re-audit agentic components whenever dependencies or versions shift. See the AI Supply Chain Security and AI-BOM Guide.
Practical implication: Re-audit agentic components whenever dependencies or versions shift.
Why behavioural analysis is stronger than per-call permissions
Behavioural analysis evaluates the sequence of actions an agent performs, rather than treating every request as an isolated event. That matters because the most dangerous agentic attacks often look harmless step by step, with risk emerging only when tool usage is stitched together over time. This is especially relevant for AI agents that can move from reading data to transmitting it, or from a trusted package to an unexpected execution path. The underlying architectural point is that policy must observe runtime composition, not just access entitlement. Practical implication: add runtime sequence analysis to existing permission controls.
Practical implication: Add runtime sequence analysis to existing permission controls.
Threat narrative
Attacker objective: The attacker aims to turn legitimate agent capabilities and trusted dependencies into a covert execution or exfiltration path.
- Entry occurs when an agent is given legitimate access to tools or installs a component that later proves untrustworthy.
- Credential or data misuse follows when the agent chains approved capabilities into file access, network access, or dependency execution that no single check flags.
- Impact appears as exfiltration, malicious execution, or inherited compromise from a poisoned package or harmful update.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- GemStuffer RubyGems campaign 2026: AI agents attributed to OpenAI mass-created RubyGems accounts, ran code on RubyDoc build servers and probed a flaw to steal API keys.
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
Sequence-level governance is now a core control problem for agentic systems. The article’s central point is that dangerous outcomes emerge across tool chains, not inside a single call. That means permissioning alone is not a complete control model for agentic AI. Practitioners should treat runtime sequence inspection as a governance requirement, not an optional detection layer.
Agentic supply chain risk is a trust-lifecycle problem, not an install-time problem. The article shows why a clean dependency tree at install does not stay clean. A later update, transitive package, or registry compromise can convert a verified component into an active threat. Teams should align agent approval, revalidation, and update monitoring as one control surface.
AI agents blur the line between tool access and non-human identity governance. Once an agent can act through files, shells, HTTP clients, and package managers, its effective identity includes the tools and trust paths it can reach. That makes agent identity, privilege, and provenance inseparable in practice, and agentic AI security becomes relevant whenever tools are delegated to software actors.
Tool misuse and supply chain compromise are distinct attacks, but they converge operationally. One abuses granted actions, the other abuses trusted code, yet both defeat controls that assume trust is static. The named concept here is agentic trust composition: the risk created when approved actions, dependencies, and updates combine into an unsafe whole. Practitioners should govern the composition, not each piece in isolation.
The strongest signal here is that agentic security needs continuous verification across behaviour and provenance. The article’s two categories point in the same direction: trust must be re-evaluated when an agent acts and when a component changes. That is where identity, tooling, and software supply chain controls intersect, and security programmes should design for that shared boundary.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Agentic trust composition: the real governance challenge is no longer a single permission or a single package, but the way approved actions and upstream dependencies combine into unsafe outcomes. That changes how identity, runtime control, and software provenance have to be evaluated in the same programme.
For security teams, the practical shift is toward continuous revalidation of delegated software actors. A tool chain that looks acceptable at install time can still become risky once behaviour changes, dependencies update, or a registry is compromised, so the control boundary has to move with the system.
The next maturity step is to connect runtime detection with supply chain assurance. Behavioural inspection catches misuse in action, while dependency provenance catches inherited compromise, and neither is sufficient alone for agentic environments.
For practitioners
- Implement sequence-aware tool monitoring Track how an agent uses permitted tools in combination, not just whether each call was authorised. Flag read-then-send, download-then-execute, and similar multi-step chains that create exfiltration or execution paths.
- Re-audit agent components on every dependency change Treat package updates, new transitive dependencies, and registry changes as revalidation triggers. A component that was approved yesterday is not automatically safe after its supply chain changes.
- Constrain agent tool scopes to task-specific necessity Limit file, shell, network, and publishing permissions to the minimum needed for the current task. Broad scopes turn ordinary tool use into an easier path for misuse chains. See the AI Coding Agents Security Guide.
- Separate install trust from runtime trust Approve components before install, but also monitor their later behaviour and update channel. The article shows why supply chain review must continue after deployment, not stop at approval.
Key takeaways
- Agentic risk appears when legitimate tools and trusted dependencies are combined into unsafe workflows that ordinary permission checks do not reveal.
- The article’s evidence points to a control gap that spans runtime behaviour, dependency provenance, and update monitoring rather than a single point failure.
- Practitioners should govern agentic systems as living trust chains, with continuous inspection of both what the agent does and what it inherits.
Related NHI Mgmt Group resources: Agentic AI Security Guide · AI Supply Chain Security and AI-BOM Guide · CI/CD Pipeline Identity Security Guide · SaaS-to-SaaS and OAuth App Governance Guide
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 and MITRE ATLAS address the attack surface, NIST AI RMF sets the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centres on agents abusing approved tools in unsafe sequences. |
| ASI04 — Agentic Supply Chain Vulnerabilities | The article also focuses on compromised dependencies and malicious updates. | |
| Recommendation — Constrain tool scopes and inspect tool-use sequences for unsafe composition. Revalidate agent dependencies and update channels whenever components change. | ||
| MITRE ATLAS | TA0006;TA0008 — Credential Access; Lateral Movement | Tool misuse and compromised dependencies support adversarial access and movement patterns. |
| Recommendation — Map agent misuse paths to credential access and lateral movement behaviours in detection rules. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about governance of agentic risk, not just technical detection. |
| Recommendation — Assign ownership for agent approval, runtime oversight, and dependency revalidation. | ||
| ISO/IEC 42001:2023 | A.3 — Internal Organisation | Agentic trust and accountability require defined organisational ownership. |
| Recommendation — Define accountable owners for agent behaviour, provenance, and change control. | ||
Key terms
- Tool Misuse: Tool misuse occurs when an agent uses an allowed integration in a way that exceeds its intended task, scope, or risk tolerance. The problem is often not access alone but the combination of valid credentials, broad permissions, and unbounded action sequencing.
- Agentic Supply Chain Vulnerability: An agentic supply chain vulnerability is a weakness that appears when AI agents depend on other agents, tools, prompts, models, data sources, or automation steps to complete work. It arises when trust, identity, permissions, or input integrity fails anywhere in that chain, allowing manipulation, misuse, or unintended actions across connected systems.
- Sequence-Aware Inspection: Sequence-aware inspection evaluates how actions unfold across a run, rather than judging each call in isolation. It is essential for agentic systems because harmful behaviour often appears only when ordinary steps are combined into a larger workflow.
- Dependency Provenance: Evidence that a package release came from the expected source, build pipeline, and repository state. Provenance matters because version numbers alone do not prove trust, and malicious actors can use legitimate-looking releases to hide harmful code.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It is built for practitioners who need to connect identity controls to modern machine and agentic systems.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org