Public documentation for governed AI labor
SDKs/Governance/Connectors
Arx / Docs / ARX Technical Trust Pack

Documentation

ARX Technical Trust Pack

Project-Agent-trust-merge / sales-assets/technical_trust_pack.md

Project-Agent-trust-merge market sales-assets/technical_trust_pack.md

Audience: CEO sponsors, CISO/CIO validators, CFO/CHRO stakeholders, and internal procurement teams at regulated enterprises.

Positioning sentence: ARX helps a regulated enterprise deliver one measurable business outcome with AI labor, then prove that the result came from a governed operating model with scoped identity, human supervision, verifiable records, and a clean termination path.

What This Package Is For

Use this document immediately after a first CEO or CXO conversation. It is designed to be forwarded internally without requiring a second pitch deck.

The goal is to answer five questions quickly:

  1. What exactly is ARX?
  2. How does it fit with our existing security and governance stack?
  3. What would the first 90 days look like?
  4. What proof would our security team and auditor actually inspect?
  5. How mature is the product today, honestly?

Category And Buyer Map

ARX should still be introduced as AI workforce infrastructure or the control plane for enterprise AI agents.

But the first sentence in a live pitch should usually be an outcome claim, not a category claim.

Examples:

  • We can reduce close-cycle time in one regulated finance workflow inside ninety days.
  • We can lower cost-to-serve in one approval-heavy operating workflow without weakening control.
  • We can deliver measurable growth or gross-profit lift in one named market wedge, then prove how the work was governed.

It should not be introduced as only:

  • a generic AI governance platform
  • a runtime security tool
  • a model vendor
  • a no-code agent builder

Primary buyer map:

  • CEO sponsors the category decision: whether AI is treated as governed labor or as unmanaged software sprawl.
  • CHRO / COO validate the operating model: role definitions, reporting chains, approval paths, workforce design.
  • CFO validates the pilot economics: named workflow improvement, cost-to-serve delta, or FTE-equivalent gain.
  • CISO / CIO validate the control plane: identity, approval enforcement, auditability, deployment posture, and rollback.

What ARX Adds To The Existing Stack

ARX is additive to the tools a regulated enterprise already owns.

| Existing layer | What it already does | What ARX adds | |---|---|---| | IAM / IdP | Issues credentials and centralizes access | Binds one scoped identity to one digital worker with declared role scope | | SIEM / logging | Collects events and alerts | Creates a worker-level personnel record with attribution, approvals, and lifecycle context | | AI security / guardrails | Detects prompt attacks, data leakage, or unsafe outputs | Adds supervision, execution controls, approval routing, and termination | | GRC / policy tooling | Tracks policies, exceptions, and control reviews | Connects those policies to live agent execution and evidence generation |

Short version for the CISO:

> Keep the existing stack. ARX is the control plane that turns those tools into a governable operating model for AI labor.

Deployment And Data Posture

The preferred posture for executive conversations is simple and concrete:

  • Atlas runs inside the customer's environment. See docs/atlas/atlas-spec.md.
  • No exfiltration to ARX is required for Atlas. The customer controls egress, observability, storage, and KMS.
  • Per-agent credentials are scoped and short-lived. See docs/credentials/per-agent-auth-integration.md.
  • The audit chain lands in customer-controlled infrastructure.
  • Termination is explicit and operational, not rhetorical.

Use these technical truths in diligence:

  • Customer-private deployment is the default trust posture for Atlas.
  • The customer's own infrastructure team can inspect network policy, image provenance, and audit-chain integrity.
  • ARX is designed to work with the customer's chosen LLM provider rather than forcing a model contract.

90-Day Controlled Pilot

The first offer should be a controlled pilot, not a broad rollout.

Default pilot shape:

  • Executive surface: Atlas for brief / decision support / audit visibility
  • Workflow scope: 1-2 high-value cohorts only
  • Industry fit: regulated enterprise, ideally financial services, healthcare, insurance, or industrials
  • Write posture: read-only or approval-gated first, then selective live execution
  • Success artifact: one board-ready outcome story plus one auditor-verifiable evidence package
  • Pitch posture: lead with the business claim; use ARX's controls as the reason the claim is safe to believe

Recommended pilot timeline:

  1. Days 0-14 — deploy Atlas, confirm systems in scope, define KPIs, bind approvers, and agree the rollback path.
  2. Days 15-45 — run cohorts in shadow or approval-gated mode, collect audit records, and tune approval posture.
  3. Days 46-75 — move selected workflows into governed production with named managers and daily monitoring.
  4. Days 76-90 — produce the executive outcome readout and the evidence package for validator review.

Recommended first-cohort examples:

  • Financial services: finance audit prep, reconciliation, security triage
  • Healthcare: audit prep, member-support triage, patch verification
  • Industrials: incident triage, configuration drift monitoring, audit prep

What Proof The Customer Should Expect

The pilot should prove both business value and control value.

Business proof:

  • one named KPI improved
  • one workflow moved faster or at lower cost
  • one outcome headline the CEO can repeat in a sentence
  • one executive narrative the CFO or COO can repeat in a board context

Control proof:

  • one evidence package that maps control claims to observed behavior
  • one approval trail with named humans and timestamps
  • one worker-level audit trail the customer's team can inspect independently

Supporting references in-repo:

Honest Maturity Statement

Use this wording externally:

> ARX's governance and control-plane primitives are the most production-forward part of the platform today: scoped identity, approval routing, audit-chain posture, and customer-private Atlas deployment. Reference agents and ecosystem variants provide the workforce model and deployment shape, but customer-specific live integrations and richer agent intelligence are still deployed cohort by cohort.

What to avoid saying:

  • that every agent cell is turnkey and equally production-deep
  • that ARX replaces the customer's existing security stack
  • that ARX is a generic AI governance dashboard with no deployment substance

Objection Handling

"Why not use our existing AI governance platform?"

Most AI governance platforms help inventory, review, and document AI systems. ARX is stronger where the customer needs workforce control: scoped worker identity, execution-time approvals, personnel records, and clean termination across systems.

"Why not rely on our security stack?"

The current stack secures systems and identities. It does not create a worker model for AI agents with declared scope, named supervisors, and audit records that map to one digital employee over time.

"Why not just use model-provider guardrails?"

Model-provider guardrails are useful, but they are provider-scoped and model-scoped. They do not solve cross-system supervision, customer-controlled records, or workforce lifecycle management.

Forwardable Next Step

The recommended next step after a first executive conversation is:

  1. CEO or CXO sponsor requests the trust pack and the relevant industry wedge brief.
  2. CISO/CIO review the deployment and control posture.
  3. CFO/COO align on one pilot KPI and one workflow wedge.
  4. ARX and the customer scope a 90-day controlled pilot.