Contact

Aegis4A · Authority before automation

The AI governance gateway for agents, LLMs and enterprise systems

Aegis4A runs in your own cloud and sits in front of every model and system your AI agents use. Each request is checked against your rules, held for a person when needed, and recorded before it runs.

Book a demo How Aegis4A works
Aegis4A at the centre of four boundaries: Answer, Action, Authority and Audit.

Drop-in attachment

Change two settings, not your agents

Point the agent at Aegis4A and give it an Aegis4A key. Its code and SDK stay the same.

  • Aegis4A holds the real model and system credentials.
  • With the documented network isolation in place, agents can reach only Aegis4A, so there is no way around it.
agent settings
# Model calls go through Aegis4A
OPENAI_BASE_URL=https://aegis4a.example.com/v1
OPENAI_API_KEY=a4a_••••••••••••

# System calls go through Aegis4A too
PAYER_API_BASE_URL=https://aegis4a.example.com/gw/payer

Architecture

One gateway between your agents and everything they can affect

Aegis4A architecture AI agents and applications send requests only to the Aegis4A governance gateway, which applies Answer, Action, Authority and Audit checks and mediates all access to model providers and enterprise systems. Reviewers approve or reject gated actions. Requests, policy decisions and execution events go to the audit store, with a separate off-site copy. 01 SOURCE AI Clients Requests originate here AI agents Assistants & tools Applications User-facing interfaces No direct downstream access 02 TRUST BOUNDARY Governance Gateway Aegis4A checks on every request Answer Response controls Action Execution boundaries Authority Policy & approval Audit Evidence & traceability All outbound access is mediated by the gateway 03 DESTINATIONS Controlled Services Reached only through gateway Model providers AI inference endpoints Enterprise systems Apps, records & data Policy-checked calls and responses Request 04 HUMAN IN THE LOOP Reviewer approval Allow / reject gated actions When human review is required 05 EVIDENCE LAYER Event & audit storage Requests Policy decisions Execution events Trace Decision record Activity record 06 SEPARATE COPY Off-site archive / backup Logical separation of retained evidence Kept separately for tamper evidence Audit events Approval result Controlled flow Separate archival flow Conceptual architecture — not a deployment topology
Aegis4A architecture AI agents and applications send requests only to the Aegis4A governance gateway, which applies Answer, Action, Authority and Audit checks and mediates all access to model providers and enterprise systems. Reviewers approve or reject gated actions. Requests, policy decisions and execution events go to the audit store, with a separate off-site copy. 01 SOURCE AI Clients Requests originate here AI agents Assistants & tools Applications User-facing interfaces No direct downstream access Request 02 TRUST BOUNDARY Governance Gateway Aegis4A checks on every request Answer Response controls Action Execution boundaries Authority Policy & approval Audit Evidence & traceability All outbound access is mediated by the gateway 03 DESTINATIONS Controlled Services Reached only through gateway Model providers AI inference endpoints Enterprise systems Apps, records & data Policy-checked calls and responses Approval result Audit events 04 HUMAN IN THE LOOP Reviewer approval Allow / reject gated actions When human review is required 05 EVIDENCE LAYER Event & audit storage Trace Decision record Activity record 06 SEPARATE COPY Off-site archive / backup Logical separation of retained evidence Kept separately for tamper evidence Controlled flow Separate archival flow
Answer

Answers must cite approved sources. Missing or unknown citations are flagged or withheld.

Action

Rules decide: execute, recommend only, require approval, escalate or block. Anything else is blocked.

Authority

Reviewers approve tickets one time or always. Escalations need a manager.

Audit

Every step is logged before it runs, hash-chained and copied off the server.

Built to fail safe

Safety that doesn’t depend on the model behaving

Fail-closed

If a governance check can’t run, the request is refused.

Rule-based decisions

Rules decide. AI judgment is advisory by default and always recorded.

Isolated governance data

Rules and approvals sit in separate databases agents can’t reach.

No provider-side tools

Tools that would run on the model provider’s side are refused.

Inside the console

Reviewers see exactly what an agent asked to do

Screens from Aegis4A running a prior authorization demo with fictional data.

Aegis4A ticket A4A-000003: a prior authorization request held for approval, showing the exact request, the earlier approved request, and the one changed field, service code 97110 to 97112, with Approve one-time, Approve always and Reject buttons.
A ticket shows the request, the earlier approval it nearly matches, and the field that changed.
Aegis4A ticket list with one open prior authorization ticket, one escalated claims adjustment approved always, and two prior authorizations approved one time.
Tickets: open, escalated and decided requests.
Aegis4A active approvals list showing an always approval for claims adjustments, granted by a manager, with a Revoke button.
Approvals: who granted what, with one-click revoke.
Aegis4A audit log showing a successful chain verification, followed by hash-chained events such as policy.decision, gw.request, gw.forwarded and approval.applied.
Audit log: verify the hash chain, filter and export.

Works with

The model providers your agents already use

One OpenAI-compatible endpoint. Agents keep their SDKs; only the base URL and key change.

See it live

Watch Aegis4A hold, approve and audit a live agent request

Book a demo How it works