Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.
RBA RBA Skills

Security & guardrails

The standards pages tell you how each artifact is shaped. This section tells you how it’s secured — the four pillars every catalog contribution is measured against, the threats they exist to mitigate, and the validator rules that enforce the deterministic parts.

If you’re an external reader (RBA client, security reviewer, peer agency), this is the page that explains the catalog’s security posture in 10 minutes.

If you’re a contributor, you don’t need to memorize every threat to ship a safe artifact. Follow the per-artifact standards page (the controls are baked in) and the Secure-by-default checklist. This page is the why.

The four pillars

Section titled “The four pillars”

1. Least-privilege permissions

Section titled “1. Least-privilege permissions”

Every artifact declares exactly the tools it needs and nothing more.

  • Skills declare allowed-tools explicitly. Omitting it inherits everything — the validator warns; reviewers treat it as a fail.
  • Bash is never bare. Use Bash(specific-command *) patterns. Bare Bash is hard-blocked in CI.
  • WebFetch is domain-scoped. Use WebFetch(domain:example.com). Bare WebFetch is only justified for genuinely open-ended skills — the research plugin is the canonical example, and new ones get pushback.
  • Agents never inherit-all. The tools field is set explicitly. Anthropic allows omitting it; RBA forbids it.
  • MCP servers default-deny against a single scoped namespace. Production writes require an explicit confirmation env var. Secrets via env vars or keychain, never embedded.

A permission a skill doesn’t need is a permission an attacker (or a prompt-injection vector) can exercise. The audit cost of declaring tools narrowly is paid once; the cost of an over-permissioned skill compounds with every install.

2. Supply chain

Section titled “2. Supply chain”

Nothing reaches plugins/ (or the standalone roots) without passing review against the rules above. The mechanics:

  • npm run validate runs locally and in CI on every PR — astro sync + scripts/validate-bundles.mjs. The script enforces the deterministic rules (bare Bash, slug = name, SKILL.md size, credential paths, computer_use justifications).
  • Dependabot opens weekly PRs for npm and GitHub Actions dependency updates so the site and CI tooling don’t drift.
  • gitleaks scans every PR diff for accidentally-committed secrets.
  • Plugin bundles must be complete (manifest + rba-meta.json + README + at least one artifact). Half-bundles are rejected.
  • .claude-plugin/marketplace.json is regenerated from plugins/ at build time, not hand-edited. There is no path to add a plugin to the marketplace without it appearing under plugins/ first.

Real incidents in the last 12 months have shown that cloning untrusted Claude Code repos can leak credentials before any trust dialog appears. The catalog can’t prevent users from installing plugins from other marketplaces, but it can guarantee that anything inside this marketplace has been reviewed against the rules above.

3. Prompt injection

Section titled “3. Prompt injection”

Two distinct threats, two distinct controls.

  • Injection via skill content (catalog-side) — a poisoned SKILL.md or resource that causes Claude to take unauthorized actions when followed. Mitigated by code review: every skill is read by a human reviewer against the standards page before merge. Tool-allowlist scope limits the blast radius if a pattern slips through — a skill restricted to Read, Grep can’t write or shell out, even if its prompt tells Claude to.
  • Injection via external content at runtime (user-side) — a document or webpage the user feeds the skill that contains hidden instructions. This is what the Prompt security training module covers (direct / indirect / zero-click). The catalog can teach the pattern; it can’t enforce safe runtime use.

For both, see Threat model T3 for the controls and residual risk.

4. Audit trail

Section titled “4. Audit trail”

Claude Code captures session JSONL logs at ~/.claude/projects/<repo>/*.jsonl by default — tool calls, file reads and writes, prompts, and responses. That local log is the baseline audit trail every Claude Code user already has.

For enterprise deployments that need centralized forwarding (SIEM ingestion, retention policy, tamper detection), the deployment side lives outside this repo. The catalog references it from threat-model entries that depend on it, but does not ship the runtime infrastructure here.

A separate gap to know about: Anthropic’s Compliance API and Audit Logs cover Claude Code, but as of this writing do not cover Cowork. Any RBA team relying on Cowork for sensitive workflows should treat that as a deployment-time concern; the catalog’s audit trail covers the Claude Code surface only.

Where to go next

Section titled “Where to go next”