Compliance

When an AI agent acts, someone eventually has to answer for what it did: which actions were permitted, which were blocked, who set the rules, and whether the record can be trusted. Compliance work is the discipline of being able to answer those questions with evidence rather than assurances. This section is about turning the runtime behavior of governed agents into that evidence.

Qortara turns runtime governance decisions into structured, tamper-evident records that your compliance team and your auditor can examine. Every allow, deny, and verify decision is recorded with the agent context, the policy that matched, and a content hash linked into a verifiable chain. Because the record is a byproduct of actually enforcing policy, the evidence reflects what your agents really did, not a separately maintained spreadsheet that drifts out of sync with reality. That record is the raw material a compliance program runs on.

The pages here connect the conceptual model (what an evidence record is and how it is produced) to the practical work of presenting that evidence under a specific framework. Read the concept first if you want the mental model; read the SOC 2 guide when you are preparing for an actual examination.

What this section covers

• [SOC 2 Evidence](/docs/compliance/soc2): how Qortara governance evidence is designed to map to the SOC 2 Trust Services Criteria (CC6.1, CC6.2, CC6.3, CC6.6, CC7.2, CC8.1), the auditor evidence categories with example export commands, tips for a clean audit, and an honest account of what Qortara does not provide.
• [Compliance Evidence (concept)](/docs/concepts/compliance-evidence): what an evidence record contains, how continuous governance records and on-demand compliance scans relate, and how governance events become audit-ready material across SOC 2, GDPR, the EU AI Act, and NIST AI RMF.

A sensible path is to read the concept page first for the model of how evidence is generated and what frameworks it is designed to map to, then move to the SOC 2 guide for the concrete export commands and the five evidence categories an auditor typically asks for.

What good evidence looks like

Across both pages, the same building blocks recur, and it helps to recognize them.

• **The decision log.** Every policy evaluation, allow or deny, recorded with the agent, the action, the resource, and the policy that matched. This is what shows an auditor that controls are not just written down but enforced.
• **Tamper-evidence.** Each record is content-hashed into a verifiable chain, so a chain-integrity check can demonstrate the log has not been altered after the fact.
• **Framework mapping.** Records are tagged with the frameworks they are relevant to, which is what lets the same activity serve a SOC 2 access-control criterion and a GDPR records-of-processing obligation at once.
• **Scans over time.** Periodic compliance scans produce a scored, framework-shaped summary with findings and remediation, so you can show a trend rather than a single snapshot.

Frameworks Qortara evidence is designed to support

The SOC 2 guide goes deep on one framework, but the evidence model is designed to map to several. The concept page covers all of these in detail; the summary below orients you.

• **SOC 2.** Qortara is designed to map agent governance to the Trust Services Criteria most relevant to it: logical access (CC6.1), system authentication (CC6.2), termination (CC6.3), external access (CC6.6), monitoring (CC7.2), and change management (CC8.1). The [SOC 2 guide](/docs/compliance/soc2) walks through the auditor evidence categories and the export commands for each.
• **GDPR.** The same governance records are designed to support processing principles (Art. 5), lawful basis (Art. 6), data protection by design (Art. 25), records of processing (Art. 30), and security of processing (Art. 32).
• **EU AI Act.** Tamper-evident governance records are designed for the record-keeping obligation (Art. 12), with mappings also covering risk management (Art. 9), transparency (Art. 13), human oversight (Art. 14), and accuracy and robustness (Art. 15).
• **NIST AI RMF.** Evidence is designed to support the Govern, Map, Measure, and Manage functions.

These describe what Qortara is designed to support, not a guarantee that a given control is satisfied in your environment. See [Compliance Evidence](/docs/concepts/compliance-evidence) for the full mapping tables and the caveats that come with them.

A typical audit-preparation workflow

When Qortara Cloud Governance is available, preparing the agent-governance portion of a SOC 2 examination is designed to follow a predictable shape. The [SOC 2 guide](/docs/compliance/soc2) details the exact export commands; the high-level flow is:

1. Confirm policies exist and are versioned, then export your active policies and their version history.
2. Export the access-decision log over the audit period to show that every governed action went through policy evaluation and that denials were enforced.
3. Run a chain-integrity check to demonstrate the audit trail has not been altered.
4. Export your compliance-scan history to show scans run regularly and findings are remediated over time.
5. Show your monitoring configuration: at least one active webhook endpoint and its delivery history into your SIEM.

Each of these maps to something an auditor specifically looks for, and each is produced from real governance activity rather than assembled by hand. Treat the workflow as the pre-launch design until Cloud Governance is deployed.

Availability

Recording governance decisions happens in the open-source Qortara Governance sidecar today (`pip install qortara-governance-langchain`, Apache-2.0, alpha v0.2.0). The sidecar produces the underlying tamper-evident records as it enforces policy. Centralized evidence generation, compliance scans, and the export endpoints referenced in the SOC 2 guide are part of Qortara Cloud Governance, the hosted control plane, which is pre-launch and has not been deployed. Where this section shows a hosted endpoint or a scan report, it describes the pre-launch design, not a running service. You can build and plan against that design now; the live evidence pipeline arrives when Cloud Governance launches.

Important note on what compliance means here

Using Qortara does not guarantee compliance with any framework, and Qortara is not certified against any framework. Qortara holds no SOC 2 report and no third-party certification, and nothing in this section should be read as a claim that it does. What Qortara is designed to do is generate evidence that can support your compliance workflow for the agent-governance portion of your program. Your organization and your auditor (a CPA firm, in the SOC 2 case) remain responsible for determining whether a given control, and the evidence behind it, satisfies the framework you are pursuing. Qortara also covers only the agent-governance-relevant controls; your overall posture includes infrastructure, personnel, physical security, and other areas Qortara does not address.

Where to go next

• [Policy Enforcement](/docs/concepts/policy-enforcement): the decision point that produces the evidence in the first place.
• [Policy Authoring](/docs/guides/policy-authoring): write the policies whose decisions become evidence, including templates aligned to CC6.1 and other controls.
• [Webhooks and Events](/docs/concepts/webhooks-events): stream governance decisions into a SIEM, which is one way to satisfy the monitoring intent behind SOC 2 CC7.2.
• Questions about an audit or evidence export? Email support@qortara.com.