@import url('https://fonts.googleapis.com/css2?family=Barlow+Condensed:wght@700;800&family=Share+Tech+Mono&display=swap');
INFRASTRUCTURE PLATFORM SERVICES CONNECTOR LIBRARY CUSTOMER AGENT RUNTIME
ENGINEERING

How We Built ARX: The Technical Architecture of a Compliance-Native Security Agent Platform

A look under the hood at the technology decisions behind ARX — and why we made them.

6 min read

AMershard J.B. Frierson · Founder, ARX

When we started building ARX, we had one guiding principle: compliance cannot be an afterthought bolted on at the end. It has to be the foundation that everything else is built on top of.

That principle shaped every technical decision we made.


Infrastructure: Aptible for Certified Hosting

The first decision was the hardest and the most important. We could build on raw AWS and construct the compliance layer ourselves. This is what most startups do. It takes 12-18 months to do correctly and it is still not third-party certified when you finish.

Instead we chose Aptible — a Platform-as-a-Service that holds SOC 2 Type II, HIPAA, and HITRUST certifications. Every application deployed on Aptible runs on infrastructure that has been independently audited. Our customers' agents inherit that certification from day one.

Database: Supabase with Row-Level Security

We chose Supabase (PostgreSQL) with Row Level Security enabled on every table. RLS means that multi-tenancy isolation is enforced at the database layer — not just in application code.

The audit log table has a specific constraint: it is append-only. Our database configuration prevents UPDATE and DELETE operations on audit records at the schema level. Not enforced only by application code — enforced by the database itself.

Secrets: HashiCorp Vault

Every API credential for every security tool connector is stored in HashiCorp Vault, deployed on Aptible. Credentials are never stored in our application database. They are never present in agent code. They are injected at runtime by our connector execution layer from Vault, after the policy engine has approved the specific operation.

Even if our application database were compromised, no credentials would be exposed. Vault is the only location they exist.

The SDK Intercept Pattern

The most novel architectural decision is the SDK intercept layer. When a customer's agent calls a connector method — for example, CrowdStrikeConnector.get_detections() — the SDK does not immediately call the CrowdStrike API. It intercepts the call, evaluates it against the policy engine, logs the intercept to the audit trail, routes it for human approval if required, and only then executes the API call with credentials retrieved from Vault.

This intercept happens transparently. The customer's agent code does not change. The governance layer is invisible to the agent and mandatory for all operations.

This is the architecture behind three of our five patent-pending mechanisms.

// MORE FROM ARX
MARKET INTELLIGENCE
The Agentic Transition in Cybersecurity: What It Means for Security Teams Right Now
Read post →
PROCUREMENT
What Security Procurement Teams Are Actually Asking When They Request a VSQ
Read post →

Ready to see what your team built?

Deploy your first agent in 14 days. No cost. No commitment.