How Aegis is structured

Three zones. One boundary. Complete control.

Three-zone model

Runtime Zone
AI agents operate here
AI Agent
e.g. OpenClaw
AI Agent
any runtime
purpose declaration
Boundary
Aegis Gateway
Policy evaluation · Access control · Audit recording · Disclosure limiting
controlled access
Protected Data Zone
Encrypted Capsules
Audit Logs
Policy Config

Architecture principles

No direct access

AI agents in the runtime zone cannot reach protected data directly. All paths go through the Gateway.

Single trust boundary

The Aegis Gateway is the only entry point to protected data. There is no second path, no debug backdoor, no test bypass.

Purpose evaluation

Before any data is returned, the Gateway evaluates the declared purpose against policy. Mismatched purposes are denied.

Minimized disclosure

Even when access is allowed, the Gateway returns only the fields required for the declared purpose.

Chain-hash audit

Every event is recorded in sequence with cryptographic chaining. Missing entries are detectable. Tampering is detectable.

Controlled outbound flow

Data leaving the protected zone is governed. The Gateway controls what crosses the boundary outward.

Request lifecycle

Every data access follows the same structured flow, whether the request is allowed or denied.

Agent declares purpose

The AI agent submits a data access request with a declared purpose to the Aegis Gateway.

Gateway evaluates against policy

The Gateway checks the declared purpose against the configured access policy for the requested data.

If allowed: minimal data returned

Only the fields required for the declared purpose are returned. The access event is recorded in the audit log.

If denied: empty response

No data is returned. The denial event is recorded in the audit log with the same integrity guarantees.

Tamper-proof audit entry created

In both cases, a chain-hash audit entry is created. The audit trail is chronologically sealed and tamper-detectable.

See where Aegis applies.