AIUC-1 Control Mapping¶

AIUC-1 is the agent-native attestation standard published by the AI Underwriters Council. It is structured similarly to SOC 2 — a third-party attestation issued by an authorized assessor over an observation window — but its control surface is built specifically around the failure modes of AI agents rather than general-purpose SaaS.

This document maps AIUC-1's six control families to the ARX platform's primitives and clarifies what is delivered by the platform versus what remains a tenant responsibility. The mapping is also crosswalked to NIST AI RMF and ISO 42001, so evidence collected once can satisfy multiple frameworks.

How ARX Fits Into AIUC-1¶

AIUC-1 is structured for AI agents — systems that take autonomous actions on behalf of users. ARX is primarily a control plane that wraps customer-built agents, not an autonomous agent itself. ARX's attestation pursues the platform / infrastructure track of AIUC-1, with a thin builder-track scope for ARX's own AI surfaces (the LLM router, the MCP server, and any first-party LLM-augmented features).

For tenants, this means:

• If you build agents on ARX, you inherit a substantial portion of the AIUC-1 control surface from the platform — analogous to how SOC 2 customers on Aptible inherit infrastructure controls.
• You remain responsible for the agent itself: its behavior, its declared intent, the eval suites you run against it, and the human owners who answer for it.
• Foundation-model vendors (Anthropic, OpenAI, others) appear in the mapping as named subprocessors and are covered by their own attestations.

The shared-responsibility framing matches the SOC 2 carve-up that already exists in the SOC 2 Control Mapping. Auditors familiar with the Aptible-inherited pattern will recognise the structure.

Current alignment status: ARX maintains a control-by-control tracker for substantive alignment with the AIUC-1 standard, separate from the third-party certification path. See the AIUC-1 Alignment Tracker for live status (Met / Partial / Gap per control), and the AIUC-1 Readiness Plan for the program path.

Responsibility Model¶

The AIUC-1 responsibility model for ARX has three layers:

An assessor evaluating a tenant's AIUC-1 posture for AI agent operations can point to Aptible's SOC 2 Type II report for infrastructure controls, ARX's platform attestation for the agent runtime, and the tenant's own configuration and operating evidence for the residual responsibilities.

What the platform-track attestation covers (and doesn't): ARX attests that its control plane delivers the primitives listed in the table below — and that ARX's own narrow first-party AI surface (LLM router and MCP server) meets builder-track controls. ARX does not attest on behalf of customer agents; the agent itself remains the tenant's responsibility, and AIUC-1 controls applied to it must come from the tenant's own program (with ARX evidence as inheritable artifacts).

Control Families & Crosswalk¶

AIUC-1 organizes controls into six families. Each family below shows how ARX primitives produce the evidence and what the corresponding NIST AI RMF / ISO 42001 anchors are.

SAF — Safety¶

Intent: The agent does not take harmful actions, and remains within a declared scope of behavior. Crosswalk: NIST AI RMF MEASURE 2.6 / 2.7; ISO 42001 A.6.2.4.

ARX Platform Controls¶

• Declared intent manifests (INV-003): Each agent ships with a manifest declaring permitted systems, actions, and data types. The platform refuses anything outside the manifest at the connector boundary.
• Behavioral drift detection: Live agent behavior is continuously compared to the manifest. Drift events are classified by severity and trigger auto-throttle or auto-suspend without human delay.
• Adversarial-prompt regression suite: Each release is replayed against a stored corpus of jailbreak / injection / scope-bypass prompts. Failures block the release.

Tenant Responsibility¶

• Defining the declared intent manifest accurately for each agent.
• Running periodic red-team exercises and contributing the resulting prompts back to the regression corpus.
• Triaging drift events and documenting the root cause.

Evidence: Audit log entries with action_type of drift.detected, policy.violated, and agent.suspended; per-release adversarial replay reports archived in the compliance package.

SEC — Security¶

Intent: The agent and its credentials cannot be compromised, exfiltrated, or escalated. Crosswalk: NIST AI RMF MANAGE 2.1; ISO 42001 A.7.4; SOC 2 CC6.1 / CC6.6.

ARX Platform Controls¶

• Agent identity: Every agent has a platform-issued identity. Connector credentials never leave the platform; the agent receives short-lived handles bound to the agent identity.
• Connector scope binding: Each connector configuration declares permitted_operations. Calls outside that list are rejected before they reach the upstream API.
• Tenant isolation: Row-Level Security enforces per-organization isolation at the database layer; a misconfigured query cannot cross tenants.

Tenant Responsibility¶

• Setting permitted_operations with the principle of least privilege.
• Configuring SSO / SAML for human access.
• Rotating tenant API keys on a documented cadence.

Evidence: Audit log entries with action_type of connector.called and policy.evaluated; key-rotation records.

REL — Reliability¶

Intent: The agent fails predictably, recovers, and never silently produces wrong results when its environment degrades. Crosswalk: NIST AI RMF MEASURE 4.2; ISO 42001 A.6.2.7.

ARX Platform Controls¶

• Model-provider failover (INV-006): LLM calls flow through a provider-neutral router. Transient failures (401, 403, 429, 5xx, timeout) hop to the next provider; deterministic failures (400, content-policy) re-raise immediately so they cannot be silently masked.
• Versioning & rollback: Every agent deployment creates an immutable version record. Rollback is one operation and is itself audit-logged.
• Drift-triggered auto-suspension: An agent exhibiting critical drift is suspended automatically with full audit context.

Tenant Responsibility¶

• Declaring the per-org provider failover order.
• Maintaining release-level eval reports and regression suites.
• Investigating suspended agents before restoring service.

Evidence: Audit rows with provider_used and failover_hops populated; agent.rolled_back entries; per-release eval reports.

ACC — Accountability¶

Intent: Every action the agent took is attributable to a human owner and reviewable by an auditor without trusting the vendor. Crosswalk: NIST AI RMF GOVERN 1.4; ISO 42001 A.4; SOC 2 CC8.1.

ARX Platform Controls¶

• Approval gates inside the connector: High-risk actions pause for a named human approver. The approval record is bound into the audit chain — the action and its approval are inseparable.
• Tamper-evident audit trail (INV-001): The log tip is hash-chained and signed every five minutes to a witness bucket the customer owns. ARX can write to the bucket but cannot read or delete from it.
• Customer-side verification: verify_chain() runs against the witness bucket and an exported audit slice; if the tip does not match, the chain is provably broken.

Tenant Responsibility¶

• Naming an owner for every registered agent.
• Staffing the approval queue within the policy timeout.
• Periodically running verify_chain from the witness bucket.

Evidence: Witness-bucket signatures; approval.requested / approval.granted / approval.denied audit entries; verification run records.

PRV — Data Privacy¶

Intent: Personal and sensitive data is identified, minimized, and not exfiltrated through the model. Crosswalk: NIST AI RMF MAP 3.1; ISO 42001 A.7.2; GDPR Art. 5; HIPAA §164.312.

ARX Platform Controls¶

• PII redaction at the prompt boundary: Configurable redaction rules are applied to prompts and tool inputs before they leave the platform. Redacted spans are recorded so the audit row remains complete without storing the underlying PII.
• Region-pinned routing: Tenants choose US or EU residency; calls are pinned at the router, not just at storage.
• BYO-KMS: Customers may bring their own KMS in AWS, Azure, or GCP; ARX never holds plaintext.

Tenant Responsibility¶

• Configuring redaction rules to match the data classes the agent handles.
• Maintaining the data-classification map for each connector.
• Honoring data-subject access requests against agent logs.

Evidence: redaction.applied audit metadata; data-residency configuration history; KMS key-rotation records.

SOC — Society¶

Intent: Foreseeable harms beyond the immediate user — bias, disparate impact, manipulation, environmental cost — are surfaced, reviewed, and disclosed. Crosswalk: NIST AI RMF GOVERN 3.2 & MAP 1.1; ISO 42001 A.5; EU AI Act Art. 9 & 10.

ARX Platform Controls¶

• Risk classification per agent: At registration, each agent is tagged with a risk band aligned to EU AI Act tiers (minimal / limited / high). High-risk agents cannot deploy without an attached conformity packet.
• Bias evaluation hook: A standardized eval slot in the release pipeline accepts the tenant's bias / fairness suite and binds the run record into the compliance package.
• Disclosure surfaces: Per-agent system cards rendered from registry state; downloadable in the customer-facing trust package.

Tenant Responsibility¶

• Selecting and maintaining the fairness / bias eval suite appropriate to the agent's task.
• Publishing the system card to affected stakeholders.
• Reviewing high-risk classifications quarterly.

Evidence: Bias eval run records bound to release; system-card publish history; risk-band change log.

Summary Matrix¶

ARX Vendor-Side Attestation¶

ARX itself is pursuing AIUC-1 attestation under the platform / infrastructure track described above, plus a narrow builder-track scope for the LLM router and MCP server. Readiness completion targeted Q3 2026; Type II report Q2 2027, following the 6-month observation window and audit fieldwork. The current plan is Type II only — a Type I (point-in-time) report would land sooner but matures buyers see through it; the additional cost isn't justified unless a specific deal cycle requires it.

The customer-facing mapping above is independent of ARX's own attestation status — it describes how the platform helps tenants meet AIUC-1, regardless of when ARX's own report lands. The internal readiness plan (gap list, scope statement, owners, timeline) lives at AIUC-1 Readiness — Internal Plan.

Need SOC 2 instead?¶

See the SOC 2 Control Mapping for how ARX maps to Trust Service Criteria. AIUC-1 evidence and SOC 2 evidence are produced from the same audit chain — adopting AIUC-1 does not require re-instrumenting your agents.