Compliance & Audit

Aura's alignment with SOC 2, ISO/IEC 27001, and HIPAA. Why the intent log is a natural audit trail, and how to produce an evidence package for external auditors.

Overview

Auditors do not care about features. They care about evidence — signed, time-ordered, tamper-evident records that a control was in place, that it operated correctly, and that exceptions were reviewed. Aura produces that evidence as a natural by-product of how it works. The same intent tracking that protects code from AI mistakes also produces a cryptographically chained record of every semantic change, who authored it, what they intended, and which reviewer approved it.

This page documents which common framework controls Aura satisfies, which require customer action, and how to export evidence for an audit engagement.

We describe Aura as aligned with the requirements of SOC 2 Type II, ISO/IEC 27001:2022, and HIPAA technical safeguards. We do not describe Aura as "certified" to any of these frameworks on your behalf, because certification is always against a specific organization's scope. Your SOC 2 report covers your company, not Naridon's engine. What we guarantee is that Aura produces the artifacts your auditor will ask for.

The intent log as audit trail

Every commit created through Aura carries an intent record. The intent is written before the commit, verified by the pre-commit hook against the actual AST changes, and appended to an immutable, hash-chained log. Each record contains:

The commit SHA and the AST node identities of every added, modified, or deleted function.
The stated intent string, authored by the human or agent making the change.
The identity of the author (human user, or agent identity under RBAC).
A timestamp from a trusted source (the Mothership clock, or a configured RFC 3161 timestamp authority).
The SHA-256 of the previous intent record, forming a tamper-evident chain.
Optional reviewer attestation signed by a second identity.

Auditors care because this record gives them, in one place, every property they normally have to reconstruct from scattered sources:

Change attribution — who made the change.
Change justification — why they said they made it.
Change verification — whether the stated intent matched the actual code change.
Time ordering — verifiable by replaying the hash chain offline.
Reviewer sign-off — when applicable.

A single aura audit export command produces the evidence a SOC 2 CC8.1 (change management) test needs. We have yet to meet an auditor who did not smile when we showed them.

Control mapping: SOC 2

The table below maps Aura capabilities to the SOC 2 Trust Services Criteria most commonly scoped in a software engineering audit. Controls marked customer require action outside Aura — access provisioning, on-call rotation, vendor review — and are listed here only so the scope is unambiguous.

| TSC | Requirement | Aura provides | Customer provides | | --- | --- | --- | --- | | CC6.1 | Logical access | RBAC roles, zone ownership, mTLS peer authentication | User directory integration, offboarding process | | CC6.6 | Transmission of data | TLS 1.3 + mTLS between all peers and Mothership | Certificate lifecycle management | | CC6.7 | Restriction of data | AST fragments stored encrypted at rest (AES-256-GCM) | KMS key custody | | CC7.2 | Monitoring for anomalies | Intent-vs-AST drift detection, strict-mode enforcement | SIEM integration, alert triage | | CC8.1 | Change management | Hash-chained intent log, AST-level diffs, reviewer sign-off | Change-advisory board process | | CC8.1 | Emergency changes | Strict-mode break-glass with passcode and audit marker | Passcode custody, post-incident review | | A1.2 | Capacity planning | Prometheus metrics, capacity planning guide | Capacity review cadence | | C1.1 | Confidentiality | Mothership stores fragments, not secrets; secret-detection pre-commit hook | Secret management platform |

Control mapping: ISO/IEC 27001:2022

The 2022 revision of ISO 27001 places heavier emphasis on evidence of operating effectiveness. The Annex A controls where Aura materially reduces the implementation burden:

| Annex A | Control | Aura provides | | --- | --- | --- | | A.5.15 | Access control | Role and zone model enforced at pre-commit hook | | A.5.23 | Information security for use of cloud services | Self-host posture eliminates transfer to cloud provider | | A.5.34 | Privacy and protection of PII | Code fragments only; no inline PII collection | | A.8.2 | Privileged access rights | admin role gated behind mTLS + optional passcode | | A.8.4 | Access to source code | Zone ownership + RBAC; immutable access log | | A.8.9 | Configuration management | Pinned configuration file, hash-verified on boot | | A.8.16 | Monitoring activities | Metrics, traces, intent-drift alerts | | A.8.28 | Secure coding | Semantic PR review flags layer violations and accidental deletions | | A.8.32 | Change management | Intent log = change management evidence |

Control mapping: HIPAA Technical Safeguards

Aura does not process protected health information (PHI) directly. It processes source code that may implement systems handling PHI. For teams building PHI-handling software, the relevant controls land on Aura as follows:

| 45 CFR 164.312 | Requirement | Aura provides | | --- | --- | --- | | (a)(1) | Access control | RBAC with emergency access via strict-mode break-glass | | (a)(2)(iii) | Automatic logoff | Session tokens with configurable TTL | | (a)(2)(iv) | Encryption and decryption | AES-256-GCM at rest, TLS 1.3 in transit | | (b) | Audit controls | Hash-chained intent log | | (c)(1) | Integrity | AST-level change attribution; tamper-evident chain | | (d) | Person or entity authentication | mTLS; optional second factor on admin actions | | (e)(1) | Transmission security | mTLS between all peers |

We recommend HIPAA-scoped customers also enable RFC 3161 timestamping for the intent log, which satisfies the "integrity" safeguard with a third-party time source.

Exporting evidence for auditors

The aura audit export command produces a zipped evidence package covering a specified window:

aura audit export \
  --from 2026-01-01 \
  --to 2026-03-31 \
  --repo monorepo \
  --output q1-2026-evidence.zip

The package contains:

intent-log.ndjson — every intent record in the window, one per line.
intent-log.sig — detached signature over intent-log.ndjson.
chain-verification.txt — output of the chain verifier, proving no tampering.
access-events.ndjson — every role change, zone claim, and admin action in the window.
commits.ndjson — SHA-level commit index with author, timestamp, and AST-change summary.
config-snapshot.toml — the effective Mothership configuration at window start and end.
schema-version.txt — Postgres schema version; confirms no schema manipulation.

The package is deterministic: regenerating it from the same window on the same data produces an identical archive. That makes re-performance by an auditor trivial.

Verifying the intent chain offline

The intent chain can be verified without talking to the Mothership. Ship the exported evidence package plus the CLI to an auditor's workstation:

aura audit verify q1-2026-evidence.zip

intent records in window: 14,832
chain start: 2026-01-01T00:00:04Z
chain end:   2026-03-31T23:59:41Z
hash chain: valid
signature: valid (Naridon release key)
reviewer attestations: 9,214 signed / 5,618 unreviewed
intent-vs-AST drift flags: 12 (all acknowledged)
result: PASS

The verifier exits non-zero on any chain break. If a record is missing, altered, or reordered, the output identifies the exact record and the break point.

Review attestation

Teams running in regulated environments often require a second-reviewer signature on every change that touches designated critical paths. Configure this per zone:

[[zone]]
path = "services/billing/**"
require_review = true
min_reviewers = 1
reviewer_role = ["senior_engineer", "security"]

When the pre-commit hook sees a commit that touches a zone with require_review = true, it requires a signed attestation from an identity bearing one of the listed roles before accepting the intent record. The attestation is stored inside the intent log and flows into the evidence export.

Data retention

The intent log is append-only and, by default, retained indefinitely. For jurisdictions that require affirmative deletion under GDPR Article 17, Aura supports cryptographic redaction: the record is retained for chain integrity, but its payload is replaced with a zero-length ciphertext whose key has been destroyed. The record's existence and timestamp remain provable; its contents do not. See Data Sovereignty in the EU for the full procedure.

Retention policy is a TOML knob:

[audit.retention]
mode = "indefinite"      # or "cryptographic_redaction" after N days
redact_after_days = 2555 # seven years, typical SOX default

Auditor tabletop

When an auditor is scheduled, a typical engagement looks like this:

Scope the window. The auditor specifies the review period.
Export evidence. One command, one zip file.
Verify chain offline. The auditor runs aura audit verify. Output is self-describing.
Sample commits. The auditor selects commits at random. For each, the evidence package includes the intent record, AST diff, reviewer signature, and timestamp.
Review exceptions. Drift flags, emergency changes, and access anomalies are surfaced in dedicated columns.

In our experience, engagements that previously required two weeks of screenshots and spreadsheet assembly now take an afternoon.

Responsibility summary

Aura is not a compliance program; it is an evidence generator. The customer still owns:

Defining the control framework and scope.
Provisioning and deprovisioning identities.
Key management for fragment encryption.
Alert triage for drift and access anomalies.
External auditor engagement.

What Aura removes is the archaeology. The evidence is already there, already chained, already signed, already exportable.