What breaks when organisations rely only on static analysis for AI agent skills?

Why Static Analysis Fails for AI Agent Skills

Static analysis is useful for catching obvious defects in code, but it is a poor fit for AI agent skills that assemble behaviour at runtime. The real risk is not just what the skill file contains, but what it can do once it starts calling tools, fetching remote content, or following hidden instructions embedded elsewhere. That is why guidance from the OWASP Agentic AI Top 10 and NHI research such as OWASP NHI Top 10 both point to the same problem: agents are dynamic systems, not static artifacts.

Once a skill can chain prompts, invoke APIs, or pull payloads from remote endpoints, a file scan cannot reliably prove safety. Hidden links, delayed execution, self-reinstalling logic, and tool-abuse paths may not appear in the source at all. Security teams often assume that a clean review means a clean execution path, but that assumption collapses when the agent’s effective behaviour depends on context, memory, and runtime policy.

In practice, many security teams discover malicious agent behaviour only after a tool call, data access, or persistence event has already occurred, rather than through intentional pre-deployment review.

How Runtime Evaluation Changes the Control Model

Static analysis should be treated as one layer, not the control plane. For AI agent skills, the stronger model is runtime validation: inspect what the agent is trying to do, verify whether the requested action matches policy, and issue only the minimum credentials needed for that task. That is where intent-based authorisation, ephemeral secrets, and workload identity become more important than code-only inspection. Current guidance from the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework supports this shift toward context-aware controls.

Practitioners should assume an agent may behave differently from one run to the next. A skill that looks harmless in source can later retrieve a remote instruction, load a second-stage payload, or reuse a token in an unintended workflow. Security checks therefore need to move closer to execution, with request-time policy evaluation and strong identity proofs for the workload itself.

• Use policy-as-code to approve or deny each tool call at runtime.
• Issue short-lived credentials per task, then revoke them immediately after use.
• Bind access to workload identity rather than trusting a static skill package.
• Log data access and tool invocation so post-execution review is possible.

This is where AI Agents: The New Attack Surface report is especially relevant: NHIMG cites that 80% of organisations report their AI agents have already acted beyond intended scope, while only 52% can track and audit the data those agents access. Those numbers matter because static analysis cannot close a runtime visibility gap. These controls tend to break down when agents can call external tools with inherited enterprise privileges, because the execution path becomes broader than any one skill review can predict.

Where the Edge Cases Defeat Code Review

Tighter scanning often increases review time and operational friction, requiring organisations to balance faster delivery against incomplete assurance. That tradeoff becomes especially visible when skills are generated dynamically, composed from multiple prompts, or updated after deployment. In those environments, a “clean” scan may only mean the current snapshot had no obvious indicators, not that the skill is safe under live conditions.

There is no universal standard for how much static analysis is enough for agent skills. Best practice is evolving toward layered assurance: static checks for obvious unsafe patterns, runtime controls for tool use, and continuous monitoring for drift. In agent-heavy environments, this is especially important because a benign-looking skill can become dangerous once it inherits a high-privilege session, calls an external MCP service, or is instructed by a remote payload to persist across runs.

NHIMG case studies such as Analysis of Claude Code Security and Replit AI Tool Database Deletion show the practical risk: the problem is not just what the code says, but what the agent can be induced to do once execution begins. That is why static analysis alone is a weak final gate for AI agent skills.

Related resources from NHI Mgmt Group

• What are Agent Skills and how do they enhance AI performance?
• When should organisations treat an AI agent as a privileged system?
• What breaks when organisations rely on static permissions for enterprise AI search?
• What breaks when organisations rely on static scans for AI security?