Press Release

OpenBox Launches on AWS Marketplace: Runtime AI Governance

OpenBox is now on AWS Marketplace as a self-hosted runtime AI agent governance platform, deployed entirely inside your AWS account and VPC.

Published on

Subscribe to our newsletter

By submitting your email, you agree to our Privacy Policy and consent to receiving updates from us

OpenBox Launches Runtime AI Agent Governance on AWS Marketplace, Deployed Inside the Customer's Own AWS Account

OpenBox is now available on AWS Marketplace with the Deployed on AWS designation. Enterprises can procure runtime AI agent governance through their AWS billing and deploy it entirely inside their own AWS account and VPC, with the OpenBox platform, policies, and audit trail running inside the customer's environment.

By Tahir Mahmood, Co-founder & CTO, OpenBox ยท Last updated 23 October 2026

In brief: OpenBox has launched on AWS Marketplace as a self-hosted runtime AI agent governance platform, carrying the Deployed on AWS designation. Enterprises deploy it entirely inside their own AWS account and VPC through a signed Helm chart and an AWS CDK template that stands up an Amazon EKS Auto Mode cluster. The platform evaluates every agent action against policy before execution, returns one of five governance decisions, and seals each session with a tamper-proof Proof Certificate, giving regulated-sector buyers runtime enforcement and auditable evidence without sending agent data to a third-party SaaS.


What Was Announced

OpenBox is now available on AWS Marketplace as a self-hosted AI agent governance platform, carrying the Deployed on AWS designation. Enterprises can procure OpenBox through AWS Marketplace and deploy it entirely inside their own AWS account and VPC, with the governance control plane, policies, and audit trail running inside the customer's environment. The listing sits across the AWS Marketplace AI Security, Cloud Governance, and Security categories.

The product is built for engineering and platform teams deploying AI agents in regulated or data-sensitive environments: financial services, healthcare, public sector, and enterprises with data-residency obligations that rule out sending prompts, outputs, or audit data to a third-party SaaS. For those buyers, OpenBox now lives inside the same procurement, billing, and infrastructure surface they already use for their AWS estate.

Why Runtime Enforcement, Not Post-Hoc Observation

AI agents act at runtime. They call tools, move money, and touch customer data in the moment. Tools that watch what agents did after the fact catch issues only once the action has already happened. For a bank processing a payment, a hospital routing a patient record, or a public-sector agent initiating a case action, 'after the fact' is where the regulatory exposure lives.

OpenBox is designed to evaluate each agent action against policy before it executes, and to return one of five governance decisions. A non-compliant operation can be stopped, paused for human approval, run inside a sandboxed environment, or escalated to terminating the entire agent session. The record of each decision is written into an immutable audit trail and sealed with a cryptographic proof certificate once the session completes.

The architectural distinction matters for compliance teams. Observability and logging describe what agents did. Runtime governance decides what agents are allowed to do, and holds a signed record that stands up to independent verification.

The Five Governance Decisions

Every evaluated agent action in OpenBox resolves to one of five governance decisions, with HALT taking precedence over BLOCK, BLOCK over REQUIRE_APPROVAL, REQUIRE_APPROVAL over CONSTRAIN, and CONSTRAIN over ALLOW

ALLOW permits the operation to proceed normally. CONSTRAIN executes the action within a sandboxed environment rather than allowing or refusing it outright. REQUIRE_APPROVAL pauses the operation and routes it to a designated human reviewer before it proceeds. BLOCK refuses the specific operation while the agent continues. HALT terminates the entire agent session.

The decision is produced by evaluating the action against versioned policy bundles, written in OPA/Rego, that security and governance teams manage centrally. Behavioral Rules sit alongside those policies to detect multi-step patterns across a session, which single-event checks cannot catch on their own. Each decision is written to the audit trail with its verdict, reason, timestamp, and the identifiers needed to trace it back to the policy in force at the time.

Deployed on AWS: How the Install Works

OpenBox is delivered as a signed Helm chart (OCI) with every container image pinned by digest and an SBOM published per release. An AWS CDK template provisions an Amazon EKS Auto Mode cluster and installs the full stack end to end.

Customers bring their own VPC, subnets, Route 53 hosted zone, and ACM certificate; the CDK template imports existing networking rather than creating new infrastructure. Public endpoints can be restricted to a customer-supplied IP allowlist enforced at the load balancer, or made VPC-internal only, so the governance control plane runs on the same network footprint as the workloads it governs.

Supported Kubernetes services are Amazon EKS and Amazon EKS Anywhere. Optional GPU node support is available for LlamaFirewall acceleration, used for prompt-injection and jailbreak inspection where that defence is in scope.

For security and infrastructure teams, the shape of the install is deliberate: signed artefacts, pinned images, published SBOMs, customer-controlled networking, and no outbound dependency on an external governance SaaS to make a runtime decision.

Auditable Evidence Without Sending Agent Data to a Third-Party SaaS

OpenBox records every governance decision in an immutable audit trail inside the customer's AWS account. Records cannot be modified after creation. Each session's governance events are hashed into a Merkle tree and digitally signed, producing a per-session Proof Certificate that confirms no governance data was altered after the fact.

By default, signing uses AWS KMS with an ECDSA NIST P-256 key, with one signing key per agent, managed in the customer's own KMS. For organisations that require signing inside their own infrastructure, such as a Trusted Execution Environment, OpenBox supports an external attestation endpoint. In both cases the signing key and the signed record live where the customer controls them.

The Proof Certificate carries the Merkle root, the digital signature, and the event count for the session, and sits inside the Verify phase of the OpenBox Trust Lifecycle. The lifecycle has five continuous stages, in order: Assess, Authorize, Monitor, Verify, Adapt. Each phase feeds the next: observed behaviour updates the agent's Trust Score, which then informs the next assessment.

For auditors and regulators, that combination of immutable trail and signed, independently verifiable certificate is designed to answer two questions that logs alone cannot: what happened, and can we prove it has not been changed since.

Procurement Through AWS Marketplace

Enterprises purchase OpenBox through AWS Marketplace with consolidated AWS billing. Private Offers for custom terms are available directly from the OpenBox team, extended through AWS Marketplace to the buyer's AWS account on request. The Deployed on AWS designation on the OpenBox listing means Marketplace spend on OpenBox may count towards customers' existing AWS Enterprise Discount Program commitments, subject to AWS's current eligibility rules; buyers should confirm current status in writing with their AWS account team.

For procurement and finance leads, that puts governance alongside the rest of the customer's AWS infrastructure in a single contracting and billing surface, rather than treating it as a separate SaaS line item to onboard, pay, and audit independently.

Works With the Agent Stack Enterprises Already Run

OpenBox integrates with the agent orchestration frameworks enterprise teams already use, including Temporal, LangGraph, LangChain, CrewAI, Mastra, and n8n, through one SDK with no architectural changes to existing agent code. Integration takes three steps: generate an API key, install the SDK, and configure governance rules.

The design brief for OpenBox is to add the governance layer without asking engineering teams to rebuild their agents. On a Temporal workflow, the plugin wraps the worker. On a LangGraph or CrewAI agent, the SDK registers at the orchestration layer. In every case, the agent's existing definition stays as it is.

Tahir Mahmood on Why Self-Hosted Runtime Governance Is the Right Model

โ€œEnterprises buying AI agent governance in regulated sectors have been asked to send their prompts, outputs, and audit records to a third party and trust the trail that comes back. We built OpenBox so they do not have to. The agent, the policy, the evidence, and the signing key all live inside the customer's own AWS account. The runtime enforcement happens before the action completes, not after it has settled, and the record is sealed with cryptographic proof the customer can verify themselves. That is the model we think the next generation of enterprise AI agents should be governed with, and AWS Marketplace is the right place to put it in front of the buyers who need it.โ€

said Tahir Mahmood, Co-founder and CTO at OpenBox.

About OpenBox

OpenBox is an AI agent governance platform for enterprises deploying AI agents in regulated and data-sensitive environments. Founded by Tahir Mahmood (Co-founder and CTO) and Asim Ahmad (Co-founder). OpenBox provides a self-hosted runtime trust layer that enforces policy before agent actions execute and records them in a cryptographically signed, auditable trail, integrating with the leading agent orchestration frameworks via a single SDK. Documentation is at docs.openbox.ai. The AWS Marketplace listing is at aws.amazon.com/marketplace/pp/prodview-2hy6xromcc3sc. To book a demo, visit meetings-na2.hubspot.com/openbox/demo-call.


Sources

1. OpenBox AI, "OpenBox AI - Runtime AI Governance Platform," AWS Marketplace listing, https://aws.amazon.com/marketplace/pp/prodview-2hy6xromcc3sc, accessed 23 October 2026.

2. OpenBox, "Governance Decisions," https://docs.openbox.ai/core-concepts/governance-decisions, accessed 23 October 2026.

3. OpenBox, "Trust Lifecycle," https://docs.openbox.ai/trust-lifecycle, accessed 23 October 2026.

4. OpenBox, "Attestation & Cryptographic Proof," https://docs.openbox.ai/administration/attestation-and-cryptographic-proof, accessed 23 October 2026.

5. OpenBox, "Compliance & Audit," https://docs.openbox.ai/administration/compliance-and-audit, accessed 23 October 2026.

6. Tahir Mahmood, "Governing Muse Code with OpenBox," OpenBox Blog, 12 October 2026, https://www.openbox.ai/blog/govern-muse-code-enterprise-openbox, accessed 23 October 2026.

7. OpenBox, "Temporal and AI Agent Governance," OpenBox Blog, 13 July 2026, https://www.openbox.ai/blog/temporal-and-ai-agent-governance, accessed 23 October 2026.

8. AWS Marketplace, "Procurement with AWS Marketplace," https://aws.amazon.com/marketplace/features/procurement, accessed 23 October 2026.

9. OpenBox, "About OpenBox," https://www.openbox.ai/about, accessed 23 October 2026.


Trustworthy AI
Starts Here

By submitting your email, you agree to our Privacy Policy and consent to receiving updates from us

Trustworthy AI
Starts Here

By submitting your email, you agree to our Privacy Policy and consent to receiving updates from us

Trustworthy AI
Starts Here

By submitting your email, you agree to our Privacy Policy and consent to receiving updates from us

Trustworthy AI
Starts Here

By submitting your email, you agree to our Privacy Policy and consent to receiving updates from us