Phase 1 · in development
Secure AI gateway with governance for the enterprise
Use AI in the enterprise safely: every model call and agent action passes through policy, guards and audit.
Phase 1 is in development in a private lab; nothing is deployed yet. Phase 2 and Phase 3 are roadmap items.
Four ways AI use goes wrong inside an organisation, and what a policy-enforced gateway does about each.
What goes wrongUntrusted text in a document, web page or tool result can carry instructions that a model follows as if they came from the user.
What AegisX9 doesAegisX9 screens every prompt and tool result for injection and jailbreak patterns before it reaches the model, and records the decision.
What goes wrongCredentials 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.
What AegisX9 doesAegisX9 redacts secrets and PII on the way out and screens responses for data that should not be returned.
What goes wrongAn agent with broad tool access can take actions nobody reviewed, at machine speed.
What AegisX9 doesAegisX9 gives each agent its own key, model allowlist and budget today; per-agent tool allowlists with human approval for risky actions are a Phase 2 roadmap item.
What goes wrongTeams adopt models and tools directly, so nobody can say which models are in use, by whom, or at what cost.
What AegisX9 doesAegisX9 is one gateway behind SSO: a single place to allow models, issue keys, set budgets and audit use.
One request, start to finish. Solid elements are Phase 1 and in development in a private lab; the dashed box is Phase 2 and a roadmap item.
Let developers use Claude every day while the company's secrets, data and customers are protected first. Secrets never exist where a developer or an agent could hand them to a model.
Phase 1.5 is design intent: planned, not built. Nothing on this page is deployed.
Centralized per-developer workspaces on a Kubernetes cluster as the standard way to work. A laptop holds only an IDE client, a WireGuard tunnel and an SSO session. Works with the Claude Code CLI, VS Code Remote-SSH and JetBrains.
Access via SSO with passkeys or hardware security keys, over WireGuard.
Each workspace is a signed, digest-pinned image with a locked Claude Code policy baseline: traffic only to the AegisX9 gateway, no static API keys, a model allowlist, an MCP allowlist, a sandboxed shell, secret-file read denies, and telemetry without prompt text.
Every model call passes through the gateway: prompt-injection and jailbreak guards, secret and PII redaction, output data-leak prevention, per-user budgets and rate limits, and an audit log signed with Vault Transit.
Vault issues short-lived credentials to developers and agents (hours, not months). The provider key lives only in the gateway, with a path to no static key at all via workload identity federation. Terraform Enterprise with Sentinel policy builds the environment; Vault Radar and CI scanning detect leaked secrets.
Red Hat Ansible Automation Platform and Event-Driven Ansible: repeated injection attempts or a leaked secret trigger key revocation, rotation and an incident, with human approval for destructive actions.
Workspaces keep the assistant's session history and a team memory, so work continues day to day.
The same signed workspace image runs locally during an outage with the same guardrails, backed by a standby gateway in the cloud so assistance continues; it syncs back and is wiped when service is restored.
Phase 1 is the scope being built in a private lab: code with unit tests, not a running service. Nothing below is deployed, behind SSO, red-teamed or signed yet. Anything marked roadmap is planned and not started.
WhatOne policy-enforced gateway for all LLM traffic: SSO, per-team or per-agent keys, a model allowlist, budgets and rate limits.
Why it mattersEvery call has an identity, an allowed model and a spending limit, so AI use is visible and bounded.
WhatPrompt-injection and jailbreak detection, with secret and PII redaction before anything leaves.
Why it mattersThe model only sees what policy allows it to see.
WhatData-leak prevention on model responses.
Why it mattersA response that carries data it should not is stopped before it reaches the caller.
WhatA tamper-evident record of every prompt, decision and tool call, without storing secrets.
Why it mattersReviews and investigations have one source that cannot be quietly edited.
Whatgarak and promptfoo run as a CI gate, so a regression in the guards fails the build.
Why it mattersGuard quality is tested on every change, not once at launch.
WhatSBOMs, keyless-signed images (cosign), an admission policy that only runs signed images, and GitOps delivery.
Why it mattersWhat runs is what was built, reviewed and signed.
WhatAn MCP/tool gateway with per-agent allowlists and human approval for risky actions.
Why it mattersAgents can only call the tools they are allowed to, and a person approves the actions that matter.
WhatControls mapped to OWASP Top 10 for LLM Applications (2025), MITRE ATLAS, NIST AI RMF / NIST AI 600-1 and ISO/IEC 42001-style policy.
Why it mattersEvidence for reviewers comes from the same controls that run in production.
WhatAn inventory of the AI systems behind the gateway and a risk register tied to them.
Why it mattersGovernance starts with knowing what is in use.
Phase 3 maps the controls the gateway enforces to the frameworks that enterprise reviewers ask about.
| Framework | What it covers | Planned mapping |
|---|---|---|
| OWASP Top 10 for LLM Applications (2025) | Application-level LLM risks such as prompt injection and sensitive information disclosure | Each gateway and guard control tagged with the OWASP entries it addresses |
| MITRE ATLAS | Adversary tactics and techniques against AI systems | Guard and audit events tagged with the ATLAS techniques they detect or block |
| NIST AI RMF / NIST AI 600-1 | Risk management functions (Govern, Map, Measure, Manage) and the generative AI profile | Inventory and risk register structured around the RMF functions |
| ISO/IEC 42001-style policy | AI management system policy and controls | Policy templates that cite gateway controls as their evidence |
"Mapped" will mean that each control the gateway enforces is tagged with the framework entries it addresses, so the audit log can be read as evidence against those entries.
No dates. Phase 1 is in development; Phase 1.5, Phase 2 and Phase 3 are planned.
In development in a private lab.
Planned; design intent, not built.
Roadmap item; not built yet.
Roadmap item; not built yet.
Licence: Apache-2.0 (the repository is private until the owner opens it). Follow progress at www.xeronine.com.
Continuous checks on every change: linting, type checks, unit tests with a coverage gate, secret scanning, SAST, dependency audit, infrastructure-as-code and Kubernetes manifest linting, and a container vulnerability scan. Release images carry an SBOM and are signed keylessly.
GitHub: coming soon www.xeronine.com
Infrastructure and security engineering, AI-assisted operations and guardrails. Resume · Contact