Agentic AI supply chain threats are moving into security workflows

At a glance

What this is: Knostic is positioning AgentMesh as an analysis stream for AI agent skills, MCP servers and IDE extensions, with a key finding that prompt injection and supply-chain abuse are increasingly embedded in agent tooling.

Why it matters: For IAM, PAM and NHI teams, this matters because agent tooling now carries the same trust and privilege assumptions as other non-human identities, but with far less mature control and review processes.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Knostic's analysis of AI agent supply chain threats and AgentMesh

Context

AI agent supply chains are becoming a security problem because the tools agents rely on, including MCP servers, IDE extensions and skills, can be tampered with before an organisation ever reviews the agent itself. In practice, the trust boundary has shifted from the model to the component ecosystem around it, which is why traditional malware scanning and code review do not fully cover the risk.

This matters for identity governance because agentic tools are effectively part of the non-human identity stack when they can act, call tools, and reach data or code on behalf of a user or workload. When a compromised extension or server can shape agent behaviour, the organisation is not just screening software, it is governing delegated access paths that behave like machine identities with execution rights.

Key questions

Q: How should security teams govern AI agent toolchains that include MCP servers and IDE extensions?

A: Security teams should treat every MCP server and IDE extension as a governed access path, not a convenience layer. That means assigning ownership, validating provenance, restricting permissions, and reviewing behaviour continuously. If a component can change what the agent sees or does, it belongs in the same control conversation as privileged access and secrets exposure.

Q: Why do compromised AI agent tools create NHI risk?

A: Compromised agent tools create NHI risk because they can redirect delegated access without needing to steal the primary agent account. A malicious tool can influence what data is read, what systems are called, and what secrets are exposed, which turns the agent into an execution proxy for attacker intent.

Q: What should teams look for when assessing AI agent supply chain risk?

A: Teams should look for typosquatting, unexpected network behaviour, secret exfiltration patterns, and unusual response shaping. These are often earlier indicators than confirmed malware. A good assessment combines package provenance, runtime telemetry, and access scope so suspicious components can be isolated before they influence production workflows.

Q: Who is accountable when an AI agent extension causes data exposure or secret leakage?

A: Accountability should sit with the team that approved, deployed, and monitored the component, not with the agent itself. Governance must define who owns component review, who can approve elevated access, and who responds when a tool changes behaviour. Without that assignment, incident response becomes fragmented and remediation slows.

Technical breakdown

How prompt injection reaches the agentic tool layer

Prompt injection in the agentic supply chain does not require breaking the model itself. Attackers place malicious instructions inside tool descriptions, response fields, package metadata, or extension content so that the agent consumes them as part of normal orchestration. Once the agent trusts that content, it may call tools, reveal context, or route data in unintended ways. Behavioural analysis is more useful than static signature matching because these payloads often mutate and are embedded in legitimate-looking components.

Practical implication: inspect tool metadata and runtime behaviour, not just file hashes or package names.

Why MCP servers and extensions behave like privileged integration points

MCP servers and IDE extensions sit close to the agent's decision path, which makes them privileged integration points rather than passive add-ons. They can expose data sources, mediate actions, and expand what the agent is allowed to see or do. That creates a governance problem familiar to IAM teams: any component that widens access or delegates execution should be treated as part of the trust boundary. In agentic environments, tool access is identity policy by another name.

Practical implication: inventory every MCP server and extension as a governed access path with explicit ownership and review.

Supply chain signals that distinguish suspicious from malicious

Agentic supply chain telemetry is valuable because compromise often appears first as anomalous behaviour, not confirmed malware. Typosquatting, unexpected outbound connections, secret exfiltration patterns, and unusual response shaping are indicators that a component may be trying to influence agent behaviour or leak data. This is the same logic used in broader software supply chain defence, but applied to the agent layer where the consequence is not only code compromise, but also delegated data access and action abuse.

Practical implication: tie agent component scoring to network, secrets and data-access telemetry so suspicious behaviour can trigger containment.

Threat narrative

Attacker objective: The attacker wants to hijack trusted agent tooling so the agent itself becomes the delivery mechanism for access, leakage, or manipulation.

1. Entry occurs when an attacker publishes a malicious or typosquatted AI skill, MCP server, or IDE extension that looks legitimate enough to be installed or consumed by an agent workflow.
2. Escalation happens when the agent trusts the component, ingests injected instructions, and uses its delegated access to call tools, read context, or reach connected data sources.
3. Impact follows when the compromised component drives secret exfiltration, unauthorised system access, or downstream code and data manipulation through the agent's execution path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic supply chain risk is becoming an identity problem, not just a software integrity problem. When an AI agent consumes a tool, server, or extension, it is inheriting that component's trust into an execution pathway. That makes the component ecosystem part of the non-human identity governance surface, because delegated access can be redirected without changing the primary agent account. Practitioners should treat agent tooling as governed identity infrastructure, not optional add-ons.

Prompt injection at the tool layer creates a new control gap that traditional threat intelligence misses. Signatures are weak against payloads hidden in metadata, responses, and package descriptions, while behavioural analysis can observe what the component actually tries to do. This is why security teams need detection that follows agent actions, not just artifact classification. The field should expect more focus on runtime trust validation across MCP and extension ecosystems.

Tooling ecosystems now carry the same blast-radius logic that identity teams already manage for privileged accounts. A compromised server or extension can widen access, change context, or move data without human review. That is the same governance failure pattern as over-privileged service accounts, only translated into agent operations. The practical conclusion is that identity, application security, and supply chain controls must converge around agent components.

AgentMesh-style analysis reflects a broader shift toward treating AI components as inspectable security objects. The market is moving from static cataloguing toward continuous behavioural verdicts, because the question is no longer whether a component exists but whether it changes the agent's authority at runtime. That direction aligns with the need for policy enforcement and provenance tracking across the AI stack. Practitioners should prepare for component-level governance, not one-time approval.

Named concept, agentic trust boundary collapse: the point at which a tool, extension, or server is trusted as though it were part of the agent itself. Once that boundary collapses, the organisation loses clear separation between model behaviour, delegated access, and external code provenance. Security teams should design controls that preserve the boundary before they try to score the risk.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• OWASP Agentic AI Top 10 frames the control patterns most likely to reduce tool misuse, prompt injection, and privilege abuse across agent workflows.

What this signals

Agentic trust boundary collapse: security programmes will need to separate model risk from tool risk, because the attack surface increasingly sits in the components that agents consume rather than the model prompt alone. That shift will force tighter provenance controls, runtime inspection, and access scoping across the agent toolchain.

The practical issue for IAM and PAM teams is that agent components now behave like delegated non-human identities with hidden reach into data, code, and network paths. If governance cannot answer which tool widened access, the programme will not be able to explain or contain the resulting exposure.

Security leaders should expect AI toolchain review to converge with software supply chain governance, secrets monitoring, and identity policy enforcement. The next maturity step is not approving more tools, but proving that each tool can be observed, constrained, and revoked when its behaviour changes.

For practitioners

• Inventory agent tool dependencies Catalog every MCP server, IDE extension, skill, and plugin used by AI assistants, then assign an owner, business purpose, and review date for each dependency. Treat the inventory as part of the non-human identity estate, not a software wish list.
• Inspect behaviour, not just packages Add behavioural analysis for tool metadata, response shaping, outbound connections, and secret access attempts so suspicious components can be identified even when they appear legitimate.
• Bind agent tools to least privilege Limit the data sources, commands, and network paths available to each agent tool, and revoke broad access by default when the component does not need it for a defined task.
• Correlate agent alerts with secrets and data telemetry Route suspicious component verdicts into secrets monitoring, data access logs, and SOC workflows so a malicious extension or server can be contained before credential leakage spreads.

Key takeaways

• AI agent tools are part of the identity problem because they extend delegated access into data, code, and execution paths.
• Behavioural analysis is more useful than static signatures when malicious logic is hidden inside tool metadata and responses.
• Practitioners should inventory, constrain, and continuously monitor MCP servers and extensions as governed access paths.

Key terms

• Agentic Trust Boundary: The point at which an AI agent's authority stops and the surrounding tools, servers, and extensions begin. When that boundary is weak, external components can alter the agent's actions, data access, or execution path without changing the agent's own account or prompt.
• Prompt Injection: A technique that places malicious instructions inside content an AI system will process, such as tool descriptions, responses, or metadata. In agentic systems, the goal is to redirect behaviour, make the agent reveal information, or persuade it to take unsafe actions through trusted inputs.
• Agentic Supply Chain: The ecosystem of packages, skills, servers, extensions, and services that an AI agent depends on to operate. Security risk in this chain comes from the fact that compromise in any component can influence the agent's decisions, reach, or privileges at runtime.
• Behavioural Verdict: A security assessment based on what a component actually tries to do during analysis, rather than only on its name, hash, or declared purpose. For agentic tools, behavioural verdicts help expose hidden prompt injection, suspicious networking, and secret access attempts.

What's in the full article

Knostic's full blog post covers the operational detail this post intentionally leaves for the source:

• How AgentMesh classifies MCP servers and VS Code extensions as benign, suspicious, or malicious
• The behavioural signals used to detect prompt injection and secret exfiltration patterns in tool content
• The specific agentic supply chain cases Knostic says it has been tracking across 2026
• How VirusTotal's Crowdsourced AI program is intended to surface agent-layer verdicts in analyst workflows

👉 Knostic's full post covers the behavioural verdict model, threat cases, and rollout context for AgentMesh in VirusTotal.

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 identity lifecycle controls that matter when AI tools expand delegated access. It helps practitioners connect identity policy to the operational realities of modern security programmes.