PRAE

Agents · Custom / homegrown agents

Secure every custom agent — at the execution boundary.

Agents your engineering team built into its own applications get the same control as any other: PRAE decides what the agent can actually execute — which tools and APIs, with which arguments, paths, hosts, commands and budgets — before the action runs, whoever wrote the agent and however it plans.

PRAE governs agents built into your applications — without a model or a proxy in the execution path.

  1. 01 · Application

    Your product, with an agent built into it: a support assistant, a billing copilot, an operations bot.

  2. 02 · Agent runtime

    Your framework and your model, unchanged. The agent plans and proposes tool and API calls as it does today.

  3. 03 · PRAE governance boundary

    prae-gate’s judge(), called from your tool loop before each call runs: allow, refuse, or hold for a person. Deterministic rules from your pack.

  4. 04 · Tools · APIs · infrastructure

    The call runs only if the verdict allows it. A refused call never reaches your API; a held one waits.

  5. 05 · Evidence

    Every decision appended to a hash-chained ledger with the rule that made it, signed when you give it a key.

Govern → Enforce → Prove

Shipping · execution control

  1. 01

    Govern

    Your policy as data: one pack of rules over tools, capabilities, paths, hosts, commands and budgets, testable with prae test and rolled out in shadow mode before it blocks anything.

  2. 02

    Enforce

    Each tool call judged before it executes — allowed, refused, or held for a human — whether it comes from a built-in tool, an MCP server or your own.

  3. 03

    Prove

    Every decision sealed with the clause that produced it, so what your agent did, and why it was allowed, is on the record.

Where it plugs in today: agents in Node or TypeScript that call the gate from their own tool loop (the SDK), and file access through PRAE’s MCP server. Other runtimes and cloud agent services are on the roadmap. PRAE does not scan repositories or discover agents.

Node / TypeScript →MCP & MCP servers →AI compliance & audit readiness →

For DevOps & engineering

Where does PRAE sit?
At the agent’s execution boundary: inside your service, between the agent choosing a tool call and the call running.
What does it control?
Tool and API actions before they execute — which tools, which arguments, paths, hosts, commands and budgets — allowed, refused or held for a person.
How do I integrate it?
npm install prae-gate, load your pack, and call judge() at the one place your loop runs tools. No sidecar, no proxy, no extra model. Node and TypeScript today.
import { judge, Ledger, parsePack } from 'prae-gate'

// The one place your agent's loop runs a tool:
async function runTool(name, args) {
  const { decision, record } = judge(pack, { name, arguments: args })
  ledger.append(record) // the evidence
  if (decision.kind === 'deny') return { refused: decision.reason }
  // ask: hold the call for a person
  if (decision.kind === 'ask') return { held: decision.reason }
  return tools[name](args) // runs only when allowed
}

How it differs

  • Not a proxy

    Nothing sits between your agent and your APIs on the network. The gate is a function your service calls, in process.

  • No model in the path

    Verdicts come from your pack’s rules: the same call gets the same answer, every time. No second LLM judges the first.

  • Not a new framework

    Keep your agent framework, prompts and model. You add one call before each tool runs, and honour its verdict.