Architecture

System boundary

Aethis is an AI-agent governance platform designed to check supported model and tool calls before execution. Its authority layer is designed to sit between an AI agent and the systems the agent can affect. A governed workflow can include model providers, MCP servers, SaaS APIs, internal services, and other supported execution surfaces.

The design separates two concerns:

1. Control plane: where organizations will define workspaces, agents, connections, policies, reviewers, retention, and administrative settings.
2. Enforcement path: where supported actions are designed to be identified, evaluated, held or refused when required, executed through their destination, and correlated into an Action Record.

Trust boundaries

The design treats organization, workspace, agent identity, provider credentials, administrative access, and downstream connections as separate trust boundaries. A credential that makes a destination reachable is not meant to grant an agent authority to take every action available on that destination.

Identity and credentials

Agent-facing credentials are designed to be scoped to the Aethis route and tenancy they belong to. Raw upstream provider credentials are designed to be kept separate from the credential used by the agent. Identity is designed to be resolved from authenticated route context rather than trusted from an arbitrary caller-supplied label.

Governed action flow

A supported governed action is designed to follow one ordered path:

1. Resolve the caller and workspace context.
2. Normalize the destination, operation, and relevant arguments.
3. Evaluate the policy version in force.
4. Hold the action for an eligible reviewer when policy requires it.
5. Issue or refuse authority for the specific action.
6. Attempt execution through the supported destination.
7. Record the decision, execution state, outcome, and evidence metadata.

The goal is to preserve the decision context while it still exists rather than reconstructing it later from unrelated logs.

Action Records are designed to be tamper-evident: each record would be written to append-only evidence storage and carry an HMAC integrity hash chained to the previous record, so a changed or missing record breaks the chain. Independent verification without trusting an Aethis-held key is a later goal.

Failure and uncertainty

The design does not treat missing evidence as proof of success. If a consequential downstream effect cannot be confirmed, the evidence model is designed to represent that uncertainty explicitly instead of silently converting it to success or failure.

Deployment and operations

The current architecture design places governed-traffic processing at the Cloudflare edge, control-plane and evidence storage in Supabase PostgreSQL, and low-latency policy and cache state in Upstash Redis.

Production changes are expected to move through reviewed source control, automated validation, and traceable deployment history. Public service status and incident communication are separated from this architecture document.

Scope and related documentation

Once built, these controls apply only to supported calls routed through Aethis. Calls that bypass the governed route are outside that enforcement boundary. This architecture description is not a certification or independent audit.

Read AI-agent governance and authority, how approval gates work, and Action Record fields. The Trust Center separates product boundaries from assurance evidence.