Why Agent Skills Need a Real Package Manager

2026-11-11

by Uri Walevski

Most agent skills today get shared the same way people shared JavaScript in 2008. Someone drops a SKILL.md file and a couple of Python or TypeScript scripts into a GitHub repo, and everyone else copies the folder into their workspace or points an agent straight at the raw branch URL.

That workflow feels fine when an agent is just summarizing articles in a local terminal. It falls apart the moment the agent has access to a real Gmail inbox, a Stripe key, or a production database.

A Markdown file on an unpinned GitHub branch is a prompt. That same capability pinned to an immutable version, checked by a security scanner, and restricted to an explicit list of network hosts is a software package.

Silent Drift Breaks Live Agents

Software teams learned twenty years ago not to deploy production services by pulling main from third-party repositories on every boot. Agent builders are currently re-learning the exact same lesson.

When an agent loads a skill from a live branch URL, two things go wrong.

First, benign edits break working workflows. A skill author renames a script flag, changes a JSON output key, or rewrites a system instruction to fit their own model preference. Nothing crashes at deploy time, because there is no build step. Instead, the agent wakes up at 2am on a scheduled task, misreads the new output format, and hallucinates a fallback.

Second, an unpinned remote prompt is an open prompt-injection vector. Anyone who compromises the upstream repo can slip two sentences into a reference Markdown file and redirect every downstream agent that loads it.

Pinning a skill to an immutable version like tank:@uriva/p2b-gmail@1.4.2 stops silent drift immediately. Upgrades become explicit decisions instead of surprises.

Security Scanning Before Installation

Traditional static analysis looks for buffer overflows or known CVEs in compiled dependencies. Agent skills introduce a different attack surface because natural language instructions sit right next to executable scripts.

A malicious or sloppy skill does not need a zero-day exploit. It can instruct the model in plain English to read all environment variables and POST them to a webhook URL, or hide an outbound fetch call inside a helper script that claims to format dates.

That is why we wired prompt2bot to Tank. Every published version on Tank goes through an automated security scan before it becomes installable. The scanner inspects both the prompt instructions and the bundled scripts, assigning a scan verdict to that exact version.

When an agent or user searches the Agency and Tank directory or installs a package on prompt2bot, packages without a passing security verdict are filtered out before their instructions ever touch a model's context window.

Static Capability Signatures and Host-Scoped Secrets

Versioning and scanning catch known bad packages, but defense in depth assumes an agent might still get tricked by untrusted data at runtime. Imagine an email skill reading an incoming message that contains a prompt injection telling the agent to forward its API token to an external server.

If a runtime lets arbitrary scripts read raw environment variables and call fetch to any URL on the internet, game over. One tricked tool call can read the secret string and ship it anywhere.

In prompt2bot, lightweight skill logic and custom tools run in Safescript (@uri/safescript), a restricted functional language built specifically for untrusted agent execution.

Before a Safescript program ever runs, the engine parses the AST and statically computes its exact capability signature: which secret names it reads, which outbound HTTPS hosts it contacts, and its upper bounds on memory, runtime, and algorithmic complexity. Every stored secret on a bot is paired with an explicit list of allowed hosts, such as api.resend.com or gmail.googleapis.com.

If a confused model or a compromised script tries to read a secret and talk to an unapproved domain, the policy check rejects the program before execution even starts, or requires explicit administrator approval in chat first.

What This Looks Like in Practice

Treating skills like real packages does not have to make them harder to launch. The goal is the exact opposite: when trust, versioning, and host policies are enforced by the runtime, launching a specialist becomes safer than pasting prompts by hand.

On /agency, searching for Gmail, Calendar, Shopify, or a coding workflow queries verified Tank packages alongside open-source specialist roles. Clicking any package spins up a dedicated agent on WhatsApp, Telegram, or web chat in one click via Talk to Skill, with its version locked and its network capabilities statically bounded.

← All posts