Question 1

What does Imladri do?

Accepted Answer

Imladri is runtime control for agents that can touch code, cloud, databases, privileged tools, or third-party compute. The agent path is proven across OpenClaw, Hermes, MCP, and Generic HTTP, with 20 SDK adapter families, MCP authority, hosted adopter proof, and Any CI scanner proof around the same boundary. Teams publish a constitution, route dangerous capabilities through the boundary, block prohibited actions before side effects, halt compromised agents, and export SHA-256 signed evidence for review.

Question 2

Who should evaluate Imladri first?

Accepted Answer

The strongest first customer is a security, platform, infrastructure, or AI product team shipping an agent with real authority. Good pilots involve one agent, one meaningful side-effect surface, a clear allowed list, and at least one prohibited action that must stop before commit.

Question 3

What does the customer actually wrap?

Accepted Answer

Wrap the dangerous capability, not the whole app. In a private pilot that can be an OpenClaw bridge, a Hermes bridge, an MCP host, or a custom SDK endpoint. Good first targets are deploys, pull-request writes, cloud changes, privileged database queries, payment transfers, email sends, file writes, shell commands, or any tool where an agent mistake creates real cost.

Question 4

How does a pilot start?

Accepted Answer

Join the waitlist, confirm the first runtime or adopter path, wrap one dangerous tool, run one allowed action and one prohibited action, review the local proof artifact, then convert that artifact set into a private design-partner workspace after approval.

Question 5

Can Imladri stop any arbitrary function my agent calls?

Accepted Answer

No. Capabilities routed through the SDK, preflight, sandbox, or database boundary can be stopped before the function body, before process spawn, or before database execution. Already-allowed unwrapped functions are observable and haltable after they are seen, but not pre-execution preventable.

Question 6

What blocks locally?

Accepted Answer

Known hard-deny actions can stop inside the SDK when the constitution is inline or warm in local cache. The conservative public sample blocked 100/100 known-prohibited attempts before network and before customer code at 0.013ms p50 and 0.065ms p95.

Question 7

When should I use live strict preflight?

Accepted Answer

Use live strict preflight for high-risk allowed actions that need current halt or policy state before commit. The latest Worker path measured 149.34ms p50 and 194.45ms p95 for allowed preflight, and 104.88ms p50 / 195.85ms p95 for prohibited payment.transfer attempts blocked before the function body.

Question 8

What happens when an operator halts an agent?

Accepted Answer

A halt propagates to the next SDK, strict-preflight, sandbox, or database enforcement-boundary action. The latest Worker-proxied halt sample rejected the next action at 67.87ms p50 and 74.18ms p95. The agent stays halted until an operator clears it.

Question 9

When should I use sandbox execution?

Accepted Answer

Use sandbox execution for command-shaped work where filesystem, network mode, backend, blocked writes, and execution result proof matter. Prohibited sandbox actions are denied before process spawn; allowed work produces execution evidence tied to the published constitution.

Question 10

How fast is the sandbox gate?

Accepted Answer

The latest OpenClaw lab sandbox denied-before-spawn sample measured 106.64ms p50 and 212.51ms p95. Agent-runtime compatibility is proven separately across OpenClaw and Hermes; sandbox timing is about the stronger process lane. Allowed sandbox execution is workload-dependent because the command still has to run, produce output, and be checked against the workspace policy.

Question 11

When should I use database execution?

Accepted Answer

Use database execution for SQL actions that need approved templates, tenant scope, schema or table checks, masked result fields, and row-level proof. It is the better boundary when the risky capability is data access rather than shell or deployment work.

Question 12

What did you validate for database sandboxing?

Accepted Answer

The focused repeat proof created 20 governed Postgres copy-on-write branches over a verified 5B-row, 690.34 GiB source at 56.84ms p50 and 68.95ms p95 with 0 source mutations and 6/6 proof checks. The GCP Local SSD branchd run then sustained 500/500 DDL-heavy 5B branches at 88.27ms create p95 with zero source mutations.

Question 13

Is Imladri a replacement for sandboxing?

Accepted Answer

No. SDK and strict preflight control declared dangerous actions before they run. Sandbox execution is the stronger lane when the process, filesystem, network isolation, blocked writes, and result artifact need to be proven. The lanes are complementary.

Question 14

How is this different from ordinary monitoring?

Accepted Answer

Ordinary monitoring is usually a postmortem log. Imladri is a control boundary first: it records the policy revision, action decision, halt state, sandbox or database lane, and signed outcome at the moment the runtime decision is made.

Question 15

What data does Imladri need to inspect?

Accepted Answer

The system needs the action type, agent id, policy context, requested tool inputs, and enough execution metadata to prove the decision. Customers should route secrets and sensitive payloads through scoped integrations, masking, or sandbox/database proof lanes instead of dumping raw production data into logs.

Question 16

What is in the proof export?

Accepted Answer

A proof packet includes the published constitution revision, signed action rows, drift or halt events, operator notes when present, sandbox or database evidence when those lanes are used, and integrity proof that the chain was not altered after the fact.

Question 17

Why stay on SHA-256 instead of BLAKE3?

Accepted Answer

BLAKE3 is fast enough for large payload experiments, but it is not SHA-256 or FIPS-compatible. Customer-facing evidence stays on the SHA-256 path; BLAKE3 remains experimental and separate from production proof claims.

Question 18

What is live today?

Accepted Answer

The private pilot path has live signup, Resend email checks, constitution publish, SDK keys, OpenClaw/Hermes/MCP/custom runtime support, 20 certified SDK adapter families, hosted Dify/Flowise/n8n/Zapier/Botpress proof, GitLab and Vercel CI scanner proof, local hard blocks, Worker strict preflight, sandbox and database lanes, halt propagation, monitoring rows, public proof shares, and SHA-256 proof export. Billing is still manual/design-partner only.

Question 19

Can this work in third-party compute environments?

Accepted Answer

Yes. The third-party GPU enclave proof started on RunPod and now includes same-instance Qwen LoRA overhead work plus Vast.ai provider validation through the same Training lifecycle and proof flow. Providers and Training stay separated so new compute providers can fit the protected-compute path without changing the agent guardrail flow.

Question 20

What is still beta?

Accepted Answer

The production enterprise layer is still being hardened: organizations and workspaces, backend-enforced RBAC, append-only audit logs, final tenant isolation, validation limits, rollout tooling, and wider third-party compute provider coverage.

Question 21

How should a design partner evaluate it?

Accepted Answer

Pick one workflow where an agent can create a real side effect, define allowed and prohibited actions, wrap the dangerous capability, run a prohibited-action test, verify halt, and review the signed proof export. That gives a concrete security result instead of a generic demo.

Runtime security questions, answered at the boundary.

Prevention applies where the dangerous capability crosses Imladri.

What the product is and where it fits

What stops before execution

When to use stronger execution lanes

What gets recorded and exported

What is live now and what remains beta

Put one dangerous tool behind the boundary.