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 file read is judged against your pack: its path, and content findings for what it would return.

  2. Enforce

    A refused read returns nothing. A rule that would hold a call is refused instead: this server has no channel to a person.

  3. Steer

    Not over MCP yet.

  4. Prove

    With --ledger, every read is sealed in a hash-chained ledger with the tool it named. This server does not sign its rows.

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 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 is checked against the pack, and a read’s content is inspected for credentials before anything returns; listings are confined to the root but not judged. 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 or refuse. A rule that would hold the call for a person is refused at PRAE’s MCP server, which has no channel to a person. A refused call gets an error result the model can read, with the reason.

{ "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

With --ledger, every read, allowed or not, is a row in the hash-chained ledger: the call, the rule, the reason and the time. PRAE’s MCP server does not sign its rows. `prae verify` re-derives the chain, and any row can be exported as a signed receipt that verifies offline.

prae verify decisions.jsonl

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.