·11 min read

Auditable AI for Regulated Engineering Teams: Provenance, Policy, and Approval Controls

EngineeringComplianceGovernance

Auditable AI for Regulated Engineering Teams: Provenance, Policy, and Approval Controls

AI code generation has become remarkably capable. Tools like GitHub Copilot, Cursor, and Claude Code can produce functional code from natural language descriptions in seconds. For a startup building a consumer app, this is transformative. For an engineering team building software that processes protected health information, controls medical devices, or manages financial transactions, current code generation tools have a fundamental gap: auditability.

This post describes the problem, explains why it matters for regulated industries, and details MindCODE's approach to auditable AI-assisted engineering.

The Problem: Generated Code in Regulated Environments

Regulated software development is governed by standards that require traceability from requirements to implementation to testing. In healthcare, this includes:

  • IEC 62304: Software lifecycle standard for medical device software, requiring documented design inputs, design outputs, and verification for every software unit
  • 21 CFR Part 11: FDA regulation requiring electronic records to have audit trails, electronic signatures, and access controls
  • HIPAA Security Rule: Requires technical safeguards including audit controls and integrity controls for systems handling PHI
  • SOC 2 Type II: Requires evidence of change management controls, including who made changes, when, why, and who approved them

In financial services, similar requirements come from SOX (Sarbanes-Oxley) Section 404, PCI DSS for payment systems, and various regulatory frameworks. In defense, NIST 800-171 and CMMC set the bar.

All of these standards share a common requirement: for every artifact in production, you must be able to answer who created it, why, what inputs informed it, who reviewed it, and who approved it.

Standard AI code generation tools cannot answer these questions. When a developer uses Copilot to generate a function, the resulting code has no formal trace to a requirement, no record of the prompt that produced it, no documented review beyond whatever the team's PR process catches, and no machine-readable policy evaluation.

Why This Matters Beyond Compliance Checkboxes

The audit trail requirement is not bureaucratic overhead. It exists because software failures in regulated domains have consequences:

  • A bug in a clinical decision support system could inform a wrong treatment decision
  • A vulnerability in a PHI-handling service could expose millions of patient records
  • A logic error in a financial calculation could trigger regulatory action

When something goes wrong, investigators need to reconstruct exactly how the faulty code was produced, reviewed, and deployed. If the answer is "an AI generated it and a developer glanced at it in a PR diff," that is not an acceptable answer to the FDA, the OIG, or the SEC.

MindCODE's Trusted Code Agent

MindCODE's Trusted Code Agent is an AI-assisted code generation system designed for regulated environments. Every artifact it produces carries a complete provenance chain, every generation passes through policy evaluation, and every artifact requires explicit approval before it enters the codebase.

Core Architecture

The system has four layers:

┌─────────────────────────────────────────────┐
│          Developer Interface (IDE/CLI)        │
├─────────────────────────────────────────────┤
│          Policy Evaluation Engine             │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │ Coding   │ │ Security │ │ Compliance   │ │
│  │ Standards│ │ Rules    │ │ Requirements │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
├─────────────────────────────────────────────┤
│          Generation Engine (LLM + RAG)        │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │ Codebase │ │ API Docs │ │ Requirement  │ │
│  │ Context  │ │          │ │ Traceability │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
├─────────────────────────────────────────────┤
│          Provenance & Audit Layer             │
│  (Append-only log, trace IDs, signatures)    │
└─────────────────────────────────────────────┘

Provenance Chains

Every code artifact generated by the Trusted Code Agent carries a Trace ID — a unique identifier that links to the complete provenance record:

{
  "trace_id": "tca-2026-0401-a8f3c921",
  "timestamp": "2026-04-01T14:23:07Z",
  "developer": "jchen@mindcode.co",
  "input": {
    "prompt": "Create a FHIR R4 Patient resource endpoint that validates incoming data against the US Core Patient profile, stores to the patient repository, and emits an audit event",
    "prompt_hash": "sha256:9f86d08...",
    "context_files": [
      "src/fhir/types.ts",
      "src/repositories/patient.ts",
      "src/audit/events.ts"
    ],
    "context_hash": "sha256:3a7bd3e...",
    "linked_requirements": ["REQ-PAT-001", "REQ-AUD-003"]
  },
  "generation": {
    "model": "mindcode-code-v3.2",
    "model_hash": "sha256:b5c8a12...",
    "temperature": 0.0,
    "output_hash": "sha256:7c4a8d0...",
    "tokens_in": 4821,
    "tokens_out": 1247
  },
  "policy_evaluation": {
    "policies_checked": [
      "hipaa-phi-handling-v2.1",
      "fhir-validation-required-v1.3",
      "audit-event-emission-v1.0",
      "input-sanitization-v2.0"
    ],
    "result": "PASS",
    "details": {
      "hipaa-phi-handling-v2.1": "PASS — PHI fields handled through encrypted repository layer",
      "fhir-validation-required-v1.3": "PASS — US Core Patient profile validation present",
      "audit-event-emission-v1.0": "PASS — Audit event emitted on create and update",
      "input-sanitization-v2.0": "PASS — Input validated against FHIR schema before processing"
    }
  },
  "approval": {
    "status": "PENDING",
    "required_approvers": ["senior-eng", "security-reviewer"],
    "approvals": []
  }
}

This trace is created at generation time and updated as the artifact moves through review and approval. It is immutable once finalized — no field can be modified after approval without creating a new trace.

Concrete Example: Patient Data API Endpoint

A developer needs to create an API endpoint for creating Patient resources. Here is how it flows through the Trusted Code Agent:

1. Prompt with requirement linkage:

Generate: FHIR R4 Patient resource POST endpoint
Requirements: REQ-PAT-001 (patient creation), REQ-AUD-003 (audit logging)
Constraints: US Core Patient profile validation, HIPAA PHI handling

2. The generation engine produces code with inline annotations:

// [TCA:tca-2026-0401-a8f3c921] Generated artifact
// [REQ:REQ-PAT-001] Patient resource creation
// [REQ:REQ-AUD-003] Audit event emission
// [POLICY:hipaa-phi-handling-v2.1] PHI handled via encrypted repository
 
import { validateResource } from '@/fhir/validation';
import { USCorePatientProfile } from '@/fhir/profiles/us-core';
import { PatientRepository } from '@/repositories/patient';
import { AuditService } from '@/audit/service';
import { FHIROperationOutcome } from '@/fhir/types';
 
export async function createPatient(
  resource: unknown,
  context: RequestContext
): Promise<Patient | FHIROperationOutcome> {
  // [POLICY:input-sanitization-v2.0] Validate against FHIR schema
  const validation = await validateResource(resource, USCorePatientProfile);
 
  if (!validation.valid) {
    await AuditService.emit({
      type: 'patient-create-validation-failure',
      actor: context.authenticatedUser,
      detail: validation.issues,
      traceId: context.traceId,
    });
 
    return {
      resourceType: 'OperationOutcome',
      issue: validation.issues.map(i => ({
        severity: 'error',
        code: 'invalid',
        diagnostics: i.message,
        expression: [i.path],
      })),
    };
  }
 
  // [POLICY:fhir-validation-required-v1.3] US Core profile validated
  const patient = await PatientRepository.create(
    validation.resource,
    context
  );
 
  // [REQ:REQ-AUD-003] Audit event for successful creation
  await AuditService.emit({
    type: 'patient-created',
    actor: context.authenticatedUser,
    resourceType: 'Patient',
    resourceId: patient.id,
    traceId: context.traceId,
  });
 
  return patient;
}

3. Policy evaluation runs automatically:

The policy engine scans the generated code against the configured policy set. Each policy is a code-level rule that checks for specific patterns:

  • hipaa-phi-handling: Verifies that Patient resources are stored through the encrypted repository layer, not written directly to a database
  • fhir-validation-required: Verifies that incoming resources are validated against the specified FHIR profile before storage
  • audit-event-emission: Verifies that audit events are emitted for both success and failure paths
  • input-sanitization: Verifies that raw input is validated before use

If any policy check fails, the artifact is flagged and the developer sees the specific violation with remediation guidance.

4. Approval gate:

The artifact enters the approval queue with the trace ID, the policy evaluation results, and the linked requirements. The configured approval policy for this repository requires sign-off from a senior engineer and a security reviewer before the artifact can be committed.

Deterministic Reproducibility

For audit purposes, you need to be able to demonstrate that the same input produces the same output. The Trusted Code Agent achieves this through:

  • Temperature 0 generation: The LLM is configured with temperature=0 and a fixed random seed for all policy-subject generations
  • Pinned model versions: The exact model version (including weights hash) is recorded in the trace. Model updates are versioned and require their own approval process
  • Context hashing: The concatenated context (prompt + referenced files) is hashed. Regeneration from the same hash with the same model version produces identical output
  • Reproducibility verification: The system can re-run any historical generation from its trace record and verify that the output matches the recorded hash

This means an auditor can, at any point, request the system to reproduce the generation and verify that the output matches what was approved and deployed.

Auto-Documentation

Regulated environments require documentation that stays in sync with implementation. This is one of the most persistent pain points in regulated software development — documentation drift. The Trusted Code Agent addresses this by generating documentation as a by-product of the generation process:

  • API documentation: Generated from the code structure and inline annotations, linked to the trace ID
  • Requirement traceability matrix: Automatically updated when a new artifact is linked to requirements
  • Change log entries: Generated from the diff between the previous and current artifact versions
  • Test specifications: Generated alongside the implementation code, linked to the same requirements

Because all of these are generated from the same traced process, they cannot drift from the implementation. When the code changes, the documentation is regenerated from the new trace.

Policy-as-Code

MindCODE's policy engine treats coding standards, security rules, and compliance requirements as executable code rather than PDF documents that developers are expected to read and remember.

A policy definition looks like this:

policy:
  id: hipaa-phi-handling-v2.1
  version: "2.1"
  effective_date: "2026-01-15"
  description: "PHI must be stored through encrypted repository layer"
  severity: BLOCKING  # Cannot proceed without passing
 
  rules:
    - name: no-direct-database-writes
      description: "PHI resources must not be written directly to database"
      pattern:
        type: ast-pattern
        match: "db.insert|db.update|db.query"
        in_context: "Patient|Encounter|Observation|DiagnosticReport"
      action: BLOCK
      message: "Direct database access for PHI resources is prohibited. Use the encrypted repository layer."
 
    - name: encrypted-repository-required
      description: "PHI resources must use the encrypted repository"
      pattern:
        type: import-check
        required: "@/repositories/*"
        when: "resource contains PHI identifiers"
      action: BLOCK
      message: "PHI-containing resources must be stored through @/repositories/* which provides encryption at rest."
 
    - name: phi-logging-prohibition
      description: "PHI must not appear in log statements"
      pattern:
        type: ast-pattern
        match: "console.log|logger.*"
        contains: "patient.name|patient.birthDate|patient.identifier|patient.address"
      action: BLOCK
      message: "PHI fields must not be included in log output. Use trace IDs for correlation."

Policies are version-controlled in the same repository as the code they govern. When a policy changes, the system can evaluate all existing artifacts against the new policy version and flag any that would no longer pass — giving teams a concrete list of remediation items rather than an ambiguous mandate to "update code to meet new standards."

CI/CD Integration

The Trusted Code Agent integrates with standard CI/CD pipelines as a gate:

# Example GitHub Actions integration
- name: TCA Policy Evaluation
  uses: mindcode/tca-policy-check@v2
  with:
    trace_ids: ${{ steps.collect-traces.outputs.ids }}
    policy_set: production
    require_approval: true
    fail_on: BLOCKING
 
- name: TCA Reproducibility Check
  uses: mindcode/tca-reproduce@v2
  with:
    trace_ids: ${{ steps.collect-traces.outputs.ids }}
    tolerance: exact  # For audit-subject artifacts

The pipeline will not proceed if:

  • Any artifact lacks a trace ID (untracked code)
  • Any BLOCKING policy check fails
  • Any required approval is missing
  • Any reproducibility check fails (output does not match trace record)

This means that AI-generated code receives more scrutiny than manually written code in most organizations today — which is appropriate given the novelty of the tooling and the regulatory environment.

What This Does Not Replace

The Trusted Code Agent is a tool, not a compliance program. It does not replace:

  • Human code review: Approvers must still understand the code they are approving. The trace and policy evaluation give them better information, but the judgment is theirs.
  • Manual testing: The system generates test specifications, but test execution and validation remain engineering responsibilities.
  • Risk assessment: Determining which software components are safety-critical (IEC 62304 software safety classification) is a human judgment that informs the policy configuration.
  • Regulatory strategy: Deciding which standards apply to your product and how to demonstrate compliance is a regulatory affairs function. The Trusted Code Agent is a tool that makes compliance more achievable, not a substitute for regulatory expertise.

Who This Is For

The Trusted Code Agent is designed for engineering teams that:

  • Build software subject to IEC 62304, 21 CFR Part 11, HIPAA, SOC 2, or similar regulatory frameworks
  • Want to use AI-assisted code generation but cannot accept the audit gap in current tools
  • Need to demonstrate to auditors, regulators, or customers that every artifact in their codebase has a documented, traceable origin
  • Are willing to accept the overhead of trace management and approval gates in exchange for auditable AI assistance

If your team builds consumer apps with no regulatory requirements, standard code generation tools are fine. If your team builds software where "who wrote this and why" is a question an auditor might ask, the Trusted Code Agent was built for you.

Getting Started

The Trusted Code Agent is available as a CLI tool and IDE extension. It integrates with existing Git workflows — traces are stored alongside the code in a .tca/ directory, and policy definitions live in policies/ at the repository root.

Setup for an existing repository takes approximately 30 minutes: install the CLI, configure your policy set (we provide starter policies for HIPAA, IEC 62304, and SOC 2), connect your identity provider for approval workflows, and run the initial baseline scan.

Every generation from that point forward carries a full provenance chain, passes through policy evaluation, and requires configured approvals before merge. Your auditors will thank you.