● OSS LOCAL · APACHE-2.0 · CLOUD DEMAND VALIDATION

Let your agents act.
You keep the veto.

Gatekeeper sits between your AI agent and the real world — shell, filesystem, HTTP, memory, LLM calls. Every action is evaluated against policy: allow, require human approval, or deny. Every decision — and every dollar — is logged. Works with Claude, GPT, local LLMs, and MCP servers.

$ npx -y @runestone-labs/gatekeeper-mcp

45 seconds · what Gatekeeper enables, in production

YOUR AGENT
LLM
Claude · GPT · Llama · MCP
GATEKEEPER
policy · approval · audit
on your hardware
TOOLS
shell · files · HTTP · memory · LLM
the real world

Three decisions, not two

Binary allow-or-deny is why security tools get disabled. Any rule strict enough to catch real misuse also blocks legitimate work. Gatekeeper's third option is the one developers actually leave on.

● ALLOW

Fast-path the safe 90%.

Your agent's normal reads, scoped writes, and allowlisted HTTP fly through without interruption. Sub-millisecond policy evaluation.

◐ APPROVE

Pause for the risky 10%.

Exact actions stay local. Signed local approvals ship today. A digest-bound, outbound-only team inbox is the planned Cloud beta scope—not a generally available feature.

✕ DENY

Hard-block the obvious bad.

Dangerous shell patterns, path traversal, SSRF, disallowed extensions — rejected before the tool is ever touched. The agent can't retry its way through.

Built for the actual threat model

Semantic tool rules, not regex.

Shell policy understands allowed_cwd_prefixes and dangerous-pattern lists. File policy enforces allowed_paths + denied extensions. HTTP gets DNS & IP allowlists plus SSRF protection.

tools:
  shell.exec:
    allowed_cwd_prefixes: ["/workspace/"]
    deny_patterns: ["rm -rf", ":(){ :|:& };:"]
    decision: approve   # human sign-off required

Append-only audit log.

Every decision — allow, deny, approval requested, approval consumed, executed — written as JSONL with actor, args (secrets redacted), risk flags, and policy hash. Daily file by default. Optional Postgres sink.

{"ts":"2026-04-22T14:03:11Z",
 "actor":"agent:finance-sync",
 "tool":"http.request",
 "decision":"approved",
 "risk":["external-api"],
 "policy_hash":"sha256:a3f9..."}

Role-based principals.

Tag agents with roles (local_dev, prod, research_readonly). Policies fork on role, so the same agent binary can be tightly caged in production and loose on your laptop — without branching the agent code.

Sensitive-boundary protection.

17 built-in rules catch an agent crossing into the macOS Keychain, SSH keys, cloud credentials, browser profiles, package-registry tokens, or .env files — even when its stated intent is benign. Override or extend any rule by id in YAML.

Framework-agnostic.

HTTP in, HTTP out. Works with the Anthropic Claude SDK, OpenAI SDK, LangChain, LlamaIndex, custom agents, and MCP servers. The repo ships a TypeScript client (@runestone-labs/gatekeeper-client), a stdio MCP server for Claude Desktop / Claude Code / Cursor, and a Claude Code hook.

USD budgets & cost audit.

Route model calls through the optional Anthropic proxy and each one is metered with real parsed token usage (cache-tier aware) — model, tokens, and USD stamped onto the audit row. /usage + /budget show actual dollars per actor, per tool, per day. Caps are per-actor (rolling guardrail) or per-run — the unit where recursive burn compounds — and deny before the upstream call. Start in soft mode, observe, then enforce at ~2× p95.

budgets:
  - name: finance-sync daily cap
    match: { actor_name: "agent:finance-sync" }
    window: day
    max_usd: 2.00        # exceeded → BUDGET_EXCEEDED
  - name: research per-run burn cap
    match: { actor_role: "research" }
    scope: run           # caps a single agentic run
    window: day
    max_usd: 5.00
    mode: soft           # observe first, then enforce

Memory, with boundaries.

Optional knowledge-graph layer: entities, episodes, relationships. Agents request memory operations just like any other tool — upserts and queries flow through the same policy engine, so you can scope which agent writes what, and audit every change.

Where Gatekeeper fits

IS
  • → A runtime enforcement boundary between agent and tool.
  • Local authority. Exact actions, budgets, execution, and receipts stay on your disk.
  • Auditable. Hash-chained JSONL, bound approvals, and independent verification.
  • Semantic. Understands shells, files, HTTP — not abstract ABAC.
IS NOT
  • → Prompt-injection mitigation. Guardrails AI does that; different layer.
  • → An LLM gateway or observability platform. Portkey and Langfuse do those.
  • → A replacement for OS-level sandboxing. Pair with it.
  • → Magic. We document what we catch and what we don't.

vs. the alternatives

Capability Gatekeeper MCP server alone DIY policy code
Allow / approve / deny tri-state decision Yes Allow / deny only If you build it
Append-only audit log JSONL out of the box No If you build it
Semantic rules (shell / fs / http / llm) Built in Tool-shape only If you build it
Per-principal cost budgets Built in No If you build it
Local enforcement + planned team coordination Local now · Cloud validating Yes Yes
Framework-agnostic client Any HTTP MCP-only Whatever you wrote
License Apache-2.0 Varies by server Yours

MCP servers expose tools; they don't decide whether the call should happen. Gatekeeper sits in front of any of them — including MCP servers you already run.

Common questions

What is Runestone Gatekeeper?

Runestone Gatekeeper is a self-hosted policy, approval, budget, and audit layer for AI agent tool calls. The agent calls Gatekeeper instead of directly calling shell, filesystem, HTTP, memory, or LLM tools.

Is Gatekeeper an MCP server?

Gatekeeper can sit in front of MCP servers, but it is not limited to MCP. It is an HTTP enforcement boundary that can protect MCP tools, SDK-based agents, custom agents, and local automation.

Does Gatekeeper stop prompt injection?

Gatekeeper is not a prompt-injection detector. It enforces runtime policy after the model asks to take an action, so risky shell, file, HTTP, memory, or model calls can be allowed, denied, or held for approval.

Where does Gatekeeper run?

Enforcement, exact actions, budgets, and forensic receipts stay local. A possible Cloud team layer is in demand validation; it is not generally available. If built, it will coordinate approvals and redacted status without receiving prompts, results, raw tool arguments, file contents, or HTTP bodies and headers.

What does Gatekeeper log?

Gatekeeper writes append-only audit events for requests, policy decisions, approvals, denials, executions, errors, risk flags, policy hashes, and LLM spend when budget tracking is enabled.

Cloud beta · demand validation

Is shared authority worth building for your team?

The local OSS boundary works today. We are validating a planned $49/month Team layer for five instances and five members. No payment is collected, and Cloud development stays frozen until qualified demand crosses the public gate.

Planned device onboarding

Browser authorization would create a scoped, hashed, revocable instance token.

Planned team approval inbox

Named approvers would decide the exact digest and expiry produced by the local daemon.

Planned policy versions

Validate, save a draft, then explicitly publish; instances retain last-known-good.

Planned deterministic reports

Budget thresholds, policy drift, new tools, expiry, denies, sensitive boundaries, and SSRF blocks.

Ready to put a boundary in front of your agents?

Install the open-source MCP boundary today. If a second operator or unattended run makes shared authority necessary, add a qualified signal for the planned Cloud beta.