Letting AI write code inside a regulated organization

The interoperability question is settled. The control question is not.

The Model Context Protocol has done for agent-to-system connection roughly what ODBC did for database drivers: it turned an N-by-M matrix of bespoke integrations into a described interface a client discovers at runtime. That is real progress.

It is also the wrong thing to celebrate first. Making it easy to connect a model to your systems does not make it defensible to do so. Connection is now the cheap part. The control plane is the expensive part: what may be reached, by whom, under whose approval, and what stays provable a year later.

The argument here is one sentence. These controls are not there to make the model smarter. They exist so that the person who does not trust the technology can point at the exact place where a human still says yes, and prove afterward that one did. Governance is not the tax you pay for adoption. It is what makes adoption survivable, and therefore approvable.

Below are the five things a skeptical stakeholder says out loud, and the control that answers each. Every one is something I built and operate.

Five fears, five controls

"It will leak regulated data."

Redaction at the model boundary, applied before anything crosses. Mine covers 12 vendor-anchored patterns (private keys, JWTs, provider API keys, bearer headers, passwords inside connection strings) plus stripping my own filesystem paths.

The design principle matters more than the pattern count: over-redaction is the safe failure mode. A redactor tuned to avoid false positives is tuned to eventually miss a credential. Tune it the other way and the worst case is a model answering with less context. This is egress data-loss prevention at the one boundary classical DLP does not watch.

"It will do something irreversible."

Sandboxed execution that refuses to run untrusted generated code on the host. Drafts execute in a Docker container or they do not execute, and the stage fails closed: if the sandbox is unavailable, nothing runs. That turns "the AI might break production" into a bounded statement about what a container can reach.

"Nobody can tell me who approved what."

A single-use approval token bound to a hash of the exact payload. Mine are 32 random bytes, stored as a SHA-256 digest, scope-bound, three-minute default lifetime, consumed atomically so a token cannot be replayed.

The consequence is the sentence an auditor cares about: if the model changes one character after a human approves, the commit is rejected. "I approved X" cannot quietly become "the system shipped Y." Sensitive paths (.env, lockfiles, Dockerfiles, anything under auth, secrets, or credentials) require a second, different confirmation phrase and an OWNER role.

Underneath sits an append-only audit chain where each entry's hash includes the prior entry's hash, so silent deletion is detectable rather than merely discouraged. Honest limitation: it is wired at the gateway boundary, not yet on every write path.

"It will produce things nobody can maintain."

A review stage that returns a block or a warning with the reasons recorded. Critical findings block outright; warnings require a consumed override token, so an exception is a logged decision by a named person instead of an unnoticed default. What matters is that "we allowed this anyway, on this date, for this reason" becomes a record rather than a memory.

"It will be confidently wrong."

Three controls in sequence. Retrieval grounding over an indexed corpus of the real codebase, with boundary-aware chunking: I parse TypeScript with ts-morph so chunks respect function boundaries and carry symbol kind, line ranges, export status, and typed import and call edges. A chunk that splits a function in half retrieves a half-truth.

Policy scanning before generation, not only after. My policy engine runs at four pipeline stages using regex, phrase, token-set, symbol, and vector-similarity matching, so a paraphrase of a forbidden pattern still trips it. Policy is data: versioned, scoped globally or per application.

Measurement. Retrieval evaluation, index coverage, drift monitoring, and adversarial payload generation against the policy engine. Retrieval quality decays as the corpus changes. If you are not measuring it, you are asserting it.

How the pieces interrelate

Five architectural domains meet at this gateway, and the seams are where failures live.

Identity determines who may invoke. The agent must act as a person, not as itself. My gateway carries per-seat scopes and resolves the organization on every call. The common failure is giving an agent one service account holding the union of everyone's permissions, at which point every downstream access control is decorative.

Integration middleware determines what may be reached. A tool gateway is middleware with a model on one end: which systems, which operations, read or write, at what rate, at what cost. I enforce daily and monthly spend caps with timezone-aware windows and warn, pause, or block actions, because cost control becomes an availability control once agents run unattended.

The data layer determines what is retrievable. An index inherits the access model of its source or it becomes a bypass. Flatten per-role visibility into one vector store and you have built a privilege escalation channel with excellent recall. It is also where chunking stops being a quality question: a chunk spanning two units of code can carry context the requester was never entitled to see.

Observability determines what is provable afterward. Logs and evidence are not the same artifact. My gateway emits an audit event for every tool call and every block, and evidence means correlating those with the chunks retrieved, the policy verdict, the approving human, and the resulting write, in a store where tampering leaves a mark.

Security policy cuts across all four, which is why it belongs in one versioned, scoped engine rather than four configurations that drift apart within a quarter.

Compliance constraints on adoption

In regulated contexts the binding constraint is usually not model quality. It is where inference happens and who legally counts as an authorized recipient. HIPAA requires a business associate agreement before protected health information reaches a vendor. The GLBA Safeguards Rule reaches institutions handling financial aid. PCI DSS governs payment paths. FERPA permits a vendor to act as a school official only when the institution keeps direct control over the use and maintenance of student records and redisclosure is prohibited.

The practical consequence: "the vendor does not train on your data" is a procurement statement, not an architectural control. The architectural control is that the data never leaves.

That is why my default is local inference on my own hardware via Ollama, with cloud escalation behind an explicit override flag. My 24 GB RTX 3090 (external, in an eGPU enclosure) comfortably serves 7B, 8B, and 14B models and fits a 32B at roughly Q4; 70B needs aggressive quantization and degrades. A 6 GB laptop node handles embeddings and small models. I know those boundaries because I benchmarked five to six local models rather than trusting vendor claims about what a card can serve.

The sequencing that follows: adopt read-only capability first. Retrieval, mapping, and impact analysis touch code and metadata, produce no writes, and can be shown to skeptics before anything changes state.

Scope, stated plainly

This is drawn from a single-operator system I built for my own work: roughly 88 tests across seven subsystems, one human, my hardware. It is not a multi-tenant enterprise deployment and I will not describe it as one. One operator is the scale at which these primitives can be designed honestly, and not the scale at which they have been stress tested.

To run it for an organization, at minimum:

• Federated identity. Local seat scopes give way to the institutional identity provider, with group-to-scope mapping and lifecycle tied to the directory. I have built OIDC authentication with machine-to-machine credentials, tenant resolution, and just-in-time provisioning in my own products: the same pattern at smaller blast radius.
• Per-role approval authority. One OWNER role becomes a delegation model with separation of duties, so the person requesting a change is not the person approving it.
• Retention policy. A retention period, legal hold, and export format agreed with counsel before the first audit entry is written, and the hash chain extended to every write path.
• External review. Penetration testing and a third-party control assessment. Self-assessed controls are a starting position, not a finding.

One disclosure, volunteered rather than left to be discovered: my hands-on experience with regulated data comes from an earlier career as an EMT in a Phoenix emergency department, working daily under HIPAA. That is operational familiarity with records carrying legal weight. It is not a compliance credential, and it is not FERPA experience. What I contribute to a regulated adoption decision is the architecture and the evidence trail. What the regulation permits is a determination for the people whose job that is.

The reason to build any of this is unchanged. The controls do not make the model better. They make the decision to use it defensible, and they leave proof that a human said yes.