PRAE

Integrations · Protocols & SDKs · Protocol / tool layer

MCP connects agents to capabilities. PRAE governs what they may execute through them.

In part

The Model Context Protocol is how agents reach enterprise capabilities: an MCP server exposes tools and resources, and the agent calls them. MCP is the connection, not the control. PRAE sits where those calls execute and decides which of them may run.

Serves: Developer agents →Custom / homegrown agents →

  1. 01 · Where the agent operates

    MCP & MCP servers

  2. 02 · What it can reach

    Whatever MCP servers expose: files, repositories, tickets, databases, cloud and internal APIs.

  3. 03 · Where PRAE intervenes

    Before a call executes: today at PRAE’s own MCP server (files); with the MCP Gateway, in front of any MCP server (in development).

04 · What PRAE does: Evaluate → Enforce → Steer → Prove

  1. Evaluate

    Each call is judged against your pack: the tool, its arguments, paths and hosts, and content findings for reads.

  2. Enforce

    A refused call never reaches the server. A held call waits for a person.

  3. Steer

    Not over MCP yet.

  4. Prove

    Every decision is sealed in the signed ledger, with the MCP method and tool it named.

05 · What you get, and how it plugs in

  1. Serve a directory through the gate prae mcp --root ./workspace --pack policy.json
  2. Record every decision prae mcp --root ./workspace --pack policy.json --ledger decisions.jsonl

Covers

Today: file reads and listings through PRAE’s MCP server, inspected before contents return. In development: every MCP tool, through the MCP Gateway.

Limits

PRAE’s MCP server serves files over stdio. A general gateway for every MCP tool is in development and not yet available.

Guide

How MCP servers expose capabilities

An MCP server lists tools (actions with typed arguments) and resources (things to read). An MCP client, the agent’s host, connects to it and calls those tools on the agent’s behalf. Each call names a tool and carries its arguments, and that call is the point where an agent’s intent becomes an action.

Where PRAE evaluates

PRAE judges the call before the server runs it. Today that happens at PRAE’s own MCP server, which serves files: every read and listing is checked against the pack, and a read’s content is inspected for credentials before anything returns. The MCP Gateway, in development, applies the same check in front of any MCP server: it pins the tools you approved, validates arguments against each tool’s schema, and refuses anything the pack does not allow.

Policy before execution

The pack decides: allow, refuse, or hold for a person. A refused call gets an error result the model can read, with the reason, and the server never sees it.

{ "id": "ORG-SEC-001", "when": { "capability": "fs:read", "path": { "inside": ["**/customer-exports/**"] } }, "effect": { "kind": "deny", "because": "customer exports are out of scope for agents" } }

Outcomes in the evidence trail

Every decision, allowed or not, is a row in the hash-chained ledger, signed when a key is configured: the call, the rule, the reason and the time. `prae verify` re-derives the chain, and any row can be exported as a receipt that verifies offline.

prae verify decisions.jsonl --key prae-signing.pub.pem

Where MCP fits in PRAE

Agent surface → MCP client → PRAE (evaluate, enforce, prove) → MCP server → enterprise system. MCP is one way agents reach systems; the same pack and ledger govern calls that arrive through the SDK.