AegisX9

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. The repository is private today and will be published; until then the CI gates above are the proof of process.

Architecture

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 1In development in a private lab; nothing deployed
• Apache-2.0Licence; the source is private today and will be published
• Signed + SBOMRelease images: keyless signing, signed-image admission policy
• 3 phasesRoadmap: gateway and guards, agent control, governance mapping

Qualitative by design: nothing is deployed yet, 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: private today, to be published under Apache-2.0
• Related: agent-guardrails and ops-orchestrator are where the guard and gate ideas were first tried