System documentation

Operate the full control loop.

Use this page to choose the right enforcement boundary, wrap a dangerous tool, publish a constitution, and export proof that still makes sense under review.

Start with the boundary. Then wrap one tool.

Choose local block, strict preflight, sandbox, or database control.

Copy the SDK shape that matches the dangerous action.

Publish policy, run one blocked action, then export proof.

Start here

Choose the path that matches your job.

Choose a boundary

Start with Boundary Choice to decide whether the action needs local block, strict preflight, sandbox, or database control.

Wrap the tool

Use SDK Quickstart to put the control layer around the dangerous function, not around the whole application.

Publish and prove

Use Policy Model, Operations, and Evidence to understand what gets blocked, halted, and exported.

Overview

The system in one picture.

Imladri is built around one policy source and one runtime chain. The best first deployment is an OpenClaw, Hermes, custom-code, cloud, database, or third-party compute agent with real privileges.

Policy

Publishes what a coding, cloud, database, or third-party compute agent may do, deny, escalate, or run under attestation.

Runtime enforcement

Performs synchronous allow, deny, sandbox, database-gateway, or attestation checks before code pushes, deploys, database mutations, or privileged jobs run.

Evidence

Scores outputs for drift and writes warnings, review-required state, halts, and enclave evidence back into operator state.

Current proof state

The canonical proof split is now explicit. Standard control runs with no sandbox. Agent wrapping is verified across OpenClaw, Hermes, MCP, and Generic HTTP with model-selected turns, native tool or plugin-body checks, side-effect sentinels, and exported proof artifacts. The process-backed qualification runner handles lighter pre-live checks. The Docker path is reserved for high-assurance allow-only proofs and adversarial qualification packs. The runtime enforcement layer now also exposes a governed database-query lane for agent SQL actions, and the database sandbox path has a 20-sample 5B-row copy-on-write branch proof. Separately, the private Providers and Training path is already proven on RunPod and Vast.ai for protected CUDA/PyTorch training under the same product surface.

Validation snapshot

Signal	Current result	Why it matters
Production buyer-flow smoke	Passed	Fresh approved-profile path, Resend email checks, Agent connect/classify/publish/verify/deploy flow, 310s monitoring, proof export, and SDK key rotation.
Runtime-agnostic agent boundary	4 runtimes	OpenClaw, Hermes, MCP, and Generic HTTP share one policy path; mixed-runtime blocks complete with 0 prohibited body calls.
SDK adopter matrix	71/71 lanes	20 SDK adapter families passed the current certification matrix. MCP and Any CI are certified separately as product surfaces.
Hosted adopter proof	5 surfaces	Dify, Flowise, n8n, Zapier MCP, and Botpress hosted proof paths passed with allowed-call evidence and zero blocked-path body calls.
Hosted CI proof	GitLab + Vercel	The scanner runs in hosted CI but stores evidence as Imladri-native proof, not as GitHub-specific state.
Local SDK block	0.065ms p95	Known-prohibited actions stop before network and before customer code when the constitution is warm.
Live preflight	194.45ms p95	Halt-aware Worker + Glasshouse strict preflight for high-risk actions.
Operator halt	74.18ms p95	Worker-proxied halt rejected the next enforcement-boundary action with AGENT_HALTED.
5B-row DB sandbox	56.84ms p50	Twenty governed Postgres COW branches over a verified 5B-row, 690.34 GiB source; 0 source mutations and 6/6 proof checks.
Evidence integrity	SHA-256	Signed proof export stays on the FIPS-compatible digest path. BLAKE3 remains experimental only.

Private beta proof

Approved users get the local proof package.

The local terminal path is available to approved beta users, not as a public install command. It follows the same product story as the private pilot workspace: setup checks, wrapper boundary, governed DB branch, proof export, and cleanup.

Join waitlist Contact us

Beta access path

Join the waitlist, get approved, then receive the private local package and setup instructions. The public website intentionally does not expose the install command.

What demo blocks and proves

Doctor confirms service health, SDK auth, and DB target wiring.
Wrap proves one allowed action and one prohibited action denied before the function body.
Sandbox creates, writes, exports proof, checks source isolation, and destroys the branch.

Step 1

Approve

Approved beta users receive the private local package and setup notes directly.

Step 2

Verify

Confirm service health, SDK auth, DB target wiring, and copy-on-write branch support.

Step 3

Prove

Run allowed and blocked wrapper checks, create a DB branch, export proof, and clean it up.

Step 4

Inspect

Open demo.md for the readable report and demo.json for the full evidence packet.

Artifact path

The combined proof packet is written to tmp/imladri-package/demo-<timestamp>/demo.json. The paired demo.mdis the human-readable proof report with the wrapper denial, DB sandbox lifecycle, source cleanup check, and JSON SHA-256 digest. See the repository file docs/cli-demo-proof.mdfor a redacted sample.

Private workspace alignment

The private pilot workspace is the visual version of this path: Agent wrapping maps to the wrapper boundary, Sandbox maps to the DB branch lifecycle, Deployments holds activity and proof, and Providers/Training handles the protected GPU compute path.

Boundary choice

Pick the lightest boundary that gives the guarantee you need.

Imladri does not need to sit in front of every harmless agent step. Put the right boundary around the dangerous capability: local block for known bad actions, strict preflight for high-risk side effects, sandbox for command-shaped work, and database control or database sandbox branches for SQL and production-like write tests.

Boundary	Latency posture	Network	When to use it
Local SDK block	0.065ms p95	No	Known-prohibited actions with inline or cached constitution state.
Strict preflight	about 195ms p95 live today	Yes	High-risk allowed actions that need live halt or policy state before commit; Access/network is now the dominant cost.
Operator halt	74ms p95 Worker path	Yes	Stops following SDK, preflight, sandbox, and database enforcement-boundary actions until review clears the agent.
Sandbox denied before spawn	about 213ms p95	Yes	Command-shaped actions rejected by halt or constitution before process start.
Sandbox allowed or violated	Decision time plus workload execution	Yes	Command-shaped actions where execution proof, blocked writes, backend, and network mode matter.
Database execution	Network plus query time	Yes	SQL actions that need template, tenant, schema/table, mode, masking, branch isolation, and row proof.
Database sandbox branch	56.84ms p50 create	Yes	Postgres copy-on-write branches for agent tests that must prove writes stayed away from the source database.

Honest boundary

Capabilities not routed through the SDK boundary are observable and haltable, but not pre-execution preventable. Dangerous capabilities should be wrapped through wrapped tools, strict preflight, sandboxed actions, or governed database actions.

Strict preflight and sandbox execution both depend on the runtime seeing a fresh published policy. If that cache is stale, the decision can be stale too. The sandbox lane improves the evidence story because allowed work runs under the declared backend, path, and network policy, but cache health is still an operator responsibility.

SDK quickstart

Wrap the privileged action path, not the whole app.

The examples below show the pilot integration path: normal evidence uses the Worker URL, while high-risk strict preflight can point directly at the runtime host for the lower-latency halt boundary. If that endpoint is Cloudflare Access protected, the SDK can attach the pilot service-token headers from environment variables.

from imladri import Imladri

imladri = Imladri.from_env()

@imladri.action("cloud.deploy", strict_preflight=True)
def deploy_release(release):
    return deployer.deploy(release)

tools = imladri.wrap_tools(
    {"customer.read": customer_lookup, "email.send": send_email},
    strict_tools=["email.send"],
)

intent = {"customer_id": customer_id, "amount_cents": 5000}
imladri.preflight("payment.refund", intent=intent)
payment_gateway.refund(**intent)

const agent = new ConstitutionalAgent({
  agentId: process.env.IMLADRI_AGENT_ID!,
  apiKey: process.env.IMLADRI_API_KEY!,
  apiUrl: process.env.IMLADRI_API_URL!,
  preflightUrl: process.env.IMLADRI_PREFLIGHT_URL,
});

const deployRelease = agent.action(
  "cloud.deploy",
  async (changeSet: ReleasePlan) => cloud.deploy(changeSet),
  {
    strictPreflight: true,
    intent: (changeSet) => ({ service: changeSet.service, version: changeSet.version }),
  },
);

await agent.runSandboxedAction("deploy.preview", {
  command: "node",
  args: ["scripts/check-release.mjs"],
  workspaceFiles: [{ path: "plan.json", content: "{}" }],
  outputPaths: ["reports/preview.txt"],
});

Adapters, MCP, scanner

Adopt Imladri without changing agent frameworks.

The beta path now has three integration surfaces: SDK adapters for existing tool objects, an MCP server for tool hosts, and an Imladri-native CI scanner that writes local findings during waitlist review. Private proof workspaces are opened for design partners when the integration moves from public preview into onboarding.

import {
  ConstitutionalAgent,
  wrapLangChainTools,
  wrapLangGraphNodes,
  wrapLlamaIndexTools,
  wrapVercelAITools,
  wrapMastraTools,
} from "@imladri/sdk";

const agent = new ConstitutionalAgent({ agentId, apiKey, apiUrl, preflightUrl });

const guardedLangChainTools = wrapLangChainTools(agent, tools, {
  strictTools: ["payment.transfer", "cloud.deploy"],
});

const guardedGraphNodes = wrapLangGraphNodes(agent, nodes, {
  strictTools: ["secrets.read"],
});

const guardedVercelTools = wrapVercelAITools(agent, aiTools, {
  strictTools: ["email.send"],
});

const guardedLlamaTools = wrapLlamaIndexTools(agent, llamaTools, {
  strictTools: ["customer.data.export"],
});

const guardedMastraTools = wrapMastraTools(agent, mastraTools, {
  strictTools: ["cloud.deploy.production"],
});

# MCP server uses short-lived authority from a private pilot workspace
IMLADRI_AGENT_ID=<pilot-agent-id> \
IMLADRI_AUTHORITY_TOKEN=<pilot-issued-token> \
IMLADRI_WORKER_URL=https://<worker> \
node mcp-server/server.mjs

# Waitlist preview keeps scanner artifacts local
imladri scan init-ci --provider gitlab --output .gitlab-ci-imladri.yml

IMLADRI_SCAN_WORKER_URL=https://<worker> \
IMLADRI_SCAN_AGENT_ID=<pilot-agent-id> \
IMLADRI_SCAN_SDK_KEY=<pilot-sdk-key> \
imladri scan --path . \
  --config .imladri-scan.json \
  --format json \
  --output imladri-boundary.json \
  --fail-on new

# Private design partners can export a signed proof packet during onboarding
imladri proof export --format json --output imladri-proof.json

Policy model

One schema feeds enforcement and monitoring.

The table below describes the public shape conceptually rather than listing every implementation-facing field name.

Field	Type	Use
Purpose and scope	Policy document	Human-readable mission and operating shape for the agent.
Hard-deny rules	Rule set	Actions that should never execute on the hot path.
Allowed-path rules	Rule set	Actions that may run under the published policy.
Conditional constraints	Rule set	Additional checks attached to more sensitive actions.
Monitored behaviors	Rule set	Behaviors that stay allowed but receive closer drift review.
Fallback behavior	Policy mode	How the system treats newly seen or uncategorized actions.
Revision marker	Version id	Published identifier carried into runtime and reports.

Operations

The five operational states you need to reason about.

Allowed

Action passes the hot path and the signed acknowledgement is stored.

Blocked

A denied action or hard rule rejects the request before side effects.

Review required

The action is parked before side effects and recorded for operator approval, which now matters in the governed database lane.

Warned

Semantic drift stays below halt threshold but still becomes part of operator review.

Halted

An agent-level halt stops all future actions until a human clears it.

Evidence

What a signed report needs to contain.

Published policy revision and review context.

Signed runtime decisions with timestamps and integrity data.

Requested versus effective sandbox backend, network mode, and whether network isolation was actually enforced.

Scoped database credential resolution, approved query template use, and masked result fields when DB control is active.

Actor attribution and export context suitable for audit and security review.

Drift findings with severity and review state.

Human review annotations describing intervention and outcome.

Tamper-evident proof showing whether the record changed after the fact.

Performance

Current live enforcement sample.

Keep the public docs focused on the enforcement boundaries a customer chooses during integration. Full proof-lane timing history stays in the engineering performance guide; this page carries the numbers that explain the SDK decision.

The live canary is run with tests/bench_production_canary.py. The local microbenchmarks still use tests/bench_agent_overhead.py. Production latency still depends on network, service placement, database choice, and concurrency, so the live runtime numbers are the ones that matter for public claims.

Metric	Latest sample	Sample basis	Notes
Local SDK hard block	0.013ms p50 / 0.065ms p95	100 blocked attempts	Known hard-deny actions reject from inline/cached constitution state before network and before customer code.
Worker strict preflight	149.34ms p50 / 194.45ms p95	100 allowed attempts	Latest live Worker + Glasshouse allowed-action burst after the 60s SDK-auth cache TTL, Worker assertion, and queue changes.
Worker blocked preflight	104.88ms p50 / 195.85ms p95	100 blocked attempts	Latest prohibited payment.transfer burst through the live Worker path.
Operator halt propagation	67.87ms p50 / 74.18ms p95	Worker path	The next enforcement-boundary action was rejected with AGENT_HALTED.
Sandbox denied before spawn	106.64ms p50 / 212.51ms p95	100 blocked attempts	Latest OpenClaw lab sample: live constitution or halt gate rejects before the process or Docker lease starts.
Database sandbox branch	56.84ms p50 / 68.95ms p95 create	20 COW branches over 5B rows	Latest focused repeat check over a verified 690.34 GiB source: 0 source mutations and 6/6 proof checks.

Enterprise path

What still has to exist for serious enterprise rollout.

The runtime loop is already real. The next enterprise layer is the control plane around it: tenant scope, RBAC, auditability, validation, and data isolation. That path is documented here as rollout context, not as the first integration step.

Organizations and workspaces

Define every privileged resource under a tenant boundary instead of one shared admin surface.

RBAC and service accounts

Move from the current internal admin model to backend-enforced roles, scoped API tokens, and service-account ownership.

Append-only audit logs

Record who changed policy, who exported evidence, who cleared halts, and what request produced the action.

Validation and bounds checking

Standardize input size, path, enum, timeout, and artifact limits across Worker, runtime enforcement, monitoring, and policy services.

Tenant isolation

Make every read and write org-scoped, then tighten encryption, retention, and export controls around that model.

Narrow white-labeling

Brand the portal and report without forking auth, policy semantics, or the data model per customer.

Current honest state

The current hidden dashboard admin path is still an internal operator surface, not the final enterprise auth model. The target architecture is one org and workspace model, backend-enforced roles, append-only audit logs, org-scoped runtime services, and tenant-scoped data across the control plane.

Today's shipped stack already includes signed evidence, selective sandboxing lanes, an access-protected runtime host, governed database sandbox branches, and governed RunPod and Vast.ai enclave paths. Broader rollout work should focus on access control, auditability, validation, and tenant isolation around that core.

Pilot path

Wrap one dangerous tool, then prove the boundary.

The fastest useful pilot is one side-effectful action: publish a constitution, run one allowed call, block one prohibited call, verify halt, and export proof.

Join the waitlist Contact us