Before You Publish an Agent Skill, Run a Safety Review

Agent skills are becoming the new software packages. That makes the security question less about whether the prompt sounds good and more about whether the skill has an inspectable operating contract.

A reusable skill stops being “just a prompt” once it can call tools, read files, browse sites, touch SaaS apps, message people, write memory, or trigger workflows. At that point, the review target is not only the text. It is the authority around the text.

Before a team publishes, sells, installs, or delegates an agent skill, it should run a safety review.

The wrong review: vibe-checking the instructions

Most skill reviews start with the obvious question:

“Does this instruction look reasonable?”

That is useful, but incomplete. A perfectly normal-looking skill can still be unsafe if it has broad permissions, unclear inputs, hidden side effects, no memory policy, no stop rules, and no receipt after execution.

The real risk surface

An agent skill has at least six surfaces that need review:

1. Inputs: What data does the skill require, and what data should never be provided?
2. Tools: Which tools may it use, at what scope, and under what approval rules?
3. State: What files, SaaS records, browser sessions, tickets, or external systems can it change?
4. Memory: What can it read, propose, promote, expire, or never store?
5. Failure behavior: When does it stop, draft, escalate, ask, or refuse?
6. Receipts: What evidence proves what happened after the run?

If those surfaces are not explicit, another agent cannot safely decide whether to run the skill. Neither can a human buyer.

Memory is part of the blast radius

Portable skills get especially risky around memory. A skill may run in one environment where memory is private and temporary, then get reused in another where memory is shared, durable, or consumed by downstream agents.

If the skill can turn a temporary observation into a durable fact, it needs a memory-write policy. Otherwise one bad run can become future operating truth.

What a safety review should check

A useful review does not need to be huge. It needs to answer the questions that predict unsafe reuse:

• What job does the skill do, and what jobs are explicitly out of scope?
• Which inputs are required, optional, forbidden, or privacy-sensitive?
• Which tools are read-only, reversible, compensatable, or irreversible?
• Which actions require human approval before execution?
• What output artifact or schema is required?
• What receipt must include sources, timestamps, actions, skipped areas, and confidence notes?
• What memory updates are allowed, proposed-only, or forbidden?
• Which eval cases prove the skill respects permissions and fails safely?

Safe failure is the product

A production-ready skill is not a skill that always succeeds. It is a skill that fails in inspectable, recoverable ways.

For real workflows, safe failure means the skill can deny ambiguous requests, draft before external action, queue an exception instead of improvising, avoid silent memory mutation, preserve evidence, and surface the exact boundary it hit.

That behavior is not “less autonomous.” It is how autonomy becomes trustworthy enough to reuse.

The marketplace implication

Agent marketplaces will not scale on demos alone. Buyers need to compare skills like operational components: interface, permissions, side effects, evals, receipts, version history, and failure behavior.

The creators who win will make trust inspectable. They will ship a contract with the skill, not just a clever instruction file.