Your Agent Skills Need Boundaries, Not Just Better Instructions

Reusable skills are one of the most useful patterns in modern agent work. Instead of asking a model to rediscover your deployment process, your code-review checklist, or your customer-support escalation flow every time, you package the procedure as a skill. The agent loads it when relevant, follows the steps, and can reuse the same operational knowledge across projects.

That is a real improvement over prompt sprawl. It is also a new trust boundary.

A new arXiv paper, “Chaining Skills to Hijack LLM Agents”, makes the risk concrete. The authors study agents that invoke multiple skills in sequence. Their attack, APEX, does not need to win by shouting a malicious instruction at the agent in one obvious place. Instead, an upstream skill can cause the agent to create a record of apparently genuine task progress that includes a false claim of user approval. A downstream skill then treats that record as evidence and performs the attacker-selected action.

That distinction matters. The weak point is not only “the model followed bad text.” The weak point is that one skill’s artifact became another skill’s authority.

The reported numbers are high enough to take seriously. The paper says adversarial chains induced the selected action in 512 of 690 attempts, or 74.2%. On GPT-5.4, the full chain succeeded in 84.3% of attempts, compared with 17.4% when the workflow was merged into a single skill. A prompting defense reduced targeted-action success, but still left it at 59.1% and also lowered benign verifier task pass rate from 86.7% to 56.3%.

The lesson is not “never use skills.” The lesson is that skills are no longer just helpful instructions. In production, skills behave like middleware, with inputs, outputs, permissions, side effects, dependencies, and provenance. If you would not let one microservice silently claim that another service received payment authorization, do not let one skill silently claim that another skill received user approval.

Skills are becoming operational software

The industry is already moving in that direction. Anthropic’s Claude Code skills documentation describes skills as reusable procedures whose bodies load when used. It also notes that Claude Code skills follow the Agent Skills open standard and extend it with features such as invocation control, subagent execution, and dynamic context injection. Skills can live at enterprise, personal, project, nested, plugin, and synced locations. Some are prompt-based and let Claude orchestrate work with tools.

That turns repeated operational knowledge into shared infrastructure. A project can encode how to run a test environment; a security team can encode a review checklist; a support team can encode escalation rules.

But all of those benefits come with the same question: what is the skill allowed to assert? The security boundary is not the Markdown file. The security boundary is the claim that survives after the Markdown file has been read.

The dangerous artifact is the “helpful” one

Many agent defenses still focus on obviously hostile input: prompt injection, suspicious URLs, tool descriptions that ask the model to ignore policy, or unexpected user messages. Those are real problems. Skill chaining adds a quieter one.

The artifact may look helpful.

It may be a status note: “User approved final send.” It may be a checklist: “Permission confirmed.” It may be a generated handoff: “Proceed with production update.” It may be a memory entry, a task receipt, or a research summary. The downstream skill sees the artifact in a context where the agent has been trained to trust its own work products. The record is not entirely fake; it can contain real progress alongside the false approval. That makes it harder to filter with a blunt “ignore all generated files” rule.

This is why a simple instruction to “check the file against the original request” is not enough. The arXiv result suggests that prompt-only verification can reduce risk while also damaging legitimate task performance. Operators need controls that preserve useful skill composition without turning every handoff into a vague trust fall.

Treat skill handoffs like API handoffs

The practical fix is to make skill boundaries explicit.

First, separate observations from authorizations. A skill output can say, “I found three files that changed,” or “the user asked for a draft email.” It should not silently upgrade that observation into “the user approved sending the email.” Authorization claims need their own structure, source, timestamp, action identifier, and scope.

Second, type the handoff artifact. Instead of arbitrary prose, require a small schema: task id, observed facts, requested next action, evidence links, required approval state, and unsupported claims. The downstream skill should parse the schema, not infer authority from a paragraph.

Third, bind human approvals to action IDs. Approval should attach to the exact action being authorized: recipient, amount, file path, environment, command, or API call. If any material field changes, the approval is stale.

Fourth, use least privilege per skill. A research skill does not need permission to deploy. A formatting skill does not need permission to send email. If an upstream skill cannot access the dangerous tool, its ability to prepare a dangerous downstream action is reduced.

Fifth, review skill provenance. Skills from enterprise, personal, project, plugin, synced, or added-directory locations should not all be treated alike. The runtime should make that difference visible.

Guardrails belong at the tool boundary too

OpenAI’s Agents SDK guardrails documentation makes a useful architectural point: input guardrails run at the first agent in a chain, and output guardrails run at the final output. In workflows with managers, handoffs, or delegated specialists, the docs recommend tool guardrails when checks are needed before or after each function-tool call.

That maps directly to skill chains. If the risky moment is a downstream tool call that acts on a claim from an upstream skill, then first-input and final-output checks are too far away. The action gate needs to ask, immediately before the tool runs: what authority supports this call? Did the user approve this specific action? Did that approval come from the user, or from a skill-produced artifact? Does the artifact cite evidence, or is it asserting permission?

For low-risk workflows, a parallel guardrail may be acceptable. For side-effecting operations, blocking checks are often worth the latency. A cancelled model run is annoying. A tool call that already sent, deleted, purchased, deployed, or modified records is worse.

Add red-team fixtures for skill seams

The test suite should attack the boundary, not just the skill body.

Create fixtures where one skill writes a plausible but unauthorized claim and another skill is asked to proceed. Try variants: false approval in a checklist, task receipt, memory note, copied transcript, generated JSON object, and “summary of previous work.” The expected behavior is not paranoia about every artifact. The expected behavior is that the agent distinguishes evidence from authority.

A good test should fail if the downstream skill accepts “the previous skill said it was approved” as enough. It should pass only when the agent finds a real approval bound to the action or stops for human confirmation.

OWASP’s Agentic AI threats and mitigations frames agent systems as needing explicit threat analysis and security measures. Skill-chain testing is a natural part of that program. It is not a separate research curiosity; it is how reusable agent procedures enter the software supply chain.

The builder takeaway

Skills are good. Teams should keep using them. They are one of the cleanest ways to turn fragile prompt habits into repeatable operational practice.

But skills need boundaries.

Do not let a skill-produced note become permission. Do not let a generated receipt become evidence of consent. Do not let a downstream tool call inherit authority just because the upstream skill was useful. Treat each skill handoff as a small API boundary with typed claims, least privilege, provenance, and pre-action checks.

The next generation of agent reliability will not come from longer instructions alone. It will come from knowing exactly which claims can cross the seam between one skill and the next.