Aura in Regulated Environments

Aura helps with specific compliance controls. It does not certify you. That distinction matters.

"Tell me exactly what you do and do not do. The auditor is going to ask."

The Concern

Vendors in the compliance space have a habit of saying "we help you achieve SOC 2 / ISO 27001 / HIPAA / GDPR / EU AI Act" in ways that imply the tool is sufficient. It is never sufficient. Certification is a process involving a qualified auditor, a controls matrix, evidence of operation over time, training records, risk assessments, and — critically — organizational behavior that the tool cannot substitute for.

The responsible way to describe a tool's relationship to compliance is to say which specific controls it can provide evidence for, what evidence it produces, and what the customer is still responsible for. That is what this page does.

The concern from a compliance-aware reader: if Aura is adding a background process, a .aura/ directory, a live-sync protocol talking to a Mothership, and agent-permission tooling — does it help or hurt my audit posture? The answer depends on what you already have and how Aura is configured.

How Aura Handles It

We organize this by framework, because that is how auditors organize their questions.

SOC 2 (Type I / Type II)

SOC 2 is a framework with five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). Organizations choose which criteria to be audited against. Aura is most relevant to:

CC7.2, CC7.3 — Monitoring and Change Management. Aura's intent logs produce an immutable-by-default, timestamped, signed record of every code change: who made it, what they stated they intended, and what the actual diff was. This is direct evidence for change management controls. Exported as JSON via aura intent export --since 2024-01-01, suitable for auditor review.

CC6.1 — Logical access controls. Aura's zone claims provide file-level access control for multi-developer coordination. In combination with git's access controls, zones produce a record of who was authorized to modify what. Note: zones are coordination, not security. Someone with git write access can bypass zones if they insist. Zones document intent, not enforcement.

CC8.1 — Change management review. aura pr-review produces a structured review output (security issues, architectural violations, unexpected deletions) that can be attached to each PR as evidence that a pre-merge review occurred.

What Aura does NOT do for SOC 2: provide the access control infrastructure (that is your identity provider and git hosting), run the security scans you need (that is SAST/DAST tools), manage your vendor risk (that is a process), or make you SOC 2 compliant. Aura produces evidence. Your auditor evaluates the evidence. Your controls matrix lists Aura as one control among many.

ISO 27001

A.8 — Asset management. Aura's semantic graph is an up-to-date inventory of the code components in your system. The graph can be exported as part of your asset register.

A.9 — Access control. Same caveats as SOC 2 CC6.1. Zones document; git enforces.

A.12 — Operations security. Aura's logs provide a tamper-evident audit trail. Logs are content-addressed and signed; modifying a historical entry is detectable.

A.14 — System acquisition, development, and maintenance. Aura's intent-versus-diff check is direct evidence of development lifecycle controls. The fact that every commit has a stated purpose, verified at commit time against the actual change, is something an ISO 27001 auditor will note favorably.

What Aura does NOT do for ISO 27001: your ISMS documentation, your risk treatment plans, your management review minutes, your training records. These are organizational artifacts.

HIPAA

Two relevant areas:

Technical safeguards §164.312(b) — Audit controls. Intent logs are audit controls for the development process. If your development process touches PHI-adjacent code (e.g., a microservice that routes PHI), the log of changes to that code is HIPAA-relevant.

Technical safeguards §164.312(a) — Access control. Aura's agent-permission model (what AI agents can do, what files they can access) is a form of access control for the development toolchain. Document in your access control policy.

Data residency. This is a common HIPAA concern. Aura's Mothership in self-hosted mode runs on your infrastructure. Intent logs, live-sync data, and agent messages stay on servers you control. If your Business Associate Agreement (BAA) landscape requires data to remain in specific jurisdictions, self-hosted Mothership lets you meet that requirement. Aura Cloud (our hosted product) is not covered by a BAA by default; if you need a BAA, self-host or contact us for enterprise arrangements.

What Aura does NOT do for HIPAA: encrypt your PHI (that is your application's job), manage your BAAs, provide a Covered Entity certification, or make your application HIPAA-compliant by installation.

The development-process angle:

Article 5 — Data minimization in logs. Aura's intent logs record commit messages, diffs, and author identity. They do not record the content of files being edited beyond what is in the commit (which is already in git). If your commit diffs contain personal data (they should not, but sometimes do), that data is in both git and Aura. The exposure surface is the same; Aura does not expand it.

Article 17 — Right to erasure. If a developer leaves and requests erasure, their identity can be redacted from Aura's logs. The underlying commits in git have the same issue; git does not erase easily. Aura follows git's stance here.

Article 30 — Records of processing. If you are a Data Processor, the intent log is an additional record of what changes were made to systems processing personal data. Useful for Article 30 documentation.

EU AI Act

This is where Aura's agent-tracking features become particularly relevant. The AI Act introduces obligations for providers and deployers of AI systems, with tiered requirements based on risk classification.

Article 12 — Record-keeping. High-risk AI systems must maintain logs of system operation sufficient to trace outputs back to inputs. If your AI system's code is co-authored by AI agents (Claude, Copilot, in-house agents), the development-time record is part of the traceability story. Aura's Sentinel inbox records every agent-to-agent message, every intent, every file an agent modified. Exported, this is Article 12-relevant evidence.

Article 14 — Human oversight. Aura's interactive conflict picker and strict-mode pre-commit hooks are forms of human oversight over agent-generated changes. The hook prevents a commit that deletes a function unless a human has explicitly authorized the deletion via intent logging. This is direct evidence of oversight mechanisms.

Article 13 — Transparency. Aura's intent logs and PR reviews document what the development-time AI agents did and why. This contributes to the transparency obligation for downstream users of your AI system.

What Aura does NOT do for the EU AI Act: your risk classification (that is your legal team's job), your conformity assessment, your post-market monitoring of the deployed AI system (that is a runtime concern), or your fundamental rights impact assessment. Aura is a development-process tool, not a deployed-system governance tool.

FedRAMP, ITAR, CMMC

These are US government and defense frameworks. The short answer: if you are operating under these frameworks, your version control tooling choice is likely constrained by your ATO (Authority to Operate) or your prime contractor's requirements.

Aura in default (Git-compatible) mode adds no new network connections if Mothership is not configured. aura init + aura save + aura push (to your existing git remote) operate entirely locally with respect to Aura.
Self-hosted Mothership in an air-gapped environment is supported. See air-gapped install.
Aura Cloud is not FedRAMP-certified and is not suitable for FedRAMP or ITAR workloads. Self-host only.
Our source is Apache 2.0 and available for inspection. If your program requires a security review of the toolchain, the entire source is open.

Whether Aura is permitted in your specific environment is a question for your Authorizing Official or security officer. We can provide documentation to support their review; we cannot make the determination for them.

Export control

Aura's binary is published from the US. It does not contain cryptography beyond standard TLS and hashing, which are generally exempt under ECCN 5D002 notes. We do not claim to be a lawyer. If your organization requires export classification, we will help provide the documentation to support your classification process.

Data Flow: What Is Stored Where

For auditors asking "where does data go":

| Data | Default mode (Git-compatible) | Standalone mode | |---|---|---| | Source code | git repo (local + remote) | Aura object store (local + Mothership) | | Commit metadata | git | Aura | | Intent logs | .aura/intent_log.jsonl (committed to git) | Aura object store | | Live-sync function updates | Mothership (self-hosted or Cloud) | Mothership | | Agent messages | Mothership | Mothership | | Zone claims | Mothership | Mothership |

If Mothership is not configured, live-sync and agent-message features are unavailable; everything else works offline.

Intent logs in default mode are committed to git, meaning they go wherever your git repository goes. This is usually desired — the intent is part of the historical record. If your compliance posture requires the intent log to live separately from source, set aura config set intent.in_repo false; logs then go to a separate file not committed to git.

Audit Export

Aura provides structured export for auditor review:

aura intent export --since 2024-01-01 --format json > intents.json
aura agent-log export --since 2024-01-01 > agents.json
aura pr-review export --pr 1234 > review-1234.json

Each export is signed and timestamped. Auditors can verify the signatures against the Aura instance's public key.

What Aura Does Not Solve

Your audit. We do not certify you. We produce evidence you provide to your auditor.
Your policies. We do not write your policies. We produce evidence that policies are followed at the development level.
Your people. We do not train your team. Aura helps a well-trained team leave a good audit trail; it does not compensate for an untrained team.
Runtime compliance. Aura is a development-time tool. Production encryption, access control, monitoring, breach response — all outside Aura's scope.
Fundamental rights impact assessments, DPIAs, conformity assessments. Legal-process artifacts, not tool outputs.

The Honest Tradeoff

Adding Aura to a regulated environment adds another tool in the supply chain, which adds scope to your vendor risk review. The tradeoff: Aura produces structured evidence that is often easier to audit than ad-hoc git history + Slack threads + tribal knowledge. Whether that tradeoff is favorable depends on the framework, the auditor, and how much evidence you are already producing manually.

Our honest recommendation: start with a compliance gap analysis. If your gaps are around change management evidence, development lifecycle documentation, or AI agent oversight — Aura likely helps. If your gaps are elsewhere (access control infrastructure, runtime monitoring, policy documentation), Aura does not help and you should address those gaps first.

We are happy to support customers through audit processes with documentation, logs, and (for enterprise customers) auditor-facing walkthroughs. Please reach out before the audit, not during.