SOC 2 Control Mapping¶

ARX is deployed on Aptible, a SOC 2 Type II certified hosting infrastructure. This architecture creates a shared responsibility model for SOC 2 compliance. Some controls are fully inherited from Aptible, some are partially inherited (shared between Aptible and ARX), and some are the responsibility of the tenant organization operating agents on the platform.

This document maps the relevant SOC 2 Trust Service Criteria to their implementation in the ARX platform and clarifies the responsibility boundary for each control.

Responsibility Model¶

The SOC 2 responsibility model for ARX has three layers:

When an auditor evaluates a tenant's SOC 2 posture for AI agent operations, the tenant can point to Aptible's SOC 2 Type II report for infrastructure controls and ARX's platform controls for the application layer. The tenant is responsible for configuring and operating the platform correctly.

CC6.1 -- Logical and Physical Access Controls¶

Criteria: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

Fully Inherited from Aptible¶

• Network-level access controls (VPC, security groups, firewall rules).
• Infrastructure SSH access restricted to Aptible operations staff with MFA.
• Database access restricted to application service accounts with connection pooling.

ARX Platform Controls¶

• Tenant isolation via Row-Level Security (RLS): Every database query includes the organization ID. RLS policies prevent cross-tenant data access at the PostgreSQL level. Agent data, audit logs, connector configurations, policies, and secrets are isolated per organization.
• RBAC enforcement: Every API endpoint is protected by the require_role decorator. Four roles are defined: admin, deployer, auditor, and viewer. Role assignments are stored in the users table and verified on every request.
• API key scoping: API keys inherit the role and organization of the user who created them. Keys are stored as SHA-256 hashes. Revoked keys are immediately invalidated.
• Connector scope binding (INV-005): Each connector configuration defines an explicit list of permitted_operations. The platform rejects any connector call that is not in the permitted list, regardless of the underlying connector's capabilities.

Tenant Responsibility¶

• Assigning appropriate RBAC roles to team members.
• Defining connector permitted_operations with the principle of least privilege.
• Rotating API keys on a regular schedule.
• Configuring SSO/SAML via Auth0 for enterprise authentication requirements.

Evidence: Audit log entries with action_type values of connector.called, agent.created, policy.created, and related actions demonstrate that access controls are enforced for every operation.

CC6.2 -- Prior to Issuing System Credentials and Granting System Access¶

Criteria: Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users.

ARX Platform Controls¶

• User registration: Users are created through Supabase Auth or Auth0 SAML/OIDC. No self-registration is permitted without an organization invitation.
• Role assignment: New users must be assigned a role by an admin. The default role provides no write access to agents, connectors, or policies.
• API key issuance: API keys are created through an authenticated endpoint that requires an existing valid session. The key inherits the creator's role and is bound to their organization.
• Policy evaluation: The policy engine (INV-002) evaluates every connector operation against defined rules before execution. This acts as a runtime authorization layer that supplements static RBAC.

Tenant Responsibility¶

• Defining an onboarding process for new team members that includes role assignment review.
• Periodically reviewing user access and removing inactive accounts.
• Defining policy rules that enforce least-privilege access for each agent.

Evidence: Audit log entries with action_type of policy.evaluated demonstrate that runtime authorization is applied to every connector operation.

CC6.3 -- Authorizes Access to Protected Information Assets¶

Criteria: The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design.

ARX Platform Controls¶

• Policy engine (INV-002): Every connector call is intercepted by the policy engine. Policies define rules based on connector type, operation pattern, and risk threshold. The engine assigns a dynamic risk score and renders a verdict of PERMIT, ESCALATE, or DENY.
• Human-in-the-loop approvals: When the policy engine returns ESCALATE, the action is paused and an approval request is created. The request is sent to configured notification channels (Slack, Teams, webhooks). Only users with the admin or deployer role can approve or deny the request. Approval requests expire after a configurable timeout.
• Declared intent manifests (INV-003): Each agent has a declared intent that specifies the systems it is permitted to access, the actions it can perform, and the data types it can handle. Behavioral drift detection compares actual behavior against declared intent and flags violations.

Tenant Responsibility¶

• Writing policy rules that reflect the organization's access requirements.
• Staffing the approval queue to review escalated actions within the expiration window.
• Defining declared intent manifests for each agent that accurately reflect its authorized scope.

Evidence: Audit log entries with policy_verdict field values of PERMIT, ESCALATE, and DENY demonstrate that authorization decisions are made for every connector operation. Approval records provide evidence of human review for high-risk actions.

CC7.1 -- Monitoring System Components for Anomalies¶

Criteria: To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.

Fully Inherited from Aptible¶

• Infrastructure monitoring (CPU, memory, disk, network).
• Host-based intrusion detection.
• Log aggregation and alerting for infrastructure components.

ARX Platform Controls¶

• Immutable audit trail (INV-001): Every agent action, connector call, policy evaluation, and administrative change is logged to the append-only audit trail. Schema-level enforcement (REVOKE UPDATE, REVOKE DELETE) guarantees immutability.
• SIEM fan-out: Audit events are automatically forwarded to configured SIEM integrations in real time. Delivery is asynchronous and non-blocking, with error tracking per integration.
• Behavioral drift detection (INV-003): The platform continuously compares agent behavior against the declared intent manifest. Drift events are classified by severity (low, medium, high, critical) and trigger automatic responses: alerts, throttling, or agent suspension.
• Webhook notifications: Organizations configure webhook endpoints to receive real-time notifications for security-relevant events including drift.detected, policy.violated, agent.suspended, and approval.requested.

Tenant Responsibility¶

• Configuring SIEM integrations to forward audit events to the organization's security monitoring infrastructure.
• Configuring webhook endpoints for real-time alerting.
• Reviewing drift event reports and investigating flagged anomalies.
• Maintaining declared intent manifests as agent capabilities evolve.

Evidence: Audit log entries with action_type of drift.detected and metadata containing severity classification provide evidence of continuous monitoring. SIEM integration records demonstrate real-time event forwarding.

CC7.2 -- Monitoring System Components for Anomalous Activity¶

Criteria: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

ARX Platform Controls¶

• Dynamic risk scoring: The policy engine assigns a numeric risk score (0--100) to every connector operation based on the operation type, target resource, session context, and historical patterns. High-risk operations are escalated for human review.
• Drift severity classification: Behavioral drift events are classified as low, medium, high, or critical. Each severity level triggers an automatic response proportional to the risk.
• Automatic suspension: Agents exhibiting critical behavioral drift are automatically suspended. The suspension is audit-logged with full context, and notifications are sent via configured channels.
• Agent registry (CISO view): The registry endpoint provides an aggregated view of all agents with drift event counts, policy coverage, and compliance posture. This enables security leadership to identify agents that require attention.

Tenant Responsibility¶

• Defining risk thresholds in policy rules that reflect the organization's risk tolerance.
• Reviewing and triaging drift events.
• Investigating suspended agents and determining root cause before restoring operations.

Evidence: Audit log entries with action_type of agent.suspended and metadata containing drift context provide evidence of automated anomaly response. Approval records for ESCALATE verdicts demonstrate human analysis of flagged operations.

CC8.1 -- Authorization and Management of Changes¶

Criteria: The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

Fully Inherited from Aptible¶

• Infrastructure change management (OS updates, network configuration changes).
• Database schema migrations managed through controlled deployment pipelines.

ARX Platform Controls¶

• Agent versioning: Every agent deployment creates a versioned record in the agent_versions table. The record includes the image URI, configuration, deploying user, and deployment notes. Rollback to any previous version is supported.
• Deployment audit logging: Agent deployments (agent.deployed), updates (agent.updated), suspensions (agent.suspended), and rollbacks (agent.rolled_back) are all audit-logged with the identity of the user who initiated the change and relevant metadata (version numbers, image URIs, updated fields).
• Role-restricted deployment: Only users with the admin or deployer role can deploy, update, or suspend agents. Policy changes require the admin role.
• Policy change tracking: Policy creation (policy.created), modification (policy.updated), and deletion (policy.deleted) are audit-logged with the identity of the user and the affected fields.

Tenant Responsibility¶

• Establishing a change management process for agent deployments (e.g., staging environments, code review, approval workflows).
• Reviewing agent version history before deploying new versions.
• Documenting the rationale for policy changes.

Evidence: The agent_versions table provides a complete history of all agent deployments. Audit log entries for agent.deployed and agent.rolled_back actions demonstrate tracked change management.

A1.2 -- Recovery and Availability Monitoring¶

Criteria: The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up, and recovery infrastructure and processes to meet its objectives.

Fully Inherited from Aptible¶

• Automated daily database backups with point-in-time recovery.
• Multi-availability-zone deployments for high availability.
• Automated failover for database and application containers.
• Backup encryption at rest using AES-256.

ARX Platform Controls¶

• Audit trail retention: Audit log entries are retained according to plan tier (90 days for Starter, 1 year for Professional, up to 7 years for Enterprise). Retention is configurable on Enterprise plans to meet regulatory requirements.
• Compliance package versioning: Generated compliance packages are stored as immutable records, preserving point-in-time compliance evidence even as the agent's operational profile evolves.
• Export capabilities: Audit logs and compliance packages can be exported in CSV, JSON, and PDF formats for offline archival and disaster recovery.

Tenant Responsibility¶

• Configuring audit log retention periods appropriate to regulatory requirements.
• Exporting and archiving compliance evidence according to the organization's data retention policies.
• Testing recovery procedures for agent configurations and policy rules.

Evidence: Compliance package records with generated_at timestamps demonstrate regular evidence generation. Audit log export records demonstrate that evidence is available for offline archival.

Summary Matrix¶