Governing AI Agents Inside Your Own AWS Account: How OpenBox Enforces Policy at Runtime

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

How do you enforce governance on an AI agent at runtime on AWS?

You deploy a policy-enforcement layer that sits in front of every agent action routed through it, inside the AWS account the agent runs in. OpenBox installs through AWS Marketplace as a signed Helm chart on Amazon EKS. Each tool call, model request, or cross-system action that passes through the OpenBox governance integration is evaluated against centrally managed policies before it completes, and the decision executes before the action reaches its target.

The practical shape of that is three things. First, a verifiable identity for every agent so unregistered or mis-credentialed agents are refused rather than silently allowed. Second, an evaluation step that returns one of five decisions on every gated action. Third, a tamper-proof record of each decision, signed per session, so an auditor can verify what the agent was permitted to do and what it actually did.

Why agent governance is a runtime problem

Observing an agent after it has acted is useful. It is not sufficient. When the agent is the thing taking the action, the window between the model's choice and the real-world effect is where the control has to live. A log of what happened is evidence, not prevention.

This is the gap between a probabilistic model and a deterministic deployment. The model may produce an output that implies a particular tool call; the deployment decides whether that call is permitted, routed, approved, or refused. Runtime enforcement puts a deterministic floor beneath a probabilistic ceiling, so the agent can be creative within the policy, not outside it.

OpenBox is built around that distinction. Every event routed through the governance integration, whether a tool call, a model request, or a cross-system interaction, is evaluated by the platform before the action reaches its target. On the identity side, the AWS Marketplace listing describes the posture explicitly: unregistered or mis-credentialed agents are refused rather than silently allowed, which it labels a fail-closed default. (Related reading: Runtime Enforcement Comes Before Compliance and Logging Is Not AI Governance.)

Five governance decisions, evaluated before the action

Every evaluated action returns one of five decisions. The decision executes before the tool call or model request reaches its target. Policies are evaluated centrally against versioned bundles, using Open Policy Agent.

When several policies apply to the same event, the strictest wins. Precedence runs HALT, BLOCK, REQUIRE_APPROVAL, CONSTRAIN, ALLOW: HALT ends the session, BLOCK refuses the one action, REQUIRE_APPROVAL waits on a human, CONSTRAIN runs the action inside a sandbox, and ALLOW lets it through.

The policies themselves are not just allow-or-deny rules. The governance stack has three layers: OPA/Rego policies handle stateless, per-event evaluation; Behavioral Rules track patterns across multiple events within a session, such as repeated attempts to reach a restricted resource; and Guardrails provide content-level checks, including PII detection, content filtering, toxicity screening, and banned-word enforcement. See Most AI Governance Stacks Are Incomplete for how these layers fit together, and the Governance Decisions reference for the full policy semantics.

The Trust Lifecycle: Assess, Authorize, Monitor, Verify, Adapt

The Trust Lifecycle is OpenBox's operating loop. It moves each agent through five continuous phases, from baseline risk through runtime observation to ongoing adaptation.

Assess baselines inherent risk from the agent's capabilities and access, across 14 parameters, and places the agent in a Trust Tier. Authorize applies the guardrails, OPA policies, and behavioral rules that govern what the agent is allowed to do. Monitor captures runtime behaviour: sessions, metrics, telemetry. Verify validates whether what the agent did stayed aligned with what it was supposed to do, and seals the record with attestation. Adapt is where that observed behaviour feeds back into governance: per the Trust Lifecycle docs, Behavioral and Alignment scores update as the agent operates, Trust Tiers adjust automatically, and policy suggestions emerge from the patterns the platform surfaces.

Underneath, the Trust Score aggregates on a 0 to 100 scale. The formula is explicit: Risk Profile at 40 percent, plus Behavioral at 35 percent, plus Alignment at 25 percent. Scores map to tiers: Tier 1 Trusted (90 to 100), Tier 2 Confident (75 to 89), Tier 3 Monitor (50 to 74), Tier 4 Restrict (25 to 49), and Untrusted (0 to 24). The tier determines how strict the applied policies are, and the tier is a runtime variable, not a static label. (For how the score is produced and what moves it, see Trust Score 0 to 100.)

Running OpenBox inside your AWS account

OpenBox deploys entirely inside your AWS account and VPC. The AWS Marketplace listing records the delivery method as a signed Helm chart (OCI). Every container image is pinned by digest, and an SBOM is published per release.

An AWS CDK template provisions an EKS Auto Mode cluster and installs the full stack end to end. The template imports your existing networking rather than creating new infrastructure: your VPC, your subnets, your Route 53 hosted zone, and your ACM certificate. Public endpoints are restricted to a customer-supplied IP allowlist enforced at the load balancer, or can be made VPC-internal only. Optional GPU node support is available for LlamaFirewall acceleration, where prompt and response inspection benefits from GPU.

Supported Kubernetes services, per the AWS Marketplace listing, are Amazon EKS and Amazon EKS Anywhere. Identity integration uses Keycloak-based SSO, with a dedicated realm per organisation.

The OpenBox control plane and its stored data sit inside your AWS account by design. The AWS Marketplace listing describes the deployment as keeping data within your environment. Where prompt, response, and audit-data flows actually go still depends on three choices you make at deployment: the model, the attestation path, and the telemetry mode. A closed-source commercial model called through a hosted API (for example OpenAI or Anthropic) sees those prompts and responses on each call; an open-source model self-hosted inside your account does not. If you configure an external attestation endpoint, OpenBox sends the signed session root to that service rather than to AWS KMS. And OpenBox itself can run in one of two self-hosting modes: Home-phone, which sends telemetry, reports, and analytics back to OpenBox for support and product improvement; or Air-gapped, which sends nothing back. Pick each setting to match your residency rules.

Works with your existing agent stack

OpenBox integrates with the orchestration frameworks you already use. The AWS Marketplace listing names Temporal, LangGraph, LangChain, CrewAI, Mastra, and n8n today, with more integrations on the way, and describes the integration as “one SDK, no architectural changes”.

The integration path has three steps: generate an API key, install the SDK, and configure governance rules. The frameworks you run on EKS do not need to change shape to be governed. Published walkthroughs cover the per-framework specifics: LangGraph governance in three steps, CrewAI governance with Trust Scores, the OpenBox and Temporal partnership, and the Mastra integration for TypeScript agents.

For long-running agent work, OpenBox uses Temporal-backed workflows for attestation, governance, and observability. Agents that take minutes or hours survive restarts and remain traceable across the full execution.

Audit, proof, and Session Replay

Every governed action, decision, and cross-system interaction is recorded in the platform's tamper-proof ledger with full lineage tracking. That is the baseline. The proof layer runs on top of it.

Each governed session produces a signed Proof Certificate. OpenBox builds a Merkle tree from all session events, then signs the root using AWS KMS with an ECDSA NIST P-256 key, or through an external attestation endpoint if one is configured. The result is tamper-evident evidence an auditor can verify independently of OpenBox itself.

Session Replay sits in the Verify stage. It reconstructs the operation context and the decision timeline for a session, so a reviewer can walk through what the agent asked to do, which policies evaluated the request, and what the verdict was at each step. Combined with the per-agent Trust Score, that gives two complementary evidence streams: the Proof Certificate establishes integrity of what happened in this session; the Trust Score aggregates risk, behavioural compliance, and alignment into a tier that governs how strictly future actions are handled. (See AI Governance Needs Proof, Not Logs and the docs on Attestation and Cryptographic Proof for the detail.)

Procuring OpenBox on AWS Marketplace

OpenBox is listed as "OpenBox AI - Runtime AI Governance Platform" and carries the Deployed on AWS designation. The current Enterprise plan is a 12-month contract covering unlimited agents, with GPU support included. Additional AWS infrastructure costs apply separately (the listing points buyers to the AWS Pricing Calculator for the EKS cluster and related resources). Billing is consolidated through your existing AWS account via the AWS Marketplace product page, where the current terms and the vendor EULA are shown directly. To see OpenBox in action against your own agent stack, book a demo with the OpenBox team.

Frequently asked questions

Does OpenBox send my prompts or outputs outside my AWS account?

The OpenBox platform itself runs inside your AWS account and VPC. Public endpoints are restricted to a customer-supplied IP allowlist at the load balancer, or can be made VPC-internal only. The AWS Marketplace listing describes the deployment as keeping data within your environment. Three settings control whether anything else leaves. First, the model: a closed-source commercial model called through a hosted API sees prompts and responses on each call, while an open-source model self-hosted inside your account does not. Second, attestation: if you configure an external attestation endpoint, OpenBox sends the signed session root to that service rather than to AWS KMS. Third, the self-hosting mode for OpenBox itself: Home-phone sends telemetry, reports, and analytics back to OpenBox for support and product improvement; Air-gapped sends nothing back. Verify each setting against your residency requirements before go-live.

Which Kubernetes services does OpenBox support?

Two, per the AWS Marketplace listing: Amazon EKS and Amazon EKS Anywhere. The delivery is a signed Helm chart (OCI) with container images pinned by digest and an SBOM published per release. An AWS CDK template provisions an EKS Auto Mode cluster and installs the full stack, importing your existing VPC, subnets, Route 53 hosted zone, and ACM certificate.

What frameworks does OpenBox integrate with?

One SDK, no architectural changes. The AWS Marketplace listing names Temporal, LangGraph, LangChain, CrewAI, Mastra, and n8n today, with more integrations on the way. Integration is three steps: generate an API key, install the SDK, configure governance rules. The framework running your agent does not need to be rearchitected.

How is agent-action evidence produced and verified?

Every governed session produces a signed Proof Certificate. OpenBox constructs a Merkle tree from all session events, then signs the root using AWS KMS with an ECDSA NIST P-256 key, or through a configured external attestation endpoint. The certificate is tamper-evident, so an auditor can verify it independently of OpenBox.