OpenBox AI

The SDKs and plugins wrap agents built on Temporal (a Python plugin), LangChain, LangGraph, CrewAI and Deep Agents in Python, and Mastra and CopilotKit Runtime v2 in TypeScript, plus an n8n community node and an OpenRouter SDK, so each operation the agent takes passes through OpenBox for a verdict. These govern actions the customer's own framework takes; nothing lets an agent take authenticated action in an outside system through OpenBox. Cursor and OpenClaw are listed as coming soon.

SourceOpenBox, docs.openbox.ai/getting-started and /developer-guideread 2026-09-25

OpenBox governs agent runs rather than running them. The workflow, its steps and its handoffs belong to the customer's framework, such as Temporal, LangGraph or CrewAI, and a HALT verdict cancels that framework's workflow rather than steering one of OpenBox's own. Multi-Agent Sessions is a view of runs for each team, not a workflow, and no workflow model of OpenBox's own is documented.

SourceOpenBox, docs.openbox.ai/core-concepts/governance-decisions and /administration/organization/teams/multi-agent-sessionsread 2026-09-25

Nothing in OpenBox's documentation indexes or retrieves the customer's documents for the agent to ground its answers on; it is a governance layer around the customer's agent. Guardrails inspect the agent's inputs and outputs, which is oversight rather than grounding.

SourceOpenBox, docs.openbox.ai/overview and the docs index (llms.txt and llms-full.txt)read 2026-09-25

A review and approve surface of OpenBox's own ships. When an operation crosses a risk threshold, a policy calls for review or the agent's trust tier requires it, OpenBox returns REQUIRE_APPROVAL: the operation pauses and appears in the Approvals queue, and a reviewer approves, rejects or escalates it, while an unanswered request expires. Who approved or denied, and when, is recorded with the decision.

The Adapt tab shows each agent's pending approvals with risk tier, semantic action type and triggering rule, plus approval history and approval rate. Chained guardrails screen the inputs and outputs of every operation, and BLOCK and HALT verdicts stop an action or end the session. Each framework SDK documents how it enforces these verdicts.

SourceOpenBox, docs.openbox.ai/core-concepts/governance-decisions, /trust-lifecycle/adapt, /trust-lifecycle/authorize/guardrails and /administration/compliance-and-auditread 2026-09-25

A named access model is documented: Admin, Developer and Viewer roles set under Organization > Permissions (a Viewer can see agents, logs and reports and cannot change anything), and teams that decide which agents a member can see and which sessions they can act on.

Each agent also carries its own cryptographic identity, a DID and an Ed25519 signing key kept separate from its API key, and OPA/Rego policies run stateless permission checks on every agent operation, giving least privilege tool access. An organization audit log records who changed what. No identity provider integration such as SSO, SAML or SCIM is documented.

Attestation is unconfirmed. The openbox.ai footer carries ISO 27001, ISO 42001 and NIST badge images with no link, certificate, auditor, report or date behind them, and the compliance page names SOC 2, ISO 27001 and GDPR only as frameworks OpenBox maps its customers' audit evidence to. trust.openbox.ai and security.openbox.ai do not resolve, openbox.ai/security returns 404, and the FAQ's security tab renders only in the browser.

SourceOpenBox, docs.openbox.ai/administration/organization, /administration/organization/teams, /core-concepts/agent-identity and /trust-lifecycle/authorize/policies, plus the openbox.ai footer and /solution/complianceread 2026-09-25

Session Replay steps through an agent session event by event, showing every tool call, governance decision and full JSON payload. The Monitor tab tracks each agent's invocations, response time and token use, along with cost and errors, over selectable time ranges.

Every governance decision goes into an immutable audit trail with verdict, reason, workflow and run IDs and approval metadata, with export on demand, and each session's events are hashed into a Merkle tree and signed into a tamper evident proof certificate (AWS KMS by default, or the customer's own attestation service). An organization audit log records user and configuration changes, separate from the runtime traces.

SourceOpenBox, docs.openbox.ai/trust-lifecycle/session-replay, /trust-lifecycle/monitor, /administration/compliance-and-audit and /administration/attestation-and-cryptographic-proofread 2026-09-25

State is kept about the agent, not for it: trust score history, behavioral rules that track patterns over several steps, and approval history. OpenBox applies all of these as governance rules, and the agent never reads them as context to decide. Universal Agent Memory Governance on the Enterprise card governs the customer's memory rather than providing one, and it is a pricing bullet with no documentation behind it. No memory layer or state the agent reads across runs is documented.

SourceOpenBox, docs.openbox.ai/core-concepts/trust-scores, /trust-lifecycle/authorize/behaviors and openbox.ai/pricingread 2026-09-25

The Enterprise plan lists Custom Deployment and SLAs on the pricing page, a one line claim that a deployment option exists, with no named environment, region or way to choose behind it. Every SDK guide points the agent at the hosted endpoint core.openbox.ai, and no region list, self hosted or customer cloud option is documented.

External attestation lets the customer sign proof certificates with its own attestation service or a Trusted Execution Environment, which decides where the signing key sits, not where OpenBox runs. OpenRouter routing policies can restrict model providers by data residency, which governs the customer's model traffic rather than OpenBox's own deployment.

SourceOpenBox, openbox.ai/pricing, docs.openbox.ai/getting-started/deep-agents and /administration/attestation-and-cryptographic-proofread 2026-09-25

Four guardrail types, from PII detection and content filtering to toxicity and banned words, can be chained into a pipeline for each agent, and three preconfigured risk profiles (low, medium and high) set an agent's starting trust tier. These are modules of one governance engine that the customer assembles, plus presets for settings. Neither is a packaged asset a buyer adopts as a working unit, and no catalog of ready made agents, workflows or policies is documented.

SourceOpenBox, docs.openbox.ai/trust-lifecycle/authorize/guardrails and /trust-lifecycle/assessread 2026-09-25

Agents are not started by OpenBox. Its SDKs wrap an agent that the customer's own runtime already runs, whether Temporal, LangChain or n8n among others, and every governance evaluation responds to an operation that agent began. Alerts on trust tier changes and goal drift flag agents for people to review rather than waking an agent.

SourceOpenBox, docs.openbox.ai/getting-started and /dashboard/alerts; docs.openbox.ai/dashboard/alertsread 2026-09-25

There is no model surface of OpenBox's own for the customer's agent: the agent's framework chooses its model and OpenBox evaluates the operations that result. The OpenRouter SDK's routing policies are Rego rules that allow or deny model providers and record proof of where each call was routed, which governs the customer's model traffic rather than offering a choice inside OpenBox. The Alignment Score uses an LLM evaluation described as configurable, with no provider list or selection documented.

SourceOpenBox, docs.openbox.ai/developer-guide/openrouter/routing-policies and /core-concepts/trust-scoresread 2026-09-25

SDKs for OpenBox's own platform are published: a Python Temporal plugin with a full API reference, Python SDKs for LangChain and LangGraph, CrewAI and Deep Agents, and TypeScript SDKs for Mastra and CopilotKit, plus an n8n community node and an OpenRouter SDK, each documented with configuration options, error codes and an event model.

They authenticate to the hosted endpoint core.openbox.ai with API keys for each agent (live and test) and send each agent operation for a governance verdict. No REST API reference and no MCP server of OpenBox's own is documented; the MCP mentions in the docs sit in the Temporal demo agent's pages.

SourceOpenBox, docs.openbox.ai/developer-guide/temporal-python/sdk-reference, /developer-guide/langchain and /getting-started/copilotkit/add-openbox-to-copilotkitread 2026-09-25

The Verify phase scores each session's actions against the agent's declared goal using an LLM evaluation described as configurable, shown as a 0 to 100 percent Alignment Score with check counts, a trend line against a threshold (70 percent by default) and logged drift events. That scores the customer's agent's behavior over time.

Nothing tests an agent against fixtures, mocks or datasets before production, the score runs only on live sessions, and the Adapt phase tunes governance rules, not the agent. The Assess phase is a risk questionnaire, not a test, and earlier claims of red teaming before deployment and CI/CD checks do not appear on the current docs, pricing or compliance pages.

SourceOpenBox, docs.openbox.ai/trust-lifecycle/verify, /core-concepts/trust-scores and /trust-lifecycle/assessread 2026-09-25

Agent operations are governed, but no browser or computer is operated. The two browser mentions in the docs are steps in demo walkthroughs, and no browser or computer use capability is documented.

SourceOpenBox, docs.openbox.ai/overview and the docs index (llms.txt and llms-full.txt)read 2026-09-25