Bastion — the AI Governance Plane

Govern the moment a model reads the data.

Enterprises govern data at rest and in motion, but that investment stops the instant a model reads it — a retrieval-augmented prompt can carry a labeled document to whichever model answers. Bastion is a control point between your applications and every model they use. It classifies each prompt by data sensitivity, enforces policy (regulated work is hard-blocked to your boundary, fail-closed), routes the rest to the cheapest capable model (local-first), and proves every decision on a tamper-evident audit — entirely inside your boundary.

Runs entirely inside your boundary.

Bastion ships as one container, deployed above your in-boundary model endpoints. It exposes a drop-in OpenAI-compatible endpoint, so existing applications and SDKs use it unchanged. TypeScript / Node, framework-free; runs on macOS, Linux, and Kubernetes (a reference manifest with Namespace, Deployment, Service, NetworkPolicy, and Ingress is provided).

The request pipeline (order is the design)

• Classify the prompt by data sensitivity, in-boundary (deterministic detectors + in-boundary NER, on by default). Session-aware; the sensitivity floor is raise-only.
• Policy pre-filter fixes the permitted model pool before any scoring — so no later stage (competency, cost, a routing pin) can reopen a boundary policy closed.
• De-identify where permitted: detected identifiers are tokenized in-boundary, only the safe residue is sent, and the answer is rehydrated locally. Egress is refused outright if detection is incomplete or unavailable.
• Route & execute: the routing decision is made in-boundary by a local model, so deciding where a prompt goes sends it nowhere. The cheapest model clearing a competency bar wins — from the already-permitted pool only.
• Prove: every decision is written to a tamper-evident, hash-chained audit — labels and counts only.

Median governance overhead is ~27 ms per request (measured in-house), before the model is called — a fraction of inference time. No data plane leaves your control; a cloud-hosted proxy cannot keep the data plane in your boundary.

Labels and counts leave. Content does not.

• Regulated & confidential work is hard-blocked to the customer boundary, fail-closed — a policy pre-filter, not runtime hope.
• De-identify-then-escalate is a standing rule of the routing decision: detected PII/PHI crosses only de-identified, and escalation is refused if detection degrades. (DPA raw-egress lanes are per-provider, per-tenant, and audited.)
• No raw prompts are retained. The audit chain and observability carry labels, counts, and hashes only — never prompt text, PII values, or tokens.
• De-identify recall measured at ~97.6% on a held-out corpus with 0% benign over-block (in-house, in-boundary; reduced exposure, not zero).
• Adversarial red-team: 0 raw-PII leaks across the corpus (a purpose-built set of obfuscated encodings, indirect injection, and escalation pressure), fail-closed. Reproducible: npm run prove:no-leak.

Fail-closed by design.

Everything re-runs on your hardware.

Testing breadth

Unit + integration suites; an end-to-end HTTP battery against the real server; browser E2E of the console; an adversarial no-leak red-team + prompt-injection probes (0 leaks over the corpus); concurrency + fault-injection/outage runs; live-model round-trips; and held-out de-identify recall attestation — behind a beta-readiness gate.

Automated security assessment done · continuous

SAST (Semgrep), dependency + container CVE scanning (npm audit + Trivy), and full active, authenticated DAST (OWASP ZAP full-scan + Nuclei) against a running instance: zero active-attack-class findings (the one high was a demo-only false positive) as of the latest run, with remediations applied and re-scanned. This scanning runs continuously in CI (on every push/PR + weekly), with Dependabot. It is reproducible from documented commands on your own hardware.

Evidence a GRC team can regenerate.

Bastion does not certify you — it produces the per-decision, labels-only evidence that regulated programs need, from the tamper-evident chain. A signed, point-in-time compliance report is available per regime:

Mappings are an editable control-map a GRC team tunes; they are enablement evidence, not an attestation of compliance.

What is not done yet.

• No third-party attestation yet. Evidence today is self-assessed and reproducible, not independently assessed. An independent third-party penetration test and SOC 2 (Type I → Type II) are the scoped next step — the item that converts "no external assessment" into "independently pen-tested," sequenced with a first deployment.
• No published throughput/scale report. Concurrency is tested for correctness (burst, no cross-request bleed), not yet a load benchmark; a pilot sets the number on your hardware.
• Cost/savings figures are modeled from a workload mix and labeled as such — computed net of the provider prompt cache a model switch would forfeit (so the headline doesn't overcount), confirmed against your traffic in a pilot, never presented as measured.

We would rather state the line between proven and projected plainly than imply a posture we have not earned. Every figure in this brief is measured in-house on the delivered package and reproducible on your hardware.

Two engineers, four weeks, your hardware.

Install the package on your infrastructure, run the proofs against your own data, and read the audit chain that comes out — none of it requires us in the room. If it holds up, the next step is a joint pilot with one regulated workload on the estate.

Contact: john@greatfallsventures.com · bastionplane.ai