AI agents gain practical abilities through reusable skills. A skill may tell an agent how to create a deployment, analyse a spreadsheet, access a CRM, triage an incident or coordinate several tools. This behaviour layer is powerful because teams can add new capabilities quickly. It is also security-sensitive because the skill can influence what the agent reads, which tools it calls and how it chains actions.
The OWASP Agentic Skills Top 10 project focuses on this rapidly growing layer. Its useful mental model is that protocols such as MCP define how an agent talks to tools, while skills define what the agent does with those tools across a workflow.
Prompt injection is one of the main ways untrusted content can redirect a capable skill. Use the prompt injection testing methodology to evaluate direct, indirect and tool-enabled attack paths.
For an enterprise, installing a skill should not be treated like copying harmless documentation. Skills can behave more like executable configuration or a software dependency. They need provenance, review, testing, permissions, monitoring and a reliable removal path.
What is an agentic skill?
An agentic skill is a reusable package of instructions, metadata, scripts, templates or tool mappings that helps an AI agent perform a specialised task. Formats vary across platforms, but a skill may contain:
- Natural-language operating instructions.
- Tool names and parameter guidance.
- Scripts or code executed during the workflow.
- Templates for reports, messages or files.
- External references, packages or downloadable assets.
- Examples that influence model behaviour.
- Required permissions, connectors and environment variables.
- Delegation rules for sub-agents.
That combination means a skill can affect both reasoning and execution. Even when it contains no traditional executable file, its instructions may cause a capable agent to run commands or transmit data.
Why skills create a distinct attack surface
Security teams already review applications, packages, browser extensions and SaaS integrations. Skills intersect all of them but may bypass established processes because they look like text.
Several characteristics increase risk:
- Natural language is executable in context. Instructions can influence tool use without calling a traditional function directly.
- Skills compose. A low-risk skill can interact with another skill that has powerful access.
- Authority is inherited. The skill may use the agent’s filesystem, tokens and connected tools.
- Updates can change behaviour. A trusted package can become unsafe after installation.
- Ownership is often unclear. Skills may be copied from public repositories without a maintained inventory.
- Review is difficult. Harmful instructions can be hidden in examples, linked content, encoded assets or long documentation.
This is why skill governance belongs in both application security and supply-chain security.
Risk 1: Malicious or compromised skill instructions
A skill can contain explicit or hidden instructions to read sensitive files, call an external service or weaken safeguards. The visible purpose may be legitimate while secondary steps create data exposure.
Review all instruction sources and resolve external references. Search for requests involving credentials, broad filesystem access, network transmission, policy override or persistence. Run the skill with synthetic secrets in an isolated environment and observe actual tool activity.
Do not rely on a marketplace description or popularity. Trust should come from verified provenance, review and controlled execution.
Risk 2: Dependency and reference hijacking
Skills may install packages, download scripts, call hosted prompts or reference repositories and domains. If an owner deletes or transfers one of those resources, an attacker may register the abandoned name and serve malicious content.
Pin dependencies to verified versions or immutable hashes. Vendor critical assets internally. Monitor domains, repository ownership and package integrity. Fail closed if a dependency changes unexpectedly rather than silently retrieving the latest version.
The broader software supply chain security testing guide provides controls for package provenance, CI/CD and dependency monitoring.
Risk 3: Excessive permissions
A skill may request complete email, cloud, repository or database access for a workflow that needs only a narrow operation. The agent then becomes a confused deputy: a malicious prompt can use the skill’s broad token for an unintended purpose.
Document required permissions before installation. Separate read and write authority. Use task-specific, short-lived credentials and resource-level restrictions. A reporting skill should not inherit deployment or deletion privileges simply because those tools are available to the same agent.
Test whether ordinary users can cause the skill to access another tenant, project or mailbox. API authorization must enforce the user and resource on every call.
Risk 4: Tool and command misuse
Skills often translate natural language into tool parameters or shell commands. Untrusted values may produce command injection, path traversal, server-side request forgery or destructive operations.
Prefer structured tool schemas and allowlisted operations. Validate types, ranges, paths, URLs and business rules outside the model. Run commands in a restricted workspace. Require an independent approval for actions affecting production, access, money or bulk data.
Use negative test values and harmless canaries to verify that validation happens before execution.
Risk 5: Cross-skill interference
An agent may load several skills into the same context. One skill can shadow tool names, override instructions or manipulate data consumed by another. A public research skill could influence a privileged deployment skill even though each looks acceptable in isolation.
Separate trust domains and minimise the number of active skills. Namespace tools clearly. Do not mix untrusted content retrieval with privileged execution in one unrestricted context. Define an explicit policy for precedence and delegation.
Testing must examine combinations, not just individual skills. Attempt to make a low-trust skill invoke, redirect or provide hidden instructions to a higher-trust capability.
Risk 6: Data exfiltration through legitimate channels
An attacker does not need a suspicious network connection if a skill can send email, create tickets, search the web or update a shared document. Sensitive data can be encoded in a legitimate tool argument.
Apply data-loss controls at the tool gateway. Restrict destinations and fields. Redact secrets before content reaches the model and before outbound actions execute. Monitor unusual volume and combinations, such as reading a secret followed by an external write.
Approval screens should show the exact recipient and data, not a model-generated summary.
Risk 7: Secret exposure
A skill may instruct users to paste keys into prompts or place them in ordinary files. Scripts may print environment variables or error messages may expose authorization headers. Traces can preserve the leak.
Integrate a secrets manager and inject credentials only at execution time. Keep secrets out of skill text, examples and tool responses. Redact telemetry and use short-lived tokens. Scan skill packages and generated artifacts before distribution.
During assessment, use synthetic secrets to map every place sensitive material can travel.
Risk 8: Unsafe persistence and memory
A skill can write configuration, modify future instructions, create scheduled jobs or store information in agent memory. Malicious or accidental persistence may survive after the immediate task.
Declare every persistent side effect. Restrict write locations, scheduled tasks and memory namespaces. Store provenance and ownership for memory entries. Provide an uninstall procedure that removes configuration, credentials, cached content and scheduled actions.
Test whether a low-privilege user can create durable instructions that affect another user or future session.
Risk 9: Inadequate verification and misleading output
A skill may claim that a backup, scan or deployment succeeded without checking the target. Humans and downstream agents can make decisions based on that false confidence.
Require deterministic evidence: exit codes, signed responses, test results, resource identifiers and independent status checks. Separate generation from verification when the impact is high. A security-scanning skill should not silently suppress failures or rewrite thresholds.
Test partial outages, tool errors and conflicting results. The skill should fail safely and communicate uncertainty accurately.
Risk 10: Weak lifecycle governance
Skills can spread through teams without central inventory. Versions drift, owners leave and unmaintained skills retain access. Incident responders may not know which agents installed a compromised skill.
Maintain a registry containing source, owner, version, hash, permissions, dependencies, approved agents and last review date. Monitor updates and deprecations. Support rapid disablement and identify every deployment of a vulnerable version.
Governance should cover internal skills as well as public ones. An internal package can become orphaned or compromised.
A secure skill adoption workflow
Stage 1: Business justification
Define the task, users, data and expected benefit. Avoid installing broad general-purpose skills when a narrow deterministic integration would be safer.
Stage 2: Provenance review
Verify publisher identity, source repository, licence, maintenance history and distribution path. Record the exact version or commit. Treat copied or forked skills as independent assets with internal ownership.
Stage 3: Static inspection
Review instructions, scripts, dependencies, external URLs, tool names, permissions and persistence. Look for obfuscation, encoded content, dynamic downloads, secret access and policy overrides.
Stage 4: Isolated dynamic testing
Run the skill in a sandbox with synthetic data and canary credentials. Monitor filesystem, process, network, tool and memory activity. Exercise normal tasks, malformed input, malicious documents and failure conditions.
Stage 5: Permission design
Create a dedicated identity with the minimum scopes and resources. Separate read and write. Define approvals, rate limits, destinations and data-loss policy.
Stage 6: Combination testing
Load the skill with other capabilities intended for the production agent. Test tool shadowing, instruction conflicts, delegation, cross-skill data flow and attempts to borrow privileged authority.
Stage 7: Controlled release
Deploy to a limited user group. Pin the approved artifact, log the version and watch behaviour. Do not permit silent auto-updates for high-risk skills.
Stage 8: Continuous monitoring
Detect source changes, new dependencies, unusual tool use, external destinations and privilege expansion. Reassess after material updates or agent-platform changes.
Stage 9: Revocation and removal
Test disabling the skill, revoking its credentials and finding every installed copy. Remove persistent memory, files and scheduled actions. Preserve evidence when compromise is suspected.
Agentic skill security testing checklist
Use these questions before approval:
- Is the publisher and source verifiable?
- Is the exact reviewed version pinned?
- Are all scripts, references and downloads visible?
- Are dependencies verified and monitored?
- Does the skill request only essential tools and scopes?
- Are user, tenant and resource permissions enforced server-side?
- Are tool arguments validated outside the model?
- Can untrusted content alter privileged instructions?
- Can the skill read files or secrets outside its task?
- Can data leave through email, search, tickets or URLs?
- Are commands isolated and destructive actions approved?
- Can the skill modify memory or create persistence?
- Does it interact safely with other active skills?
- Are outputs verified through deterministic evidence?
- Are tool calls, identity, resource and outcome logged?
- Can credentials and sessions be revoked quickly?
- Can every deployed copy be found and disabled?
- Is there an owner and next review date?
Relationship between skills, MCP and agent applications
These layers overlap but require different questions.
- Agent application security examines goals, autonomy, identity, memory, orchestration and business outcomes.
- MCP security examines protocol connections, servers, tool definitions, transport, OAuth and cross-server trust.
- Skill security examines reusable behavioural instructions, scripts, dependencies, composition and lifecycle.
A secure MCP connection does not make a malicious skill safe. A reviewed skill does not make an over-privileged MCP server safe. Both sit inside an agent application that must enforce authorization and business policy.
Read the OWASP Top 10 for Agentic Applications enterprise guide for the application layer and the MCP server security guide for the tool protocol layer.
Incident response for a compromised skill
If a skill is suspected of malicious behaviour:
- Disable it across agent platforms and block its source.
- Pause affected agents and high-risk tool calls.
- Revoke tokens, API keys and sessions the skill could access.
- Preserve the package, version, hash, prompts, commands and network logs.
- Identify every agent, user and environment that installed it.
- Review filesystem, memory, scheduled tasks and configuration changes.
- Trace data reads and outbound writes during the exposure period.
- Rotate downstream secrets and remove persistence.
- Restore a known-good configuration.
- Retest before re-enabling affected workflows.
Do not merely delete the skill folder. Its scripts may have changed other assets or created durable access.
Where security assessment adds value
Internal review establishes trust and intended permissions. Adversarial testing checks whether a skill can be manipulated through untrusted inputs, composed with other tools or used to cross identity boundaries.
A scoped penetration testing engagement can evaluate the agent interface, skills, MCP servers, APIs, credentials and target systems together. Detox’s AI agent red teaming checklist offers related scenarios for prompt injection, tool abuse and data leakage.
The most useful finding demonstrates a concrete unauthorized outcome with minimal impact, identifies the trust path and gives developers a repeatable regression test.
Frequently asked questions
Is an agent skill just a prompt?
Some skills are primarily instructions, but many also include scripts, templates, dependencies and tool mappings. Even text-only instructions can cause a capable agent to execute actions, so they remain security-relevant.
Is a skill safe if it comes from a popular marketplace?
Popularity is not verification. Review provenance, version, dependencies, permissions and runtime behaviour. Monitor future changes and be prepared to revoke the skill.
Should skills update automatically?
High-risk enterprise skills should not change silently. Monitor updates, review the diff, test the new artifact and deploy through a controlled process. Emergency security fixes may be expedited but still require integrity verification.
Can endpoint security detect a malicious skill?
It may detect some scripts or processes, but many harmful actions use legitimate agent tools and APIs. Tool-level policy, identity controls, egress restrictions and behaviour monitoring are also required.
What should an organisation do first?
Inventory the skills already installed and the permissions available to their agents. Remove unused packages, pin approved versions and isolate the skill with the broadest access for a focused review.
Conclusion
Agentic skills turn AI capability into repeatable action. That makes them valuable—and makes their instructions, scripts and dependencies part of the enterprise software supply chain.
Secure adoption requires verified provenance, static review, sandbox testing, least privilege, composition testing, monitoring and fast revocation. Skills should never inherit every permission connected to an agent, and untrusted content should never be able to redirect a privileged workflow.
Start by treating each skill as executable security-relevant software. Record who owns it, what it can reach and the exact version that was reviewed. Then test what happens when its input, dependency or neighbouring skill becomes hostile. That discipline allows enterprises to reuse agent capabilities without creating an invisible and unmanaged execution layer.
Validate agentic skills before production
Detox Technologies’ AI security testing and red teaming services assess skills, tools, permissions, prompt injection, data exposure and business-impacting agent actions as one connected attack surface.
