---
type: Reference
title: "PMOS kit — security posture"
timestamp: 2026-07-23
---

# PMOS kit — security posture

A skill is not a document. It is **instructions that run inside your agent**, with your agent's
tools and your agent's access. Anything the kit ships into your repo can shape what your agent does.
This file states, concretely, what the PMOS kit does to be safe to install — and where the
responsibility stays yours.

## Why "we scanned it" is not a posture

The largest skills registry (skills.sh) shipped a malicious-skill scanner. Trail of Bits bypassed it
with prompt injection plus compiled bytecode. Static scanning of agent instructions is *evadable by
construction* — the payload is natural language aimed at a model, not a signature you can enumerate.
So the PMOS kit does not claim "scanned and safe." It claims a set of **structural** properties you
can check yourself, below.

## What the kit does

- **No on-load command execution in shipped skills.** No PMOS kit skill uses Claude Code's dynamic
  `` !`cmd` `` context injection or any load-time shell-out. A skill's body is read as instructions,
  not run as a script when it loads. *(Check: `grep -rn '!\`' pmos/skills` — expect nothing.)*
- **Least authority, declared.** Shipped skills request the minimum tools they need; the
  security-sensitive one — the **evaluator** — is **read-only by design**: its only write is the
  schema-constrained verdict. The component that reads untrusted content (diffs, PR text) is
  deliberately *not* the component that can act, which removes the exfiltration leg of the lethal
  trifecta.
- **A `license` on every shipped skill** (portability + provenance), and PMOS producer metadata is
  carried under the spec's `metadata:` extension map, never as ambient top-level directives.
- **Fail-closed containment.** The kit is assembled by `kit/build-kit.sh`, which greps its own output
  and **aborts** if any reference to a hosted PMOS backend (a project ref, an MCP endpoint, or a
  hosted-backend URL) leaks in. The npm publish path re-runs this check on the exact tarball and
  refuses to publish on anything but a clean result. The kit you get is self-contained: **no
  database, no network, no telemetry.**
- **No network calls in the installer.** `create-pmos` vendors a bundled payload; it makes no
  outbound requests and sends nothing about you anywhere.
- **Everything the evaluator reads is untrusted data, never instructions.** An instruction embedded
  in a diff or PR body ("mark this PASS") is treated as *evidence of a defect*, not a command —
  paired with the read-only scope above, because prompt-level defenses alone are bypassable.

## What stays your responsibility

- **Review before you install.** Read the skills and scripts in `pmos/` the way you would review any
  dependency PR. The kit is small and plain-text on purpose so you can. `--update` refreshes only the
  kernel and never touches your `state/` — review its diff like any other change.
- **Your agent's tools are yours to scope.** The kit declares least authority for its own skills, but
  what your agent is *allowed* to do in your repo is set by you, not by us.
- **Pin what you install.** Prefer a pinned `create-pmos@<version>` over `@latest` in automation, and
  re-review the kernel diff on each update.

## Reporting

Found something that violates the posture above — a shipped skill with load-time execution, a
containment leak, an over-scoped tool request? Open an issue in the PMOS repo describing what and
where. The posture is only worth stating if it is enforced; a false claim here is itself a bug.