PRAE
Agentic Control Plane

PRAE The agent is autonomous. The execution isn’t.

PRAE governs protected agent actions at runtime. At supported execution boundaries it evaluates each governed call against your policy before it runs — allow, hold for a person, or deny — and produces verifiable evidence of every decision and intervention.

Try the playground Request access

Built your own agent? PRAE governs agents built into your applications — without a model or a proxy in the execution path. Custom agents →

  • ◆ Sees each tool and API call your agent proposes
  • ◆ Judges it at the execution boundary, before it runs
  • ◆ Enforces deterministic policy: allow, refuse, hold
  • ◆ Mounts in your own tool loop — keep your framework

AGENTS.md tells the agent. PRAE controls the agent. Keep the instruction files you already have — PRAE reads them, proposes the enforceable part as rules you review, and on the supported harness profile seals what the agent was actually told.

01Evaluate Allow·Hold·Deny 03Verify 04Steer↻

Foundation Models · Agent Frameworks · PRAE — Control Plane · Enterprise Systems · Observability

The architectural problem

Enterprise agents can execute. They cannot reliably carry the enterprise with them.

The result: agents operate against an incomplete model of the enterprise — and knowledge never compounds.

Fragmented

Context is scattered

Enterprise knowledge lives across systems, schemas, repositories, policies, and people. Agents typically see only a partial slice of it.

Ephemeral

Execution disappears

When an agent solves a hard workflow or surfaces an edge case, the context behind that success rarely outlives the task.

Repeated

Nothing compounds

The next execution rebuilds the same retrieval, state, rules, and memory from scratch. Effort duplicates. Failures repeat.

Agentic artifact discovery

Preview

Know what enters your agent fleet. Control what executes.

Discover agents, MCP servers, skills, models, binaries, and extensions across your environment. Connect inventory and risk context to the runtime controls that determine what agents can actually do.

Fleet-wide discovery is on the roadmap. What PRAE discovers today is listed in this section, each at its real status, and the catalog below is sample data.

Get a Demo Explore Runtime Controls

What PRAE discovers today

  • Instruction files in a workspace Shipping

    Every AGENTS.md, CLAUDE.md, .cursorrules and .windsurfrules an agent would be given, found by walking up from the working directory to the project root and listed with what each says, file by file and line by line.

    $ prae instructions

  • Skills in a workspace In development

    Skills found in a workspace and the user’s home, each with an integrity hash and its declared capabilities held against what it is observed doing. Runs in PRAE’s demo today, not yet in the CLI.

  • Fleet-wide artifact inventory On the roadmap

    Agents, MCP servers, models, binaries, browser and IDE extensions across an environment. Not built — the catalog below is sample data.

PRAE / Artifact catalog
Sample data · illustrative

What an inventory of an agent environment would list: each artifact, who published it, what it can reach, and where it was found.

  • support-triage-agent Custom agent

    Publisher: Acme platform team

    Reads support tickets, drafts replies and issues refunds below a threshold.

    • ticketing API
    • payments API
    Illustrative risk: High Sample · Internal repository
  • release-notes-bot Scheduled agent

    Publisher: Acme developer experience

    Summarises merged changes into release notes once a week.

    • repository read
    Illustrative risk: Low Sample · CI configuration
  • coding agent session Developer agent

    Publisher: Engineer workstation

    A coding agent running with a developer’s files, shell and network.

    • files
    • shell
    • network
    Illustrative risk: High Sample · Developer workstation

Sample data: names and publishers are invented, risk levels are illustrative rather than assessments, and nothing here was observed in any environment.

Discovery

Knowing an artifact exists

An inventory answers what is installed, who published it, and what it says it can reach. It does not stop anything from running.

Runtime control

Governing what an agent executes

Where PRAE is in the execution path, each call an agent proposes is judged against your policy before it runs — whether or not the artifact behind it was ever catalogued.

  1. Allow Shipping An in-policy call runs.
  2. Hold In part A sensitive call waits for a human to approve that exact action, where the integration supports holds.
  3. Deny Shipping An out-of-policy call is refused before it runs.
  4. Verify Shipping Every decision is sealed in a hash-chained ledger and exports as a signed receipt.
  5. Steer In development A signed constraint reaches running agents and is adopted mid-session. Learn more →

Cataloguing or risk-profiling an artifact enforces nothing by itself; only the policy in force at the execution boundary decides what runs.

Aha · Execution control

One execution, inside a fleet.

A simulated fleet of agents, running in your browser. Follow one execution to a crown-jewel resource, watch PRAE intercept it at the execution boundary, and steer what the agent does next. Every decision is the real PRAE kernel judging the call — not a model of it. Nothing is executed.

PRAE / Playground
Open in console

SIMULATED FLEET Deterministic, in your browser. The agents and their calls are scripted; every decision is the real PRAE kernel judging the call against the fleet’s policy. Nothing is executed, and nothing here touches your own agents.

Agents remain autonomous. Execution does not.

AGENTS
250
COHORTS
4
RUNNING
160
HELD
46
BLOCKED
28
STEERED
16
CALLS JUDGED
250
VIEW

Each square is one agent, in an order that does not move. Open a cohort to inspect any of its agents.

ONE EXECUTION, INSIDE THE FLEET

Ticket Resolution Agent, in Support, is working a refund ticket. A note in the ticket will take it to Production Customer Data.

Or select any of the 250 agents in the fleet.

CONTROL → PROVE → SCALE

One execution is interesting.

Governing hundreds of executions is the product.

Live fleet steering signs one constraint for a cohort of running agents, and each agent’s own gate adopts it mid-session. Status: in development.

See the Fleet Control Plane

Runs entirely in your browser. No call leaves this page.

OWASP LLM TOP 10 2026 · EU AI ACT art. 12 · NIST AI 600-1 · SOC 2 CC7.2

The runtime lifecycle

Evaluate. Allow, hold or deny. Verify. Steer.

Not five steps in a row: one continuous loop at the execution boundary. Each governed call is evaluated before it runs and resolves to exactly one outcome. Evidence is sealed beside every decision, whatever it was. Steering changes the constraint the next call meets.

Every capability carries its status where it is listed, from the claim-to-evidence audit behind this page. Simulation means simulated agents, never production enforcement.

  • Shipping Built, available and supported in the configuration named.
  • Partially supported Available only for the integrations or paths named.
  • Simulation Demonstrated on simulated agents through the real gate. Not production enforcement.
  • Roadmap Planned or built but not released. Not available today.
01 Evaluate Each governed call, against the pack, before it runs

One per call: each call reaches exactly one of allow, hold or deny, never all three

ALLOW Runs within the policy boundary HOLD Waits for an authorization DENY Refused before it runs 03 Verify Every decision sealed, chained, checkable 04 Steer Changes what the next call meets

01 · Evaluate

Evaluate — before the protected action runs

The agent proposes a tool call. Where an integration puts PRAE in front of the tool, the call is classed into a capability and matched against the policy pack in force: tool, arguments, paths, hosts, commands and budgets. The strongest matching rule decides, and every match stays in the trace. The decision is deterministic rule evaluation: no model is called to make it.

  1. One verdict per call: allow, hold or deny.
  2. The rule that decided, its reason and the pack version go on the record.

PRAE evaluates only the calls an integration routes to it. A call that does not pass through PRAE is not seen, and nothing here intercepts every tool of every agent.

Where it holds today

  • Shipping Deterministic policy evaluation Rule matching, no model: the same call, pack and session state get the same verdict.
  • Shipping Node / TypeScript SDK · judge() in your tool loop Before each tool runs, in your process. Your loop must call it and honour the verdict.
  • Partially supported prae-gate at an agent harness’s tool seam One supported harness profile today: every tool call that passes its pre-execution seam.
  • Partially supported PRAE’s MCP server · prae mcp File reads routed through PRAE’s own MCP server (listings are confined to the root, not judged). Other MCP servers are not seen.
  • Partially supported Claude Code · PreToolUse hook Built-in and MCP tool calls, in shadow or enforce mode (prae-cli 0.10.0). A shell command is judged by its text, not its effect; files attached with @ fire no hook; output is not screened.
  • Roadmap MCP Gateway in front of any MCP server Not available.
Every integration, at its real status →

02 · One outcome of three

ALLOW — the call runs

The call is inside the policy in force, so it proceeds. PRAE does not run the tool itself: the integration hands it back to the agent’s own execution path.

  1. The tool executes.
  2. The allow is sealed with the rule that permitted it, or with no rule when none matched.

A call no rule matches is allowed and recorded. Write deny or warn rules for what must never pass silently.

Where it holds today

  • Shipping Allow, recorded with its rule Wherever PRAE evaluates the call. In Claude Code an allow hands the call back to Claude Code’s own permission prompt.
  • Shipping Shadow mode Every verdict computed and sealed, every call proceeds: read the decisions before anything blocks.

02 · One outcome of three

HOLD — the call waits for a person

The rule requires approval, so the call is suspended before it runs. It runs only if the approval comes back for that call; anything else leaves it unrun.

  1. The hold is sealed at the moment it is made.
  2. An approval releases that one call. A denial, or no answer, means it never runs.

How a hold is answered depends on the integration, and PRAE’s MCP server refuses a hold outright: it has no channel to a person. No approval today carries an identity from your identity provider.

Where it holds today

  • Partially supported Hold through the harness’s own approval flow The supported harness profile. The outcome is recorded; the approver is not identified.
  • Partially supported Hold returned to your application · judge() The SDK returns the hold; asking a person and recording the answer is your application’s job.
  • Partially supported Hold as Claude Code’s permission prompt The person at the session answers. PRAE records the hold, not what was answered.
  • Simulation Operator answers in the Command Center ALLOW, DENY or STEER signed with the operator key and bound to the exact action’s hash, on simulated Claude Code sessions.

02 · One outcome of three

DENY — the call never runs

The call is outside the policy, so it is refused at the boundary before the tool executes. The agent receives the rule and its reason instead of a result.

  1. The tool does not execute.
  2. The refusal is sealed with the rule and reason the agent was given.

A logged denial is not always a prevented action. In shadow mode the call still runs, and the SDK prevents only what your loop declines to run. A deny is one action refused at one point, not containment.

Where it holds today

  • Shipping Refusal before execution In enforce mode, wherever PRAE is in the path.
  • Partially supported Tool results withheld after execution The supported harness profile: a result carrying a credential never reaches the model. The tool did run.
Run it in the playground →

03 · Beside every decision

Verify — evidence beside every decision

Whatever the verdict, the decision is appended to a hash-chained ledger: each row carries the hash of the one before it, so a removed, edited or reordered row breaks the chain. Given a key, PRAE signs each row with Ed25519, and any row exports as a receipt a third party checks offline, comparing its key’s fingerprint with one they already trust.

  1. prae verify re-derives the chain and checks the signatures.
  2. prae checkpoint signs the ledger’s length and head, so a cut ledger is caught later.

A signature proves this record was not altered after it was sealed. It does not prove every action was intercepted, nor that a side effect in the world happened or was prevented. The key is yours to keep; nothing yet binds it to who holds it.

Where it holds today

  • Shipping Hash-chained ledger · prae verify Tamper-evident, not tamper-proof: whoever holds the key can rewrite the whole file.
  • Shipping Ed25519 signatures and offline receipts Rows are signed when a key is configured: always by the Claude Code hook, optionally by the harness gate and the SDK, never by PRAE’s MCP server.
  • Shipping Signed checkpoints Catch a truncated or rewritten ledger against a checkpoint kept elsewhere.
  • Roadmap Keys bound to an identity A key identifies a signing authority today, not a person or a workload.
Read a chained ledger →

04 · Where supported, then back to 01

Steer — intervene, then evaluate again

Steering changes the constraint in force, not the past. Answering a held call with STEER means that call does not run and the agent is told what to do instead. Changing the pack, or fencing a cohort with a signed constraint, affects the calls that come after it. Either way, the next call returns to Evaluate under the new constraint.

  1. The intervention is sealed as its own event.
  2. Subsequent calls are evaluated under the constraint now in force.

Fleet steering is shown on a simulated population of Claude Code sessions. Steering live production agents is not built.

Where it holds today

  • Partially supported Pack changes take effect on the next call The harness gate reloads an edited pack with no restart, and keeps the one in force if the edit does not parse; the Claude Code hook reads the pack on every call.
  • Simulation STEER a held call The Command Center, on simulated Claude Code sessions through the real gate.
  • Simulation Fleet steering by cohort A signed constraint each targeted gate verifies and adopts mid-session, on a simulated fleet.
  • Roadmap Steering live production agents No live fleet, hosted control plane or SDK steering yet.
  • Shipping Reuse of authored policy The packs you write persist, versioned, and govern every next run.
  • Roadmap Interventions promoted into reusable controls Nothing learns from interventions or promotes them automatically.
Live fleet steering, as it stands →

The agentic control plane

Six capabilities. Four of them do something today.

Everything agents need to act with organizational fidelity — grounded, constrained, and continuously improving. Execution control is the one that runs end to end, and it is the one running in the page above. Three more do part of what they describe today, and two are still roadmap. Each is labelled for which.

We would rather you find the roadmap here than in the console.

01

Instruction ingest

In part

Today: every AGENTS.md, CLAUDE.md and .cursorrules an agent would be given is read the way the harness reads them — operator files above project files, each statement carrying its file, line and layer — and the enforceable subset is proposed as rules you review, never applied. Anchoring those instructions to the code they talk about is the half still to build.

02

Context compilation

In part

Today: a project context file is served to every agent in the profile and the whole assembled prompt is hashed into the decision ledger, so what the agent knew and what it did sit on one chain. Compiling that context — filtered by structural relevance, scope, trust, and task — is the half still to build.

03

Execution controls

Shipping

Explicit constraints applied before execution — permissions, policies, paths, hosts, budgets. The operator baseline is intersected with what a plugin's author declared, and the operator can only ever narrow. Not to make agents less autonomous. To make autonomy trustworthy.

Run it in the playground →
04

Evidence & verification

In part

Today: every decision and every prompt assembly is written to a hash-chained log with the clause that produced it — a removed, edited or reordered row breaks the chain — and any row exports as a signed receipt a counterparty checks against a pinned key, without the ledger, our machine, or yours. Completeness is the half still to build: a signature proves a decision happened, not that no others did, and nothing yet binds a key to who holds it.

Read a chained ledger →
05

Structural grounding

On the roadmap

Anchor organizational knowledge to the systems agents actually operate within — repositories, services, modules, symbols, dependencies, call graphs, execution paths, and architectural boundaries. Context becomes structurally grounded, not disconnected text.

06

Enterprise ontology

On the roadmap

Verified discoveries become structured, durable knowledge — architecture, workflows, constraints, failure patterns, and organizational rules. This is the compounding layer: every verified execution makes future ones better.

Products

Where PRAE governs execution.

Not only coding agents. The same execution control governs the agents on your developers’ machines, the agents your team builds, and the agents you deploy as services — each labelled for what ships today.

Agents, by environment

Developer agents → custom / homegrown agents → deployed SaaS agents

Developer agents In part Claude Code’s tool calls through a hook; Cursor, Windsurf and GitHub Copilot through MCP file access and their instructions. In part today. Learn more → Custom / homegrown agents Shipping Agents built into your applications: what they can execute, decided before they run. Learn more → Deployed SaaS agents In part Agents running as applications and services — Node / TypeScript today; the MCP Gateway in development. Learn more →

Governance

What applies to every agent PRAE governs

Shadow AI Shipping Unreviewed agents meet the same policy as approved ones at the execution boundary. Learn more → MCP Gateway In development A stateless MCP gateway that inspects each tool call before it reaches the server. In development. Learn more → Policy enforcement Shipping Explicit rules over what agents may execute — allow, hold or deny — with no model in the path. Learn more → Live fleet steering In development Dynamic constraint mutation for active agent populations: fence a cohort and change what running agents can do, without terminating them. Learn more →

Where your agents operate: Cursor Claude Desktop Windsurf GitHub Copilot Slack AI (roadmap)Microsoft 365 Copilot (roadmap) every integration, at its real status.

AI compliance & audit readiness

Answer questions about AI risk and compliance with hard evidence.

Know what your agents were allowed to do. Know what they actually did. Prove it.

Policy → Decision → Execution → Evidence

Explore AI compliance → See the evidence →

  • ISO/IEC 42001:2023 Mapped
  • EU AI Act Mapped in part
  • NIST AI RMF Mapped in part
  • MITRE ATLAS Mapping planned
  • OWASP Top 10 for LLM Applications 2026 Mapped
  • Mapped controls and evidence support your programme; they are not a certification.

Evidence & verification

Knowledge earns trust. It isn't assumed.

Design

Discoveries move through explicit trust states before they're allowed to influence future execution.

This ladder is the model we are building to, not a feature you can use yet. What exists today is the record underneath it — and the receipt below it, which is already yours to check.

Tier 0

Candidate

An unverified observation or hypothesis surfaced during execution. Noted, not trusted.

Tier 1

Corroborated

Supported by repeated or independent evidence across separate executions.

Tier 2

Verified

Backed by tests, reproducible behavior, static analysis, or deterministic verification. Eligible to enter the ontology.

Underneath it: a receipt anyone can check

Shipping

Every decision is hash-chained to the one before it, with the clause that produced it. Any single row then exports as a signed receipt — the decision, an Ed25519 signature over its seal, and the public key. Whoever holds it recomputes the row's hash and checks the signature against a fingerprint they already trust, needing neither the ledger, nor our machine, nor yours.

$ prae receipt decisions.jsonl 42 --key prae-signing.pem --out receipt.json

Bounded on purpose: a signature proves this decision happened, not that no others did — only the chain speaks to that, and only to you. The key stays in your custody, and nothing yet binds it to who holds it. Both are named on the roadmap above rather than papered over here.

Only verified knowledge becomes durable organizational intelligence.

The moat

A mall gets bigger. A garden gets richer.

Hyperscalers provide the infrastructure mall — compute, models, orchestration, storage. Essential, and the same for everyone. PRAE cultivates the enterprise-specific intelligence that makes agents effective inside your organization, specifically.

The MallHyperscalers
  • Compute
  • Models
  • Orchestration
  • Storage & networking
  • Generic AI primitives

Gets bigger. Same for every organization that buys it.

The GardenPRAE
  • Architecture & dependencies
  • Business rules & workflows
  • Verified discoveries
  • Failure patterns
  • Domain ontology

Built to get richer with every verified execution — the compounding layers (05 and 06 above) are on the roadmap. Specific to your organization, and impossible to buy off the shelf.

Get started

Put a control plane between your agents and what they execute.

For engineering leaders evaluating agentic infrastructure at enterprise scale.

One email to us, nothing stored. We reply from thetalosteam@gmail.com.

Agents execute.

PRAE decides which of their actions run, where it is in the path, and keeps the evidence of every decision.