ARCS/Crosswalks/ARCS / AIUC-1 Crosswalk
ARCS / AIUC-1 Governance Crosswalk
Source-element links point to official public source materials where stable public URLs are available. For standards or criteria that do not expose freely accessible clause-level text, links point to the official product, browsing, or reference page. The mapping remains informative.
Source-element links point to the current public AIUC-1 requirement pages. AIUC-1 updates quarterly; this crosswalk is pinned to the July 15, 2026 release and must be reviewed when the source framework changes.
Overview
AIUC-1 is an AI-agent assurance standard covering six domains. The Q3 2026 release added coding-agent controls for secrets management and secure generated code, expanded execution containment, renumbered A003 and B008 controls, strengthened third-party monitoring, and added platform/deployer shared-responsibility documentation.
ARCS is a separate standard for complete interaction-record custody. This crosswalk identifies overlap without erasing the boundary: AIUC-1 already governs portions of the operational record lifecycle, while ARCS governs record-class completeness, copy-level custody, lifecycle propagation, verifiable disposition, non-creation, and legal-process posture.
Interpretive status
This instrument does not restate AIUC-1 requirements, modify ARCS control text, or establish certification, conformance, equivalence, legal compliance, or control inheritance between the two instruments.
ARCS relevance
AIUC-1 specifies first-order operational controls for selected data, outputs, logs, storage, locations, vendor activity, and incident evidence. ARCS governs the custody system those controls do not complete: every interaction-record class and copy, every custodian and downstream processor, schedule propagation, verified deletion or non-creation, preservation beyond incident response, and production posture under legal process.
Framework scope
Table A maps the AIUC-1 families with a bounded ARCS relationship to ARCS control families at the theme level. Fit labels indicate the strength of that relationship within ARCS's narrower record-custody scope. Safety and Society outcomes without a record-custody attachment point are omitted.
| Family | Category / Theme | ARCS Families | Alignment |
|---|---|---|---|
| Family A | Input and output data retention, deletion, and customer rights | Strong | |
| Family A | Agent identity, permission, and delegation records | Strong | |
| Family A | Secrets handling across inputs, outputs, logs, and credential storage | Moderate | |
| Family B | Agent service restrictions and runtime containment records | Strong | |
| Family B | Authentication, transport, and agentic-interface integrity records | Strong | |
| Family B | Generated-code and configuration artifacts | Moderate | |
| Family D | Tool authorization, execution logging, and approval records | Strong | |
| Family E | Storage security, processing locations, and custody-surface documentation | Strong | |
| Family E | Vendor due diligence and third-party access monitoring | Strong | |
| Family E | System logging, retention settings, deletion rules, and integrity | Strong | |
| Family E | Incident evidence preservation and shared-responsibility records | Strong |
Selected mappings
Selected current AIUC-1 controls for which ARCS has a clear and bounded relationship. The mapping concerns the records created, stored, transferred, preserved, or deleted by the control; it does not claim that ARCS satisfies the underlying AIUC-1 outcome.
Family A: Data & Privacy
AIUC-1 Family A includes first-order controls for input and output retention and deletion, data access, agent identity and permissions, and secrets handling. ARCS contributes where those controls become a custody system: the full record-class inventory, propagation of schedules and deletion across every copy and processor, independently verifiable disposition, and lifecycle governance of identity, permission, and secrets-handling artifacts.
| Control | AIUC-1 Requirement | ARCS Controls | Fit | Note |
|---|---|---|---|---|
| A001 / A002 | Input and Output Data Policies. Requires documented retention, deletion, ownership, use, opt-in or opt-out, and customer-rights policies, with technical deletion and lifecycle implementation | ARCS-LIF (LIF-01 to LIF-13), ARCS-TAX (TAX-01, TAX-02), ARCS-VER (VER-01), ARCS-NCR (NCR-01) | Strong | AIUC-1 establishes first-order policy and implementation for specified inputs and outputs. ARCS asks whether every interaction-record class follows the declared schedule across application storage, infrastructure, backups, and subprocessors, and whether disposition can be independently verified. |
| A003.2 / A003.3 | Agent Identity and Permissions Management. Requires unique agent identity and permission-ready architecture, including bounded inheritance and just-in-time permissions | ARCS-VER (VER-01), ARCS-CUS (CUS-01), ARCS-AGT (AGT-01, AGT-03), ARCS-DEL (DEL-01) | Strong | Identity attestations, permission grants, inherited-scope records, and revocation events are themselves governed records. ARCS addresses their custody, classification, preservation, and delegation-chain lifecycle. |
| A008.1 / A008.5 | Secrets Detection and Stored-Artifact Redaction. Requires detection of credentials in inputs and controls preventing secrets from persisting in logs, conversation history, and stored artifacts | ARCS-TAX (TAX-01, TAX-02), ARCS-LIF (LIF-01, LIF-03), ARCS-CUS (CUS-04), ARCS-PV (PV-01) | Moderate | AIUC-1 governs secret detection and redaction. ARCS governs the custody and lifecycle of the underlying prompts, outputs, logs, redaction events, and any surviving copies across the record surface. |
Family B: Security
AIUC-1 Family B addresses infrastructure security, authentication, transport security, agent containment, and secure generated code. ARCS contributes where those controls create or transform persistent records, including access logs, signed interface messages, sandbox records, configuration artifacts, generated code, and dependency manifests.
| Control | AIUC-1 Requirement | ARCS Controls | Fit | Note |
|---|---|---|---|---|
| B006.1 / B006.3 | Agent Service Restrictions and Runtime Containment. Restricts agents to approved services and MCP servers and extends execution safeguards to agent-executed code and first-party MCP servers | ARCS-CUS (CUS-04, CUS-12), ARCS-OPB (OPB-03), ARCS-AGT (AGT-03) | Strong | Approval and containment reduce runtime risk but do not determine the custody posture of prompts, tool calls, code-execution records, sandbox logs, or vendor-retained copies. ARCS governs those record-bearing consequences. |
| B008.1 / B008.2 / B008.3 | Authentication, Transport, and Agentic-Interface Integrity. Requires authenticated callers, secure data in transit, and integrity controls across model APIs, MCP, and agent-to-agent interfaces | ARCS-CUS (CUS-01, CUS-04), ARCS-LIF (LIF-01), ARCS-VER (VER-01) | Strong | Authenticated, encrypted, and signed interfaces generate records on both sides of a connection. Transport security governs the channel; ARCS governs the records that flow through it and remain after it closes. |
| B010.3 / B010.6 | Secure Dependency and Logging Defaults in Generated Code. Requires safe dependency specification and defaults that avoid logging secrets or personal information | ARCS-TAX (TAX-02), ARCS-LIF (LIF-03), ARCS-VER (VER-01) | Moderate | Generated source, manifests, dependency-validation results, and logging templates are persistent artifacts. ARCS classifies those artifacts and governs their retention, custody, and verifiable disposition. |
Family D: Reliability
AIUC-1 Family D addresses hallucination reliability and unsafe tool calls. The bounded ARCS attachment point is the record surface created by tool authorization, execution monitoring, human approval, and periodic review. ARCS does not evaluate whether a tool call is behaviorally safe; it governs the records produced by that evaluation and execution.
| Control | AIUC-1 Requirement | ARCS Controls | Fit | Note |
|---|---|---|---|---|
| D003.1 / D003.3 / D003.4 | Tool Authorization, Logging, and Human Approval. Requires tool validation, execution logs, and approval workflows for sensitive operations | ARCS-AGT (AGT-03, AGT-05), ARCS-LIF (LIF-03), ARCS-CUS (CUS-04, CUS-07), ARCS-TAX (TAX-02) | Strong | Tool-call inputs, outputs, parameters, approval events, and execution results form an interaction-record chain. ARCS governs its taxonomy, custody, retention, and delegation context. |
Family E: Accountability
AIUC-1 Family E contains the strongest lifecycle overlap with ARCS. It includes incident evidence preservation, storage-security documentation, vendor due diligence, third-party access monitoring, processing-location records, activity-log retention and deletion, log integrity, and platform/deployer responsibility documentation. ARCS extends those first-order controls into complete, copy-level custody and legal-process governance.
| Control | AIUC-1 Requirement | ARCS Controls | Fit | Note |
|---|---|---|---|---|
| E001 | Security-Breach Failure Plan and Evidence Preservation. Requires incident response ownership, notification, remediation, and preservation of evidence for potential legal review | ARCS-PV (PV-01 to PV-07), ARCS-LIF (LIF-01) | Strong | AIUC-1 expressly reaches incident evidence preservation. ARCS extends beyond incident response to civil preservation triggers, multi-vendor hold propagation, record-class scope, and documented release or disposition. |
| E005 / E011 | Storage Security and Processing Locations. Requires documented storage-security practices and records of infrastructure regions, inference endpoints, third-party providers, subprocessors, and geographic data flows | ARCS-CUS (CUS-01 to CUS-12), ARCS-OPB (OPB-03), ARCS-TAX (TAX-01) | Strong | AIUC-1 documents known storage and processing locations, including third parties. ARCS adds copy-level custody lineage, persistence state, authorization gaps, and verified disposition across the disclosed and later-emerging custody chain. |
| E006 / E009 | Vendor Due Diligence and Third-Party Access Monitoring. Requires retained vendor-assessment evidence and logging of third-party API connections, sessions, and data access | ARCS-CUS (CUS-04, CUS-12), ARCS-OPB (OPB-03), ARCS-VER (VER-01), ARCS-LIF (LIF-12) | Strong | Vendor assessment and access monitoring do not by themselves establish whether each vendor copy follows operator retention and deletion, survives operator-visible deletion, or can be independently verified. ARCS governs that custody posture. |
| E015.1 / E015.2 / E015.3 / E015.4 | System and Agent Activity Logging. Requires logs of system activity and execution chains, defined log-retention and automatic-deletion settings, and optional tamper-evident integrity controls | ARCS-LIF (LIF-01, LIF-03), ARCS-VER (VER-01), ARCS-CUS (CUS-07), ARCS-TAX (TAX-02) | Strong | AIUC-1 already governs what to log, log storage, retention settings, deletion rules, and integrity. ARCS addresses completeness across all record classes and custodians, propagation of the declared lifecycle, and independent verification of disposition. |
| E017.3 | Platform and Deployer Security Responsibilities. Requires documentation delineating platform-level and deployer-level security obligations | ARCS-OPB (OPB-01, OPB-03), ARCS-CUS (CUS-04), ARCS-VER (VER-01) | Strong | Shared-responsibility documentation is a natural attachment point for custody allocation. ARCS requires the parties to identify who creates, holds, deletes, preserves, verifies, and can produce each record class; security responsibility alone does not complete that allocation. |
Complementary coverage
AIUC-1 and ARCS overlap at the operational record layer but address different assurance questions. AIUC-1 evaluates whether required policies and controls exist and whether agents resist defined security, safety, and reliability risks. ARCS evaluates whether the complete record surface is known and governed across its custody and lifecycle.
An organization can achieve AIUC-1 certification while retaining interaction records that may later become subject to discovery or other legal process. AIUC-1 requires meaningful lifecycle controls for specified inputs, outputs, and logs, as well as processing-location, vendor, and incident-evidence controls. ARCS addresses what remains: whether every record class and copy follows the declared lifecycle; whether deletion propagates and can be verified; who possesses, controls, preserves, and can produce each surviving record; and how those duties propagate across vendors and subprocessors.
Conversely, ARCS conformance does not establish that an agent is secure, safe, reliable, or resistant to adversarial attack. The frameworks are complementary, but neither should be described as occupying an entirely exclusive layer.
Outside scope
ARCS does not evaluate output safety, hallucination rates, adversarial robustness, runtime exploitation, secure-code quality, fairness, societal impact, or other AIUC-1 behavioral and operational outcomes. Its scope is interaction-record custody.
Within that narrower scope, ARCS goes beyond the reviewed AIUC-1 controls in the following areas:
Complete record-class coverage and lifecycle propagation
ARCS-LIF (LIF-01 to LIF-13), ARCS-TAX (TAX-01 to TAX-08)
AIUC-1 requires retention and deletion controls for specified inputs, outputs, and logs. It does not require one complete taxonomy spanning prompts, outputs, reasoning traces, tool calls, telemetry, caches, backups, intermediate artifacts, and every downstream copy, nor does it require proof that one declared schedule propagates to all of them. ARCS governs that completeness and propagation problem.
Copy-level custody and downstream propagation
ARCS-CUS (CUS-01 to CUS-12)
AIUC-1 requires processing-location documentation that can include providers, subprocessors, infrastructure regions, endpoints, and geographic data flows. ARCS goes further by mapping copy-level custody, persistence state, control and authorization gaps, and the path records take when disclosed processors create additional copies or forward data into later systems.
Civil discovery, legal hold, and production posture
ARCS-PV (PV-01 to PV-07), ARCS-CUS (CUS-01 to CUS-12)
AIUC-1 includes incident-response evidence preservation and general compliance controls. The reviewed controls do not specifically establish civil-discovery readiness, litigation-hold scope outside incident response, possession-custody-or-control analysis, subpoena allocation among platform and deployer, privilege handling, collection methodology, or production posture. ARCS governs those record-custody questions.
Provable non-creation posture
ARCS-NCR (NCR-01 to NCR-06)
AIUC-1 addresses retention, deletion, storage opt-out, and redaction for records that may be created. ARCS treats provable non-creation as a separate posture: memory-only processing, ephemeral operation, and declared non-retention verified as absence rather than as deletion after creation.
Delegation, memory, and intermediate-record persistence
ARCS-DEL (DEL-01 to DEL-12), ARCS-AGT (AGT-01 to AGT-08)
AIUC-1 governs agent identity, permissions, execution chains, and tool safety. ARCS governs the persistence and custody of records created during delegation, sub-agent handoffs, cross-session memory, retries, intermediate reasoning artifacts, and autonomous execution, including whether those artifacts inherit or diverge from the operator's declared lifecycle.
AIUC-1 updates quarterly. This crosswalk should be reviewed against each release, and its human-readable page, source links, registry metadata, JSON export, and CSV export should be updated as one governed change set.