ai-guardby OVPT
GitHub

TECHNICAL / AI-GUARD

Understand
the boundaries.

What decides. What executes.
What leaves a trace.

An overview of the documented architecture, its limits and the project’s goals.

Explore the code on GitHub ↗

Three roles.
Distinct boundaries.

A Rust foundation.
An interface for clarity.
Adapters for practical use.

EXPLORE THE MODEL

Your machine.
Your rules.

Documented local architecture.
Docker / Podman, rootless by default.

DIAGRAM 01

Who launches. Who observes.

The broker commands Docker or Podman, which creates and inspects the worker. The worker uses a working copy in a session volume. The broker sends events to the Rust collector, which stores the SQLite audit and exposes read access to the dashboard. The dashboard cannot launch commands.
Simplified logical flows for the documented local workflow. The broker and engine remain trusted; runtime configuration must be checked on the host.
Sources and scope

Provided README: product capabilities, reading actions and events, and exporting, verifying and stopping. The HTTP ingress relay is omitted for clarity; it is separate from the proposed inter-worker application relay.

Provided documentation · 29 October 2026

The documented local architecture separates the trusted broker, the advisory dashboard and Docker / Podman workers. Rootless is the default mode. This overview does not replace testing the runtime and its configuration.

DOCUMENTED LOCAL
RUSTTYPESCRIPT / JSDOCKERPODMANKUBERNETES CLOUD GOAL

Know what
is controlled.

The interface explains. The broker decides whether to launch. The runtime enforces execution restrictions.

These roles are not interchangeable. Choosing Rust, keeping a log or using an AI decision does not prove containment.

DIAGRAM 02

Decide before executing.

An authenticated request reaches the broker. Required auditing and policy precede launch. An approval permits preparing the copy and launching the worker through the runtime. Denial, pending approval or unavailable auditing blocks workload launch without a fallback to host execution. A result without evidence remains unknown.
A diagram of the decision contract. Control applies to the invocation submitted to the broker, not to each internal command run by an agent. Failure scenarios require their own validation.
Sources and scope

Provided README: capabilities, security profiles, optional Jev and known limits. Architecture: section 6, action lifecycle and recovery; a documented contract is not execution evidence.

Provided documentation · 29 October 2026
01

Working copy & runtime

The README describes a filtered copy in a session volume, an unprivileged worker, a read-only root filesystem and networking disabled by default. Exports go to a new destination.

VERIFY ON THE HOST

Inspect mounts, permissions and restrictions on the chosen engine. The broker, engine and their administrator remain trusted.

02

Decision before launch

The strict, review and observe profiles govern the invocation submitted to the broker. The request and its decision are logged; a denial or an unavailable mandatory audit blocks this workflow.

DEFINED SCOPE

This decision does not control every internal command of an agent or script individually. Optional bridge networking does not provide application-level filtering.

03

Audit & observation

The SQLite audit is independent of the worker. It distinguishes requests, decisions, observed starts and results. Provider-reported claims remain labeled as such.

VISIBLE COVERAGE

The documented Codex/Claude outputs are normalized after the session. A missing value remains unknown. Persistence, recovery and integrations each need their own evidence.

04

Jev, optional

The README describes a Rust client for Jev, disabled by default. It supports decision-making; a deterministic denial cannot become an approval.

SERVICE TO VALIDATE

Tests against the real service still need to be confirmed. Jev replaces neither the broker nor runtime containment.

DIAGRAM 03

A copy to work on. An export to review.

The original project supplies a filtered copy in a session volume. The agent works in this copy. An explicit export writes to a new destination outside the original project without replacing existing files. The user then chooses whether to bring the changes back.
The original project is not mounted in the worker. Import and export checks have limits; a filtered copy is not a universal secret scanner.
Sources and scope

Provided README: capabilities, exporting, verifying and stopping, and known limits. Architecture: section 3, separating files and tenants.

Provided documentation · 29 October 2026

One permission.
One exchange.

Two workers for client A.
One for client B.
Choose a route. Test the rule.

EDUCATIONAL SIMULATION
AI-GUARD / SANDBOX LABSIMULATED DATA
CLIENT A2 WORKERS
A1SOURCE
A2DESTINATION
CLIENT B1 WORKER
B1OTHER TENANT
01 / CHOOSE A ROUTE
02 / A1 → A2 PERMISSION
The rules are set.

Run an exchange to see the decision and its audit trail.

READY
DEMONSTRATION LOG
  1. No simulated exchanges yet.

This interaction explains the intended permission model. Its relay is not presented as delivered. It demonstrates neither runtime containment nor the product’s security validation.

A clear direction.
Evidence still needed.

The project is open source under Apache-2.0 and remains in development.

This overview distinguishes documented mechanisms from project goals and their validation status. It does not replace current results in the repository.

DOCUMENTED

Local workflow

The working copy, Rust broker, Docker/Podman workers, dashboard, audit and export are described in the README. Check the repository for a version’s availability and limits.

TO VALIDATE

Real execution

Each system/engine combination, agent integration and failure scenario needs its own reproducible results.

GOAL

Relay & cloud

The multi-client registry, quotas, application relay and usage accounting are not announced as delivered. Kubernetes orchestration and the cloud offering still need to be built and validated.

The production-readiness documentation corrects earlier claims of delivered features. Historical tests do not automatically validate the current version. The files docs/engineering/CURRENT_STATE.md and docs/engineering/VALIDATION.md are the progress references identified by the project.