TL;DR: AI skills now turn LLMs into systems that can query data, invoke tools, and interact with services, but ActiveFence’s analysis shows those same capabilities expand the attack surface through prompt injection, confused-deputy abuse, and multi-agent trust gaps. The practical lesson is that agent security depends on deterministic controls around the model, not prompt engineering alone.
At a glance
What this is: This is an analysis of how AI skills, tools, and MCP-based agents expand the attack surface through prompt injection, tool abuse, and unsafe inter-agent trust.
Why it matters: It matters to IAM, PAM, and AI security teams because AI skills behave like privileged non-human identities and need lifecycle, access, and trust controls that match their runtime power.
By the numbers:
- 82.4% of state-of-the-art LLMs execute malicious commands from peer agents that they would refuse from direct user input.
- A 2024 analysis of 1,038 ChatGPT plugins found 173 plugins with broken access control vulnerabilities.
- A 2024 analysis of 1,038 ChatGPT plugins found 368 plugins that leaked developer credentials, including API keys and OAuth tokens.
- MCP reached over 97 million monthly SDK downloads as it moved into mainstream adoption.
👉 Read ActiveFence's analysis of AI skills security threats and agentic trust gaps
Context
AI skills turn a large language model into an active system that can take actions, not just generate text. That shift matters because the model now sits inside tool chains, data flows, and trust boundaries that traditional application security was never designed to govern. The result is a genuine AI skills security problem, with identity and access decisions moving into runtime behaviour rather than static configuration.
The governance gap is not simply one of prompt safety. Once an agent can read untrusted content, call tools, and exchange information with other agents, the control problem looks much closer to non-human identity governance, least privilege, and approval boundaries than to classic chatbot moderation. That makes the article relevant to IAM, PAM, and agentic AI programmes even though the primary domain is broader AI security.
Key questions
Q: How should security teams govern AI models that can call tools and access data?
A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.
Q: Why do AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.
Q: What breaks when an AI agent trusts peer agents too readily?
A: A single compromised agent can influence others through shared instructions, delegated tools, or broadcast context, creating lateral movement across the agent mesh. That can lead to unauthorized data access, secret exposure, or unintended state changes. The failure is not only technical; it is a trust model that assumes peer input is inherently safe.
Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?
A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.
Technical breakdown
Why AI skills become an execution surface
AI skills, sometimes called tools, functions, plugins, or agents, connect an LLM to external systems through structured calls and return values. That means the model is no longer isolated text generation. It can trigger code execution, query databases, move data across services, and act on instructions embedded in retrieved content. The security boundary shifts from the prompt alone to the entire orchestration layer, where trust must be enforced in deterministic code rather than inferred from model behavior.
Practical implication: treat every agent tool chain as an execution environment that needs explicit allowlisting, permission scoping, and audit logging.
Indirect prompt injection and confused deputy risk in MCP
Indirect prompt injection occurs when malicious instructions arrive through data the agent retrieves, such as web pages, emails, documents, or API responses. The model cannot reliably distinguish instructions from content, so poisoned data can steer tool use or exfiltration. In MCP-style systems, that becomes a confused deputy problem because the agent may use legitimate authority to carry out attacker-controlled actions. This is why framework-level provenance, content filtering, and identity binding matter more than prompt hardening alone.
Practical implication: validate data provenance before the agent acts, and separate read, write, and control-plane permissions.
Multi-agent trust gaps create lateral movement paths
The most alarming failure mode is agent-to-agent trust. Research cited in the article shows that models often accept malicious commands from peer agents even when they reject the same instructions from users. That makes the trust mesh itself an attack surface. In practical terms, compromise of one agent can cascade into another, especially where shared context, delegated tools, or broadcast instructions exist. This is the agentic equivalent of lateral movement, only faster and harder to detect.
Practical implication: segment agent domains, restrict peer-to-peer delegation, and require human approval for cross-boundary actions.
Threat narrative
Attacker objective: The attacker aims to hijack agent behavior so a trusted AI system becomes a conduit for data theft, unauthorized actions, or downstream compromise.
- Entry begins with malicious instructions hidden inside retrieved content, peer-agent messages, or compromised skill definitions.
- Escalation occurs when the agent treats that content as authoritative and uses its legitimate tool access to execute attacker-directed actions.
- Impact follows as secrets, internal data, or privileged actions are exposed through trusted automation paths.
NHI Mgmt Group analysis
AI skills are becoming non-human identities in practice, even when organisations do not label them that way. Once a model can use tools, access data, and act across services, it needs identity, privilege, and lifecycle governance like any other high-value machine actor. The governance gap is not theoretical: these systems inherit authority without always inheriting controls. Practitioners should classify agent skills as governed identities, not informal automations.
Indirect prompt injection creates a trust boundary problem, not just a content moderation problem. The article correctly shows that malicious instructions can enter through retrieved data and return values, which means the security issue sits in the data plane and orchestration plane. That pattern aligns closely with identity abuse in other domains, where an attacker does not need to break authentication if they can steer a trusted intermediary. Practitioners should design controls around provenance and bounded authority.
Agent-to-agent trust is the named concept security teams should track: delegated trust collapse. The article’s multi-agent findings show that peer instructions can override normal resistance, which means one compromised agent can influence others through trust relationships rather than technical exploits. This is a governance failure in delegated authority, and it should be mapped to AI RMF GOVERN and MANAGE disciplines. Practitioners should assume peer trust is unsafe until proven otherwise.
MCP adoption is outpacing the control patterns needed to secure it. The protocol’s momentum makes it attractive for integration, but its openness also amplifies provenance, access, and monitoring gaps across the ecosystem. That is familiar to identity leaders: standards adoption without lifecycle governance produces shadow authorities. Practitioners should treat MCP enablement as a governance programme, not just an integration choice.
Security teams should stop treating prompt engineering as a primary control. The article shows why model behavior can be manipulated even when prompts are well formed, because the real risk sits in external data, tool invocation, and delegated authority. That pushes teams toward policy enforcement, sandboxing, and observability. Practitioners should evaluate controls by whether they can contain abuse after trust has already been extended.
What this signals
AI skills are moving from experimental interfaces to governed business systems, which means security teams will need to inventory them the same way they inventory other privileged automation. The control question is no longer whether an agent can be blocked from saying the wrong thing. It is whether its trust, data, and action boundaries are enforceable at runtime, and whether the organisation can prove that enforcement to auditors and risk owners.
Delegated trust collapse: this is the pattern teams should watch as agent ecosystems expand. The moment one agent can influence another through shared context or tool authority, traditional model safety controls become insufficient. Security programmes should align AI governance with NIST AI Risk Management Framework principles and use deterministic controls around identity, approval, and observability.
The practical direction for identity and security leaders is clear: treat agent enablement like privileged access expansion, not like simple application onboarding. That means scoping permissions, logging every action path, and limiting peer-to-peer delegation until the organisation can measure and contain abuse. Where identity governance already exists for service accounts, it should now extend to AI skills and MCP-connected agents.
For practitioners
- Classify AI skills as governed identities Assign each skill, tool, or agent an owner, explicit purpose, approved data scope, and expiry or review date so authority is not left implicit.
- Enforce least-privilege tool boundaries Separate read, write, and external communication permissions, and require read-only tokens wherever an agent does not truly need mutation rights.
- Block untrusted content from direct action paths Quarantine retrieved web pages, emails, documents, and peer-agent messages before the model can turn them into tool calls or state changes.
- Add human approval for cross-boundary actions Require review before production writes, financial actions, or any delegation that crosses team, tenant, or trust-domain boundaries.
- Instrument agent activity end to end Log prompts, tool invocations, returned values, and privilege use so abnormal chains can be investigated without relying on the model’s own explanation.
Key takeaways
- AI skills expand the attack surface because they turn model output into tool-enabled action paths.
- Peer-agent trust is a documented failure mode, and it can be used to steer one agent through another.
- Security teams need deterministic governance for AI skills, including scoped privileges, provenance checks, and approval boundaries.
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 and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | The article centers on agentic AI trust gaps, prompt injection, and tool misuse. | |
| NIST AI RMF | GOVERN | AI governance and accountability are central to the article's control model. |
| MITRE ATLAS | TA0006 , Credential Access; TA0008 , Lateral Movement | The attack pattern includes trust abuse, credential exposure, and agent-to-agent propagation. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access restrictions are the article's primary defensive theme. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege directly fits tool scoping and action containment for agents. |
Map agent tool chains to agentic AI risks and constrain every external action with policy and validation.
Key terms
- AI Skill: An AI skill is a tool, function, plugin, or agent capability that lets a model interact with external systems and data. It turns the model from a text generator into a runtime actor that can query, retrieve, write, or execute within defined permissions and boundaries.
- Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
- Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
- Delegated Trust Collapse: Delegated trust collapse is the failure mode where one AI agent accepts another agent's instructions too readily and propagates that trust across a mesh. The result is lateral movement through automation relationships rather than through traditional account compromise.
What's in the full article
ActiveFence's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how AI skills, plugins, and MCP-style integrations become exploitable through indirect prompt injection.
- Proof-of-concept material showing how malicious instructions flow from retrieved content into tool invocation and data exfiltration.
- Mitigation patterns for sandboxing, guardrails, and monitoring that are grounded in the article's examples.
- The article's timeline of MCP ecosystem vulnerabilities and why each one matters for deployment decisions.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building controlled access models. It gives security and identity teams a shared framework for governing privileged non-human systems.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org