Security & compliance,
explained honestly.

We make your agents credible to a review board. We don't replace them.

Arx is the enterprise-readiness layer that sits between the Python security agents your team has already built and the vendor review that's keeping them from shipping. We handle policy enforcement, human approval gates, immutable audit chaining, and SOC 2 control mapping. We don't write agents; we make the ones you've written credible to the review board that has to approve them.

What Arx is not: a managed security service provider, a SOC-as-a-service, or a replacement for your security program. We don't operate with standing visibility into your agent's runtime environment, and we don't hold credentials for your systems. When Arx isn't running, your agents are still just Python — we're an opt-in layer, not a dependency you can't remove.

Two programs, two sets of controls. Here's which is which.

Arx runs on Aptible, which means two distinct programs are in play: theirs and ours. Aptible is the infrastructure. We are the application. The distinction matters to your auditors, so we're stating it clearly instead of letting the attestation documents do the work.

Aptible's Type II observation window pre-dates Arx's application-layer program, which entered its own SOC 2 Type I observation window in Q2 2026. The two programs are documented separately and evidence is available separately under NDA.

What we receive, what we store, and what we can't touch.

SAML, SCIM, MFA, and the support access policy.

Arx supports SAML 2.0 SSO with any compliant identity provider, including Okta, Azure AD, and Google Workspace. SCIM 2.0 is available for automated user provisioning and deprovisioning. MFA is enforced at the Arx application layer for all users who authenticate via username and password; SSO-federated sessions inherit MFA enforcement from your identity provider.

Role-based access control has five roles: Admin, Security Architect, SOC Engineer, Analyst, and Auditor. Permissions are non-delegable — an Admin can grant any role, but a SOC Engineer cannot grant Admin. All role assignment and revocation events are recorded in the audit trail and tied to the acting user's session.

Arx support engineers operate under a "we see us when you see us" policy. There is no standing support access to your workspace. When a support case requires workspace access, the engineer submits a time-bounded access request, you approve it, and the session appears in your audit trail in real time alongside your own team's activity. We cannot view workspace data outside of an approved, time-limited, recorded session.

Every vendor that touches your data, listed.

A complete and continuously updated list of our subprocessors is maintained at arxsec.io/trust/subprocessors. The table below reflects our current primary subprocessors. We will notify you 30 days in advance of adding new subprocessors that materially affect data processing.

How we build, patch, test, and respond.

Where we are, and where we're going.

This roadmap reflects our current attestation trajectory. Dates are targets, not guarantees. We publish updates here as milestones close rather than waiting for a formal announcement.