Capability security
for AI agents.

Your agents inherit the full authority of the credentials you hand them.

Without a capability layer, every prompt-injection vector turns into the worst thing your agent could do with those keys. These aren't hypotheticals — they're the four failure modes every team shipping agents has seen, or is about to.

Capframe puts all four at the agent's tool-call boundary — Find and Bind as Rust binaries, Guard as a pip-installable Python layer. Every call is decided by a policy you wrote, not a model you can't inspect.

Four stages. Microsecond capability checks. One findings schema. No model in the loop.

Map the surface, mint scoped authority, enforce every call against a policy you wrote, then export the receipt. The output of each stage is the input to the next — and every artifact is auditor-ready.

Standalone, or composed. Either way, three primitives — not three products.

Find and Bind ship as Rust crates with CLI subcommands; Guard ships as a Python package (pip install mcp-guardrails) — each in its own public GitHub repo. Adopt one at a time, or wire them together through the shared findings.v1 JSON Schema — the wire format Find emits, Bind scopes against, and Guard enforces.

$ capframe find ./mcp-server.toml
✓ mapped 14 tools across 2 mcp servers
⚠ 3 tools accept input without constraints (LLM01)
⚠ 1 tool has indirect-injection surface (LLM01, ATLAS T0051)
✓ surface diff: +2 tools vs last scan
→ ./capframe.findings.json

$ capframe bind --agent shopify-bot \
                --tools "order.read, refund.write" \
                --limit max_refund=50 --limit region=eu \
                --ttl 24h
✓ token minted: cf_tok_a91f4e…
  holder:    ed25519 / shopify-bot
  scope:     2 tools · max_refund≤50 · region=eu
  expires:   2026-05-18T08:14:00Z
  revoke:    capframe revoke cf_tok_a91f4e

$ capframe guard synth ./capframe.findings.json
✓ 14 rules generated across 3 categories
✓ policy → ./policy.yaml

$ capframe guard backtest ./policy.yaml
✓ 308-case corpus · TPR 1.00 / FPR 0.01
✓ deterministic · no model in the decision path

Bind isn't a claim. It's been attacked ten times — and every result is published.

The authority layer ships with a public purple-team corpus: a structured record of adversarial scenarios run against the token engine, written blue-first — the falsifiable security claim is committed before the attack runs. Every round ships a runnable PoC and a signed denial receipt as evidence. Clone it, run the tests, verify every number on this page without trusting a word of it.

$ npm run demo:llm-direct
→ task:  "send a $30 wire to acct 4471, then buy a USB-C cable"
→ scope: tool == "checkout.purchase"

  ⨯ wire.send          DENIED   out-of-scope
                       receipt cap_rcpt_3f9a…
  ✓ checkout.purchase  ALLOWED  in-scope
                       receipt cap_rcpt_7c12…

both decisions audit-logged · agent never reached the wire API

The runtime is the product. Everything else is paperwork.

Capframe is not a wrapper around an LLM, not a policy DSL transpiled to a model prompt, and not a managed service. It's a deterministic runtime with three primitives — tokens, policy, receipts — that sit inline at the boundary your agent already calls through.

The only artifact mapping all three agent-security frameworks at once.

Most tools tick one framework. Capframe was designed so a single run emits evidence aligned to OWASP LLM Top 10, NIST AI RMF, and MITRE ATLAS — the three frameworks regulated buyers (CISO, GRC, internal audit) actually ask about. capframe report exports the dossier as HTML or PDF — signed, timestamped, and ready to attach to an SOC2 / ISO 42001 / EU AI Act submission.

Eighty seconds, four commands, one auditor-ready report.

$ capframe find ./my-mcp-server.toml
✓ mapped 14 tools across 2 MCP servers
⚠ 3 tools accept input without constraints (LLM01)
⚠ 1 tool has indirect-injection surface (LLM01, ATLAS T0051)
→ findings written to ./capframe.findings.json

$ capframe bind --agent shopify-bot \
                --tools "order.read, refund.write" \
                --limit max_refund=50 --limit region=eu \
                --ttl 24h
✓ token minted: cf_tok_a91f4e…
  holder:    ed25519 / shopify-bot
  scope:     2 tools · max_refund≤50 · region=eu
  expires:   2026-05-18T08:14:00Z
  revoke:    capframe revoke cf_tok_a91f4e

$ capframe guard backtest ./policy.yaml
✓ 247/247 corpus cases pass
✓ 14 rules, 3 categories
✓ false-positive rate: 0.0%

$ capframe report --format html --out ./report.html
✓ report written
   OWASP LLM Top 10:  4/10 covered, 2 findings open
   NIST AI RMF:       Govern ✓  Map ✓  Measure ✓  Manage ✓
   MITRE ATLAS:       2 techniques flagged, 0 active exploits

Short on time? We'll audit your agents.

The same posture we run on our own tools and on 90+ public servers on the leaderboard, pointed at your stack. I map your agent's tool surface — MCP servers, or your existing OpenAI / Anthropic / LangChain tool definitions — and hand you a report you can act on in five business days.

Open source. Hosted when you need it.

What people ask before they install.

Q.01How is this different from an LLM-as-judge guardrail?

An LLM judge is another model you have to trust — and another attack surface. Capframe's Guard is a deterministic Python evaluator: the same input always yields the same allow/deny, with no model in the path. That means it's fuzzable, reproducible, and immune to the next jailbreak paper. LLM judges are useful for content classification; they are not safe to put inline at a tool-call boundary.

Q.02How is this different from prompt-injection scanners or red-team frameworks?

Scanners tell you about a vulnerability after the fact. Capframe enforces the boundary at the moment of the call — the agent never gets to make a refund it shouldn't, regardless of what the prompt said. Find covers the offline discovery surface; Guard is the runtime backstop the scanner ecosystem doesn't have.

Q.03Is the runtime fast enough for production?

Yes. Guard is a deterministic rule engine — no model inference and no network hop in the decision path, so a decision is a pure function of (policy, call). (Raw capability verification, in the Rust Bind layer, runs in single-digit microseconds.) Drop Guard inline at the tool-call boundary and measure it on your own traffic.

Q.04Does my agent data leave my environment?

No. It's local-first — Find, Bind, Guard, and Report all run on your laptop, your CI, or your inference host (Find and Bind as Rust binaries, Guard as a pip-installable Python layer). The Pro / Enterprise hosted control plane is opt-in and stores only the metadata you choose to sync.

Q.05Does this only work with MCP?

Today, yes — Capframe is built around the Model Context Protocol. That covers Claude Desktop, Cursor, Continue, Cline, LangGraph via the MCP bridge, and most agentic Rust/Python frameworks. Native adapters for OpenAI function calling and Anthropic tool use are on the roadmap; the policy file stays the same.

Q.06Why three separate modules?

Different teams adopt them at different speeds. Security teams typically start with Find to baseline their agent surface. AI engineers usually start with Guard because it solves the immediate runtime problem. The capability-token layer (Bind) is for teams ready to commit to a permission model. The findings.v1 schema ties them together when you're ready.

Q.07Why open source?

Security infrastructure you can't read isn't trustworthy — and AI-agent enforcement is too new a category to be locked behind a closed binary. The code your boundary depends on should be inspectable, fuzzable, and forkable. MIT licensed, every line.

Q.08What does the auditor actually receive?

An HTML or PDF report (capframe report) with: the findings table mapped to OWASP LLM Top 10 and MITRE ATLAS techniques, the active policy file with its hash, the signed receipt count by verdict, and the NIST AI RMF function coverage matrix. Timestamped and signature-verifiable end to end.