Home Projects AegisX9

platformIn progress

AegisX9

A secure AI gateway with governance for the enterprise

Role
Creator and lead engineer
Period
2026 – present
Stack
  • AI security
  • LLM gateway
  • Guardrails
  • Audit
  • Supply chain
  • Kubernetes
  • GitOps
  • Python

Source on GitHubLive

One policy-enforced gateway for all LLM traffic and agent actions: SSO and per-team or per-agent keys, a model allowlist, budgets and rate limits, input guards for prompt injection and secret or PII redaction, output data-leak prevention, a tamper-evident audit log, red-teaming as a CI gate and a signed, GitOps-delivered supply chain. Phase 1 is in development in a private lab; developer workspaces, agent and tool control and governance mappings follow on the roadmap. Apache-2.0, source on GitHub.

AegisX9 is the project I am building now. The premise is that an enterprise should be able to use AI without every prompt being a data-loss event and every agent being an unreviewed operator: one gateway, every model call and agent action through policy, guards and audit. Phase 1 is in progress. The product site is aegisx9.com.

Status today: the Phase 1 gateway runs in private staging and has served real Claude requests. It holds no static model API keys: it gets short-lived Claude credentials through workload identity federation, with its own identity issued by Vault. Per-team budgets and a hard spend cap are enforced at the gateway, and only signed images are admitted to the cluster. User sign-in with SSO, the public chat and the red-team CI gate are still being built.

Problem

Four things go wrong when teams adopt models directly. Untrusted text in a document, web page or tool result can carry instructions that a model follows as if they came from the user. Credentials and personal data pasted into a prompt leave the organisation the moment the request is sent, and a response can carry data back that should have stayed inside. An agent with broad tool access can take actions nobody reviewed, at machine speed. And with every team calling providers on its own, nobody can say which models are in use, by whom, or at what cost.

What I built

Phase 1 is a policy-enforced gateway and the delivery pipeline around it:

  • Gateway. One entry point for all LLM traffic behind SSO, with per-team or per-agent keys, a model allowlist, budgets and rate limits. A call that fails policy is refused and logged.
  • Input guards. Prompt-injection and jailbreak detection, plus secret and PII redaction before anything leaves.
  • Output guards. Data-leak prevention on every model response.
  • Audit. A tamper-evident record of every prompt, decision and tool call, without storing secrets.
  • Red-teaming in CI. Adversarial prompt suites run as a gate, so a regression in the guards fails the build.
  • Supply chain. Continuous checks on every change: linting, type checks, unit tests with a coverage gate, secret scanning, SAST, dependency audit, infrastructure-as-code and manifest linting, and a container vulnerability scan. Release images carry an SBOM, are signed keylessly, pass an admission policy that only runs signed images, and are delivered by GitOps.

Phase 1.5 (planned) adds per-developer workspaces: signed, digest-pinned images with a locked assistant policy baseline, strong sign-in and short-lived credentials, so a laptop holds nothing a model could be handed. Phase 2 puts an MCP/tool gateway in the request path with per-agent allowlists and human approval for risky actions. Phase 3 maps the controls to the frameworks enterprise reviewers ask about (OWASP Top 10 for LLM Applications 2025, MITRE ATLAS, NIST AI RMF / AI 600-1, ISO/IEC 42001-style policy) and adds an AI system inventory and risk register. Both are roadmap items, not built.

The licence is Apache-2.0 and the source is public on GitHub (https://github.com/mchasse73/aegisx9), including the CI gates above.

Architecture

AegisX9: one request through the gateway Clients, apps and agents call the gateway, which applies single sign-on, per-team or per-agent keys, a model allowlist, budgets and rate limits. The request passes through input guards (prompt-injection and jailbreak detection, secret and PII redaction) to an allowed model provider; the response passes through output guards (data-leak prevention) back to the caller. The gateway and the output guards write to a tamper-evident audit log that stores no secrets. A dashed Phase 2 roadmap box shows a tool gateway with per-agent allowlists and human approval for risky actions. Clients apps, agents, IDEs team or agent key Gateway SSO, per-team keys model allowlist budgets, rate limits policy decision Input guards injection, jailbreak secret + PII redaction Output guards data-leak prevention on every response screened response back to the caller Model providers allowed models only hosted or self-hosted Audit log tamper-evident: every prompt, decision and tool call no secrets stored Phase 2, roadmap Tool gateway MCP, allowlists Approval risky actions Solid: Phase 1, in development in a private lab. Dashed: Phase 2, roadmap; not built yet. Highlighted: the guard path.
One request through AegisX9: a client calls the gateway, which applies identity, allowlist and budget policy; input guards screen the prompt and the response passes output guards on the way back; the gateway and the guards write to a tamper-evident audit log. The dashed tool gateway with human approval is Phase 2, roadmap.

The diagram shows one request. A client, app or agent calls the gateway with a key issued behind SSO; the gateway applies identity, allowlist, budget and rate-limit policy; the input guards screen and redact the prompt; the request goes to an allowed provider; the response passes the output guards on the way back to the caller. The gateway and the guards write to the audit log. The dashed tool gateway with human approval is Phase 2.

By the numbers

  • Phase 1Gateway running in private staging; in progress
  • Apache-2.0Licence; the source is public on GitHub
  • Signed + SBOMRelease images: keyless signing, signed-image admission policy
  • 3 phasesRoadmap: gateway and guards, agent control, governance mapping

Qualitative by design: the gateway runs in private staging, not production, so there are no production figures to report.

What I'd do differently

I would write the governance mapping alongside each control from the start, so the audit log reads as reviewer evidence on day one instead of becoming a Phase 3 retrofit. I would treat the agent tool gateway as part of the request path in the first design rather than an add-on: per-agent keys and budgets are only half of agent control. And I would publish the repository earlier, with the CI gates as the proof, rather than waiting for a polished first release.

Links

  • Product site: https://aegisx9.com
  • Source: github.com/mchasse73/aegisx9 (Apache-2.0)
  • Related: agent-guardrails and ops-orchestrator are where the guard and gate ideas were first tried