Compliance Packages¶

ARX automatically generates compliance packages from runtime audit data. A compliance package is a point-in-time snapshot of an agent's behavior, data flows, sub-processor dependencies, and SOC 2 control coverage. Packages are designed to satisfy auditor requests without manual documentation effort.

Compliance packages are generated on demand via the API and stored as versioned records. Each package captures the agent's complete operational profile at the time of generation.

Generating a Package¶

To generate a compliance package, send a POST request to the compliance endpoint:

POST /v1/compliance

Request body:

{
  "agent_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

This endpoint requires the admin or auditor role. The generator collects data from the audit trail, connector configurations, policy rules, and drift events to produce a comprehensive package.

The generation process is synchronous. For agents with extensive audit histories (tens of thousands of entries), the response may take several seconds. The generator processes up to 10,000 audit log entries per agent.

Package Contents¶

A compliance package contains five sections.

1. Execution Graph¶

The execution graph is a structured summary of everything the agent has done, built from the audit trail. It includes:

• Total actions: The number of audit log entries for the agent.
• Connectors used: A sorted list of every connector type the agent has called (e.g., crowdstrike, jira, splunk).
• Operations performed: A breakdown of action types and their frequency (e.g., connector.called: 1,247, agent.deployed: 3).
• Policy verdicts: Aggregate counts of PERMIT, ESCALATE, and DENY verdicts from the policy engine.
• Time range: The timestamps of the first and last recorded action, establishing the observation window.

The execution graph provides auditors with a factual record of what the agent did, derived entirely from runtime data rather than documentation or design documents.

2. Data Flow Diagram (DFD)¶

The data flow diagram maps how data moves between the agent, the ARX policy engine, the audit trail, and external systems. The DFD is generated in two formats:

• Mermaid syntax: A machine-readable diagram definition that can be rendered in documentation tools, Markdown viewers, or compliance platforms that support Mermaid.
• Structured representation: A JSON object describing each connector flow with permitted operations, actual operations observed, and data direction (inbound, outbound, or bidirectional).

The DFD distinguishes between:

• Permitted operations: Operations allowed by the connector configuration (what the agent is authorized to do).
• Actual operations: Operations observed in the audit trail (what the agent has actually done).
• Data direction: Inferred from operation names. Operations containing :read are classified as inbound; operations containing :write as outbound. Connectors with both are classified as bidirectional.

Every data flow passes through the ARX policy engine, and every policy evaluation is logged to the audit trail. The DFD makes this enforcement architecture visible to auditors.

3. Vendor Security Questionnaire (VSQ / CAIQ v4)¶

The VSQ section provides pre-filled responses to common vendor security questionnaire questions, populated from runtime data. Responses follow the CAIQ v4 (Consensus Assessments Initiative Questionnaire) format where applicable.

The questionnaire covers five categories:

Data Access: Enumerates the connectors configured for the agent and the permitted operations on each. This answer is derived from the connector_configs table, not from self-reported documentation.

Data Storage: Confirms that the agent does not store customer data. All data is processed in transit. Audit logs store SHA-256 hashes of inputs and outputs, never raw data. Credentials are stored in HashiCorp Vault or encrypted in the database, never in application logs or audit entries.

Access Control: Reports the number of active policy rules governing the agent. References the policy engine (INV-002) and dynamic risk scoring. Notes that high-risk actions require human approval via the escalation queue.

Monitoring: Describes the immutable audit trail (INV-001) and behavioral drift detection (INV-003). Reports the number of drift events detected for the agent. References the declared intent manifest that defines the agent's permitted systems, actions, and data types.

Incident Response: Documents the automatic response hierarchy for behavioral drift: low severity triggers an alert, medium severity triggers throttling, high or critical severity triggers automatic agent suspension. All drift events are recorded with full context.

4. Sub-Processor List¶

The sub-processor list identifies every third-party service that processes data on behalf of the agent. Sub-processors are identified from two sources:

• Audit trail: Connectors that appear in the agent's audit log entries.
• Connector configurations: Connector types configured for the agent, including those not yet invoked.

For each sub-processor, the package includes:

The platform maintains a registry of over 80 sub-processor mappings covering EDR/XDR, SIEM, CNAPP/CSPM, ITSM, IAM, messaging, AppSec, threat intelligence, vulnerability management, PAM, identity governance, compliance automation, network security, SOAR, endpoint management, email security, and observability platforms.

Two sub-processors are always included:

• Arx Inc. -- The ARX platform itself, processing audit logs (hashed), agent metadata, and policy configurations. SOC 2 Type II certified via Aptible.
• Aptible, Inc. -- The hosting infrastructure provider. SOC 2 Type II certified.

5. SOC 2 Control Mappings¶

The control mapping section maps the agent's observed actions to SOC 2 Trust Service Criteria. Each action type in the audit trail is mapped to one or more SOC 2 controls:

The mapping summary includes:

• Controls covered: The set of SOC 2 controls for which the agent has evidence (based on observed actions).
• Total actions mapped: The number of distinct action types with SOC 2 mappings.
• Unmapped actions: Any action types in the audit trail that do not have a corresponding SOC 2 mapping (for transparency).

PDF Generation¶

Compliance packages can be downloaded as branded PDF documents:

GET /v1/compliance/{package_id}/pdf

The PDF includes all five sections formatted for auditor review. The document header includes the agent name, package generation date, and the identity of the user who triggered generation. The PDF is generated server-side using the stored package data and returned as a downloadable file.

PDFs are suitable for sharing with external auditors, attaching to SOC 2 evidence requests, or archiving in document management systems.

Versioning¶

Each compliance package is a versioned, immutable record. Generating a new package for the same agent creates a new record with its own ID and timestamp. Previous packages are preserved and remain accessible.

This versioning model allows organizations to:

• Track how an agent's operational profile changes over time.
• Compare control coverage between package versions.
• Provide auditors with point-in-time snapshots that correspond to specific audit periods.
• Demonstrate continuous compliance by showing a history of regular package generation.

Packages are listed in reverse chronological order via GET /v1/compliance and can be filtered by agent_id.

Evidence Bundles¶

A compliance package serves as a self-contained evidence bundle for a single agent. For organization-wide compliance reviews, generate packages for each active agent to build a complete evidence set. The combination of all agent packages, plus the platform-level controls inherited from Aptible, constitutes the full SOC 2 evidence portfolio for the ARX deployment.

The compliance package generation itself is audit-logged (action type compliance.generated), creating an auditable record of when compliance evidence was produced and by whom.