Show HN: Capframe – capability tokens for AI agent tool calls

by euan21 • 2 months ago

1 2 2 months ago

euan21• 2 months ago

Hi HN — I just shipped v0.2 of Capframe, an open-source toolkit or AI agentsthat call tools.The wedge I'm trying to fill: agents calling MCP servers / OpenAI functions / LangGraph nodes have no principled authority model at the tool-call boundary. Existing approaches either (a) wrap an LLM around the allow/deny decision (un-auditable), or (b) lean on prompt-time guardrails (inherits prompt injection's "best-effort" guarantee). Capframe takes the opposite stance — deterministic, capability-based, no LLM in the decision path.

  Three modules, each its own repo, glued by a single Rust
  dispatcher CLI:

  - Find (mcp-recon)  — discovers an MCP server's tool surface,
  emits a
    structured findings document. Six deterministic rules today
  (R1
    unconstrained string input, R2 missing auth on side-effecting
  tools,
    R3 side-effect/name mismatch, R4 unbounded numeric on
  money-ish params,
    R5 money in description but no money side-effect, R6
  indirect-injection
    surface from external-fetch tools).
  - Bind (capnagent)  — mints macaroon-style capability tokens.
  Ed25519
    holder-of-key, attenuable by holders without contacting the
  issuer,
    revocable, signed denial receipts (HMAC-SHA256).
  - Guard (mcp-guard) — deterministic policy evaluator with three
  modes
    (synthesize / evaluate / backtest). Pure-stdlib Python,
  microsecond
    decision path.

  The wire format binding them is a public JSON Schema (Draft
  2020-12,
  additionalProperties:false, regex-validated OWASP LLM / NIST AI
  RMF / MITRE
  ATLAS IDs): https://capframe.ai/schema . I'd like this to become
   the
  SARIF-equivalent for AI agent security — happy to take
  suggestions and PRs.

  Install: `curl -fsSL capframe.ai/install | sh` —
  sha256-verified, native
  binaries on GitHub Releases for linux/macos/windows ×
  x86_64/aarch64.
  Source: https://github.com/capframe/capframe (MIT).

  A "Pro" tier on the landing page is a waitlist, not a product —
  ignore it
  for now.

  Three things I'd love feedback on:

  1. The schema shape. If you've shipped or reviewed anything in
  this space,
     does the findings.v1 envelope work, or am I missing fields?

  2. The Find / Bind / Guard decomposition. Is that how you'd want
   to adopt
     this incrementally in an existing agent stack, or are the
  lines drawn
     wrong?

  3. The caveat DSL (`tool in [...]`, `max_refund <= 50`, `region
  == "eu"`).
     Reasonable on top of macaroons, or reinventing badly?

  Happy to answer anything.

jonnyasmar• 2 months ago

The "no LLM in the decision path" framing is exactly the cut I'd want here. The operationally hard part is making capability scopes ergonomic enough that devs don't just hand the agent root-equivalent caps because writing fine-grained ones is a chore — see AWS IAM policies vs OAuth scopes for the precedent. Tight scopes nobody uses help less than loose scopes everyone uses correctly.

Two questions on the threat model:

1. Can the LLM influence the capability presented to the tool? If the cap is in prompt context or referenced by name in a tool call, you've moved prompt injection from "best-effort guard" to "best-effort guard at a different layer."

2. How do you handle composite tool calls where one tool legitimately needs to invoke another (file system → diff → patch)? The capability has to flow but not amplify.

Show HN: Capframe – capability tokens for AI agent tool calls

Related Stories