The security model of governed private AI

Most enterprise AI conversations stall at the same question: "how do we know it's safe?" This article describes the answer Locs gives — nine governance layers, each enforced in code rather than policy documents, and each producing evidence a security reviewer can verify independently.

The premise: local is necessary, not sufficient

Running AI on your own servers solves the data-boundary problem — nothing leaves. But local does not mean governed: an ungoverned local model can still ingest credentials, answer beyond its knowledge, leak information across teams, and leave auditors with nothing to inspect. Governance is a separate engineering problem.

The nine layers

1. Critical-secret blocking

Passwords, private keys, API keys, bearer tokens, and credentialed connection strings are detected by deterministic, security-reviewable pattern detectors — not by a model — and the containing document is refused ingestion outright. The block is recorded with its reasons.

2. Redaction before embedding

Subscriber numbers, IMSIs, emails, IP addresses, internal hostnames, and account identifiers are masked before any text is chunked or embedded. The AI never sees them; the original document remains visible only to administrators.

3. Two-key approvals

Knowledge activates only through a whitelisted state machine, and the person who ingested a document can never be the person who approves it. Security-flagged content requires a distinct security-reviewer role.

4. Role-partitioned retrieval

Knowledge is separated per module — BSS, NOC, customer care — and filtered by the user's role at retrieval time. Enforcement lives in the retrieval layer, not in a prompt an attacker could talk their way around.

5. Fail-closed answers

On high-risk topics — production commands, charging configuration, security actions — the system refuses when approved knowledge is insufficient, and opens a governed knowledge-gap request instead of improvising.

6. Assisted execution only

The AI recommends; humans execute through existing change processes. There is no write path to production systems.

7. Kill switch

One governor action halts every AI path at once — answers, activations, exports, and external serving. Releasing it is equally one action, and both are receipted.

8. Tamper-evident audit

Every material action appends to a hash-chained log: each event's integrity hash covers its predecessor, so altering any historical record visibly breaks the chain. Verification is a single call, demonstrated live during pilots.

9. Reversibility

Every knowledge activation carries a rollback identifier. Rolling back reactivates the superseded version and produces an impact analysis: which modules, roles, and answers the change touched.

The test of an AI security model isn't the diagram — it's whether an auditor can independently verify each claim. Every layer above produces evidence.

What leaves the environment

By default: nothing. If the operator enables controlled intelligence updates, only sanitized, human-approved, cryptographically signed generic requests leave — with a reviewable diff and a redaction proof. In air-gap mode, even that path is disabled and updates arrive as signed offline bundles verified locally against five gates: signature, checksum, content scan, embedded test suite, and human activation.