Topic starter
18/08/2026 2:41 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by ActiveFence: “AI Skills Security: A Practitioner’s Guide to Emerging Threats”.
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.
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.
Q: Why do agent-to-agent trust gaps create more risk than direct user prompts?
A: Peer agents often inherit trust and context that a direct user never receives, so malicious instructions can travel through delegated workflows with fewer checks.
Q: What are the warning signs that an AI skill is operating outside its intended boundary?
A: Look for unusual tool combinations, unexpected external calls, repeated privilege requests, and data movement that does not match the skill’s declared purpose.
Practitioner guidance
- Define per-skill privilege scopes Assign each AI skill only the APIs, data sources, and actions it genuinely needs, then block everything else by default.
- Sandbox agent execution paths Run untrusted or externally sourced skills inside isolated environments with constrained filesystem access and tightly controlled egress.
- Verify skill provenance before deployment Require review of source, version, and permitted integrations for every skill pulled from a third-party registry or repository.
Bottom line: AI skills expand agentic AI risk because trusted execution paths now include untrusted instructions, third-party provenance, and delegated tool use.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:25 pm
AI skills security is really identity and execution governance in disguise: the real issue is not whether a model can be persuaded, but whether its delegated tools, data sources, and peer agents are tightly scoped. Once a skill can act on behalf of the system, every trust decision becomes an access decision. Practitioners should govern skills as privileged runtime components, not as harmless extensions.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations approve AI skills the same way they approve software plugins?
A: They should be at least as strict, and usually stricter, because skills can combine data access, tool execution, and delegation in one control path. Approval should cover provenance, runtime isolation, identity binding, and revocation, not just package review or code scanning.
👉 Read our full editorial: AI skills security exposes trust gaps in agentic AI architectures