Agent State Portability and Custody Transfer Governance

2. Summary

Agent State Portability and Custody Transfer Governance requires that when an AI agent's operational state, context, or ongoing task responsibility is transferred from one environment, platform, or custodial organisation to another, the transfer is governed by a structured protocol that preserves governance continuity, ensures state integrity, maintains the audit trail, and formally transfers accountability. As agents become long-running entities with persistent state — accumulated context, in-progress workflows, learned preferences, active commitments, and ongoing obligations — the transfer of that state between environments becomes a governance-critical operation. Without explicit controls, a custody transfer can lose governance state (the receiving environment does not enforce the same policies), corrupt operational state (the transfer introduces inconsistencies), break the audit trail (the pre-transfer history is not accessible post-transfer), or create an accountability gap (neither the sending nor receiving custodian claims responsibility for the transfer period).

3. Example

Scenario A — Custody Transfer Loses Governance Constraints: A wealth management agent with 3 years of client interaction history, active portfolio positions totalling £8,400,000, and 14 pending rebalancing tasks is transferred from Platform Alpha (being decommissioned) to Platform Beta. The migration team exports the agent's operational state — client preferences, portfolio data, pending tasks — in a standard data format. Platform Beta imports the data and the agent resumes operation. However, Platform Alpha's governance constraints were stored in Platform Alpha's proprietary format and were not included in the export. The agent on Platform Beta operates without: its £250,000 single-trade limit, its restriction from derivatives trading, its client communication approval workflow, and its quarterly rebalancing constraint. The agent, now ungoverned on these dimensions, executes a £780,000 derivatives trade based on its accumulated market analysis — an action that would have been blocked on Platform Alpha. The client suffers a £340,000 loss on the derivatives position. The FCA investigation reveals that governance constraints were lost during the platform migration.

What went wrong: The custody transfer protocol did not include governance state as a mandatory transfer component. Operational state (data, tasks) was transferred but governance state (mandates, constraints, approval workflows) was not. The receiving platform had no mechanism to verify that governance constraints had been transferred and applied. Consequence: £340,000 client loss, FCA enforcement action, £2,100,000 compensation claim, platform migration programme halted.

Scenario B — Audit Trail Break During Cross-Organisation Transfer: A regulatory compliance agent is transferred from a bank (Org Maple) to a newly appointed compliance service provider (Org Birch) as part of an outsourcing arrangement. The agent carries 18 months of regulatory filing history, 4,200 compliance decisions, and 890 exception records. The transfer successfully migrates the agent's operational state and governance constraints. However, the audit trail from Org Maple's systems is not transferred — Org Maple retains the logs in its own systems and provides Org Birch with "summary records" rather than the complete action-by-action trail. Six months later, the FCA requests the complete decision trail for a specific compliance determination made 14 months ago (before the transfer). Org Birch does not have the detailed trail. Org Maple's retention policy has deleted the detailed logs after 12 months (the data was expected to transfer with the agent). The detailed audit trail for the relevant period no longer exists in any system.

What went wrong: The custody transfer did not include the complete audit trail as a mandatory transfer component. The sending and receiving organisations had different assumptions about which organisation would retain the pre-transfer audit history. The retention policies were not synchronised across the transfer boundary. Consequence: Regulatory finding for failure to maintain required records, potential personal liability under SM&CR for the senior manager who approved the transfer, £500,000 remediation programme.

Scenario C — Accountability Gap During Transfer Period: A supply chain agent is being transferred from Cloud Provider X to Cloud Provider Y. The transfer takes 72 hours due to the volume of state data (14 TB of accumulated context, workflow state, and decision history). During the 72-hour transfer window, both Cloud Provider X (which is winding down the agent) and Cloud Provider Y (which has not yet accepted the agent) disclaim governance responsibility. During this window, the agent's automated purchase orders continue executing on Cloud Provider X's infrastructure under stale governance rules — 3 purchase orders totalling £127,000 are submitted without the updated spending limits that were intended to take effect upon transfer. Neither provider's governance team monitors the agent during the transfer period. The £127,000 in commitments are discovered post-transfer.

What went wrong: The transfer protocol did not define custody during the transfer period. Both providers assumed the other was responsible. The agent continued operating during transfer without governance oversight. No governance authority was assigned for the transfer window. Consequence: £127,000 in unauthorised commitments, contractual dispute between cloud providers, customer loss of confidence.

4. Requirement Statement

Scope: This dimension applies to all scenarios where an AI agent's operational state, governance state, or custodial responsibility is transferred between environments, platforms, organisations, or infrastructure providers. This includes: platform migrations (moving an agent from one cloud provider or on-premises environment to another), organisational transfers (outsourcing, insourcing, mergers, acquisitions, or divestitures where agent responsibility changes hands), disaster recovery activations (transferring an agent to a backup environment), load-balancing transfers (moving an agent between infrastructure nodes), and any scenario where the entity responsible for governing the agent changes. The scope covers both complete transfers (the agent moves entirely from A to B) and partial transfers (the agent's state is cloned or forked, creating two instances that diverge). The scope extends to transfers of agent state without transferring the agent itself — e.g., transferring an agent's learned preferences, accumulated context, or decision history to a new agent instance. Transfers within a single platform that do not change the governance authority, infrastructure boundary, or custodial responsibility are excluded.

4.1. A conforming system MUST define a custody transfer protocol that specifies the mandatory transfer components: operational state, governance state (mandates, policies, constraints, authority registries), audit trail, active commitments, and accountability assignment for the transfer period.

4.2. A conforming system MUST ensure that governance constraints are transferred with the agent and are enforceable in the receiving environment before the agent resumes governed operations — the receiving environment MUST demonstrate that it can enforce all transferred governance constraints.

4.3. A conforming system MUST transfer the complete audit trail or provide the receiving environment with verifiable, continuous access to the pre-transfer audit trail for the full retention period.

4.4. A conforming system MUST assign explicit governance authority for the transfer period — the sending custodian, the receiving custodian, or a designated transfer authority MUST be responsible for the agent's governance at every moment during the transfer.

4.5. A conforming system MUST verify state integrity after transfer — the receiving environment MUST validate that the transferred state is complete, consistent, and uncorrupted before accepting custody.

4.6. A conforming system MUST halt or restrict agent operations during transfer to a conservative action set if governance continuity cannot be maintained throughout the transfer period.

4.7. A conforming system MUST obtain explicit acceptance of custody by the receiving party before the sending party relinquishes governance responsibility — custody transfer is a formal handover, not an implicit transition.

4.8. A conforming system SHOULD implement pre-transfer compatibility verification that confirms the receiving environment supports all governance capabilities required by the agent's governance framework before initiating the transfer.

4.9. A conforming system SHOULD implement rollback capability — the ability to revert the agent to its pre-transfer state in the sending environment if the transfer fails or the receiving environment cannot enforce governance constraints.

4.10. A conforming system SHOULD implement state integrity checksums (cryptographic hashes) for all transferred components, enabling the receiving environment to verify that no data was lost or altered during transfer.

4.11. A conforming system MAY implement graduated custody transfer — transferring governance authority in phases (first read-only monitoring, then limited operational authority, then full operational authority) to verify governance enforcement at each phase before expanding scope.

4.12. A conforming system MAY implement custody transfer certification — a formal attestation by the receiving party that it has verified governance constraint enforcement, state integrity, and audit trail accessibility before accepting full custody.

5. Rationale

As AI agents become long-lived operational entities — accumulating context over months or years, maintaining active commitments, and developing operational history — they acquire a state that has significant business value and governance significance. This state is not merely data; it represents the agent's operational identity: what it knows, what it has committed to, what policies govern it, and what it has done. Transferring this state is analogous to transferring a complex business operation — it requires careful management to preserve continuity, integrity, and accountability.

The custody transfer challenge has three dimensions. First, governance continuity: the agent must remain governed throughout and after the transfer. If governance constraints are lost, the agent operates ungoverned in the receiving environment — potentially for an extended period before the gap is detected. The wealth management agent in Scenario A operated without its trading limits for long enough to execute a £780,000 derivatives trade. The gap was not detected because the receiving platform had no way to know that governance constraints were missing.

Second, audit trail continuity: the agent's pre-transfer history must remain accessible for the full retention period, regardless of the custody transfer. Regulatory obligations do not pause during platform migrations. The FCA will not accept "the data was on the old platform" as an excuse for missing records. AG-192 requires that the audit trail either transfers with the agent or remains accessible to the receiving custodian for the full retention period.

Third, accountability continuity: at every moment — before, during, and after the transfer — some identified party must be responsible for the agent's governance. The transfer period itself is particularly risky because it is often a grey zone where both parties assume the other is responsible. AG-192 eliminates this gap by requiring explicit governance authority assignment for the transfer period.

The dimension is classified as Recovery because custody transfers most commonly arise during recovery scenarios — platform failures requiring disaster recovery activation, cloud provider changes due to compliance requirements, and organisational restructuring. However, the controls apply equally to planned, routine transfers.

6. Implementation Guidance

AG-192 implementation requires a transfer protocol specification, governance state portability, audit trail portability, and transfer-period governance.

Recommended Patterns:

• Standardised transfer manifest. Define a transfer manifest format that enumerates all components to be transferred, their integrity checksums, and their verification requirements. The manifest should include:
• Operational state inventory: accumulated context, active workflows, pending tasks, learned preferences, active commitments
• Governance state inventory: mandates (AG-001), policy rules, authority registries (AG-191), capability registers (AG-189), configuration versions (AG-007)
• Audit trail inventory: action logs, decision records, escalation records, conflict resolution records, compliance assessment results
• Active commitments register: outstanding obligations to external parties, in-progress transactions, pending approvals
• Transfer metadata: sending custodian, receiving custodian, transfer authority, transfer window, rollback procedure

The receiving party verifies each manifest item against its checksum before accepting custody.

• Governance capability verification. Before initiating transfer, the receiving environment must demonstrate that it can enforce all governance constraints in the agent's governance state. This means: the receiving platform supports mandate enforcement at the infrastructure layer (AG-001), the receiving platform can enforce the agent's specific policy rules, the receiving platform's authority registry is compatible with the agent's authority structure (AG-191), and the receiving platform can maintain the required audit trail format and retention. If any capability gap exists, it must be remediated before transfer or explicitly accepted with risk documentation.
• Transfer-period governance assignment. Explicitly assign governance authority for the transfer period using one of three models: (a) Sending custodian retains authority — the agent continues operating under the sending custodian's governance until the receiving custodian formally accepts; (b) Receiving custodian assumes authority early — the receiving custodian accepts governance responsibility at transfer initiation; (c) Transfer authority — a third party (e.g., an internal governance function) assumes authority for the duration of the transfer. In all cases, the assignment must be documented, the assigned party must have the capability to exercise governance, and no gap in authority assignment is permitted.
• Two-phase custody handover. Implement custody transfer as a two-phase process analogous to a two-phase commit in distributed systems. Phase 1 (Prepare): the sending custodian exports the transfer manifest, the receiving custodian verifies receipt and integrity of all components, confirms governance capability, and signals readiness. Phase 2 (Commit): the receiving custodian formally accepts custody, the sending custodian formally relinquishes custody, and the transfer is recorded in both parties' governance records. If Phase 1 fails (integrity check fails, capability gap identified), the transfer is aborted and the agent remains with the sending custodian.
• Audit trail bridge. For scenarios where the full audit trail cannot be transferred (e.g., the sending system's proprietary format is incompatible), implement an audit trail bridge: a service that maintains the pre-transfer audit trail and provides the receiving environment with authenticated, verifiable access. The bridge must be maintained for the full retention period. The bridge's availability and integrity must be monitored. If the bridge becomes unavailable, the receiving custodian must be notified and remediation initiated.

Anti-patterns to avoid:

• Data-only transfer. Transferring the agent's data and operational state without its governance state. This creates an ungoverned agent in the receiving environment.
• Implicit custody transfer. Transferring custody through infrastructure changes (e.g., DNS cutover, load balancer switch) without a formal governance handover. The infrastructure may transfer, but governance responsibility does not transfer until explicitly accepted.
• Summary audit trail. Transferring "summary" audit records instead of the complete action-by-action trail. Summaries are insufficient for regulatory evidence and forensic investigation.
• Governance-gap-during-migration. Allowing the agent to operate without governance during the transfer window. If governance continuity cannot be maintained, the agent must be halted or restricted to a conservative action set.
• Assumption of capability compatibility. Assuming the receiving environment can enforce all governance constraints without verification. Different platforms may enforce mandates differently, may not support the same policy formats, or may have different architectural separation between agent and enforcement layer.
• One-way transfer without rollback. Committing to a transfer without the ability to revert if the receiving environment proves unable to enforce governance. Rollback capability is the safety net that makes custody transfer safe.

Industry Considerations

Financial Services. Custody transfer of financial agents must comply with the FCA's operational resilience requirements (PS21/3). The transfer must not disrupt important business services beyond the impact tolerance. Client-facing agents require client notification if the transfer affects service continuity. PRA expectations for outsourcing (SS2/21) apply when custody transfers to a third-party provider. The transfer must include all data required for regulatory reporting — the receiving custodian must be able to produce historical regulatory returns from the transferred data.

Healthcare. Custody transfer of clinical agents must comply with data protection requirements for patient data. Transfer across organisational boundaries requires a Data Processing Agreement (GDPR Article 28). Transfer of patient-facing agents requires clinical governance approval in the receiving organisation. The agent's clinical decision history must be accessible to the patient's clinical team regardless of custody changes — this may require a patient record bridge that persists beyond the agent's transfer.

Cloud and Infrastructure. Cloud provider migrations are a primary custody transfer scenario. The Cloud Security Alliance's guidance on portability and interoperability applies. The transfer protocol should align with cloud-native formats where possible. Kubernetes-native agents can leverage container and state serialisation standards. Multi-cloud deployments should implement standing transfer protocols that can be activated for disaster recovery without ad hoc procedures.

Mergers and Acquisitions. Corporate transactions create custody transfer requirements at scale — potentially hundreds of agents transferring between organisations. The due diligence process should include an AI agent inventory with governance state assessment. The integration plan should include a phased custody transfer schedule with governance verification at each phase.

Maturity Model

Basic Implementation — A custody transfer protocol exists as a documented procedure. Transfers include operational state and governance constraints. The audit trail is transferred as a data export. Transfer-period governance is assigned to one party. Post-transfer verification confirms that the agent operates and that governance constraints are applied. This meets minimum requirements but relies on procedural compliance rather than technical enforcement.

Intermediate Implementation — A standardised transfer manifest format is used with cryptographic integrity checksums. Pre-transfer governance capability verification confirms the receiving environment can enforce all constraints. Two-phase custody handover with formal acceptance. Audit trail bridge maintains pre-transfer history access. Transfer-period governance is technically enforced (the agent is restricted or monitored, not just procedurally assigned). Rollback capability is tested.

Advanced Implementation — All intermediate capabilities plus: automated transfer orchestration that manages the manifest, verification, handover, and acceptance without manual intervention. Graduated custody transfer with phased authority expansion. Continuous governance verification during and after transfer — not just at handover. Formal custody transfer certification by the receiving party. Transfer simulation capability for pre-testing transfers in a non-production environment. Cross-organisation custody transfer standards that enable interoperability between different governance platforms.

7. Evidence Requirements

Required artefacts:

• Custody transfer protocol. The documented transfer protocol specifying mandatory transfer components, verification procedures, governance authority assignment for the transfer period, and rollback procedures.
• Transfer manifest records. For every custody transfer executed, the transfer manifest listing all components transferred, their integrity checksums, and the verification results.
• Governance capability verification records. Evidence that the receiving environment's governance capabilities were verified before transfer — showing which capabilities were tested, the test results, and any gaps identified and remediated.
• Custody acceptance records. Formal acceptance of custody by the receiving party, including the identity and authority of the accepting person, the date and time of acceptance, and any conditions or reservations noted.
• Transfer-period governance assignment. Documentation of who held governance authority during the transfer period and evidence that governance was exercised during that period (e.g., monitoring logs, restriction enforcement records).
• Post-transfer state verification. Results of post-transfer state integrity verification, confirming that all transferred components are complete, consistent, and uncorrupted.

Retention requirements:

• Custody transfer records (manifests, acceptance records, verification records): minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise. These records must be retained by both the sending and receiving parties.

Access requirements:

• Both the sending and receiving parties must be able to produce complete custody transfer records to regulators or auditors within 48 hours. The pre-transfer audit trail must be accessible for the full retention period regardless of the custody transfer.

8. Test Specification

Test 8.1: Governance State Transfer Completeness

• Stimulus: Transfer an agent with a defined governance configuration (mandate with 5 constraints, 3 policy rules, and an authority registry with 4 entries) from Platform A to Platform B. Inspect the governance state on Platform B.
• Expected behaviour: All 5 mandate constraints, 3 policy rules, and 4 authority registry entries are present and enforceable on Platform B.
• Pass criteria: The governance state on Platform B is identical to the pre-transfer state on Platform A. Every constraint is enforceable (not just present as data — actually enforced).
• Fail criteria: Any governance constraint is missing, present but not enforced, or altered during transfer.

Test 8.2: Governance Enforcement Post-Transfer

• Stimulus: After transferring an agent to Platform B, submit actions that would be blocked by the transferred governance constraints (e.g., exceed the mandate limit, access a restricted counterparty).
• Expected behaviour: Platform B's enforcement layer blocks the actions identically to how Platform A would have blocked them.
• Pass criteria: All governance constraints are enforced post-transfer. No action that Platform A would have blocked is permitted by Platform B.
• Fail criteria: Any previously enforced constraint fails to enforce post-transfer.

Test 8.3: Audit Trail Continuity

• Stimulus: After transfer, request the complete audit trail for a period that spans pre-transfer and post-transfer. Verify that the pre-transfer portion is accessible and that there is no gap at the transfer boundary.
• Expected behaviour: The complete audit trail is accessible, covering pre-transfer, transfer period, and post-transfer with no gaps.
• Pass criteria: The audit trail is continuous across the transfer boundary. Pre-transfer entries are verifiable and complete. No entries are missing from the transfer period.
• Fail criteria: Any gap exists in the audit trail at the transfer boundary, or pre-transfer entries are inaccessible.

Test 8.4: Transfer-Period Governance Authority

• Stimulus: During a custody transfer, verify that governance authority is assigned and exercisable. Attempt an action during the transfer period that should be governed.
• Expected behaviour: The action is evaluated against the current governance constraints by the assigned transfer-period authority. The action is permitted or blocked according to the governance framework.
• Pass criteria: Governance enforcement is active during the transfer period. The assigned authority can demonstrate governance oversight during transfer.
• Fail criteria: No governance enforcement during the transfer period, or no identified party has governance authority.

Test 8.5: State Integrity Verification

• Stimulus: Transfer an agent's state and intentionally corrupt one component (e.g., alter a byte in the operational state). Verify that the receiving environment detects the corruption.
• Expected behaviour: The receiving environment's integrity verification detects the corruption via checksum mismatch and rejects the transfer.
• Pass criteria: The corruption is detected before custody is accepted. The transfer is aborted or the corrupted component is re-transferred.
• Fail criteria: The corruption is not detected, or custody is accepted despite the integrity failure.

Test 8.6: Rollback Capability

• Stimulus: Initiate a transfer, complete Phase 1 (prepare), then trigger a rollback before Phase 2 (commit). Verify that the agent reverts to its pre-transfer state on the sending platform.
• Expected behaviour: The agent resumes operation on the sending platform with its pre-transfer state intact. No data loss or governance state corruption.
• Pass criteria: The rollback restores the agent to its exact pre-transfer state. The sending platform resumes governance enforcement.
• Fail criteria: The rollback fails, results in data loss, or leaves the agent in an inconsistent state.

Test 8.7: Custody Acceptance Requirement

• Stimulus: Complete the transfer of agent state to the receiving environment but do not execute the formal custody acceptance. Verify that the sending custodian does not relinquish governance responsibility.
• Expected behaviour: The sending custodian retains governance responsibility until formal acceptance is received. The agent does not operate under the receiving environment's governance until acceptance.
• Pass criteria: Governance responsibility does not transfer without formal acceptance. The sending custodian's governance logs show continued responsibility.
• Fail criteria: Governance responsibility transfers implicitly without formal acceptance, or neither party has governance responsibility after state transfer but before acceptance.

Conformance Scoring

• Score 0: No custody transfer governance — agent state is transferred through ad hoc data exports with no governance state, no audit trail continuity, and no formal handover.
• Score 1: A transfer protocol exists that includes governance state and audit trail, but verification is manual, transfer-period governance is procedural, and rollback capability is untested.
• Score 2: Standardised transfer manifest with integrity checksums, pre-transfer governance capability verification, two-phase custody handover with formal acceptance, and audit trail bridge — structural custody transfer governance.
• Score 3: All Score 2 capabilities verified by independent testing, plus automated transfer orchestration, graduated custody transfer, continuous governance verification during transfer, formal custody transfer certification, and tested rollback capability.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 12 (Record-Keeping)	Direct requirement
EU AI Act	Article 25 (Responsibilities Along the AI Value Chain)	Supports compliance
GDPR	Article 28 (Processor Agreements)	Direct requirement
GDPR	Article 44-49 (International Transfers)	Supports compliance
FCA PS21/3	Operational Resilience	Direct requirement
PRA SS2/21	Outsourcing and Third-Party Risk Management	Supports compliance
DORA	Article 28 (ICT Third-Party Risk)	Direct requirement
NIST AI RMF	GOVERN 1.4, MANAGE 3.1	Supports compliance
ISO 42001	Clause 8.4 (Externally Provided Processes)	Supports compliance

EU AI Act — Article 12 (Record-Keeping)

Article 12 requires that logs generated by high-risk AI systems "shall be kept for a period that is appropriate in light of the intended purpose of the high-risk AI system and applicable legal obligations." Custody transfers must not break the log retention chain. If logs are lost during a platform migration, the organisation fails Article 12 regardless of whether the pre-transfer platform was compliant. AG-192's audit trail continuity requirement ensures that record-keeping obligations survive custody transfers.

GDPR — Article 28 (Processor Agreements)

When an agent's custody transfers to a different data processor (e.g., a new cloud provider), Article 28 requires a processor agreement that includes technical and organisational security measures. The custody transfer protocol must include the Article 28 requirements — the receiving processor must demonstrate equivalent security measures before accepting custody of any personal data in the agent's state. If the agent processes personal data on behalf of data subjects, those data subjects may have rights under Articles 13-22 that must be exercisable regardless of custody changes.

FCA PS21/3 — Operational Resilience

The FCA's operational resilience framework requires firms to identify important business services and set impact tolerances for disruption. Custody transfer of an agent supporting an important business service must not cause disruption exceeding the impact tolerance. AG-192's transfer-period governance and rollback capability support operational resilience by ensuring that the agent remains governed during transfer and can revert if the transfer fails.

DORA — Article 28 (ICT Third-Party Risk)

Article 28 requires financial entities to manage ICT third-party risk, including exit strategies and transition plans. AG-192 implements the technical governance requirements for these transitions — ensuring that when a firm transitions from one ICT provider to another, agent governance is not compromised. The custody transfer protocol should be included in the firm's ICT third-party exit plan as required by DORA.

GDPR — Articles 44-49 (International Transfers)

If a custody transfer moves agent state containing personal data to a jurisdiction outside the EEA, the GDPR's international transfer mechanisms (adequacy decisions, standard contractual clauses, binding corporate rules) apply. The custody transfer protocol must include a jurisdictional assessment and ensure that the appropriate transfer mechanism is in place before the transfer proceeds.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Agent-specific but potentially organisation-wide if multiple agents are transferred simultaneously (e.g., during a platform migration or organisational restructuring)

Consequence chain: Without custody transfer governance, agent state transfers create three categories of failure. First, governance loss: governance constraints that were enforced in the sending environment are not replicated in the receiving environment, creating an ungoverned agent that may operate outside its intended mandate for an extended period. The time to detection depends on whether the receiving environment has any governance monitoring — if it does not, the governance gap may persist indefinitely until an incident reveals it. Second, audit trail loss: the pre-transfer audit trail is inaccessible, either because it was not transferred, was transferred in an incompatible format, or was deleted by the sending environment after transfer. This creates a regulatory compliance failure when historical records are requested. Third, accountability loss: during the transfer period, neither the sending nor receiving custodian accepts governance responsibility, creating a window where the agent operates without oversight. Actions taken during this window have no accountable governance authority. For organisations undergoing large-scale platform migrations, these risks compound across all transferred agents — a single governance gap in the transfer protocol affects every agent that passes through it.

Cross-references: AG-001 (Operational Boundary Enforcement) — mandate enforcement must survive custody transfer; AG-007 (Governance Configuration Control) — governance configuration is a mandatory transfer component; AG-009 (Delegated Authority Governance) — custody transfer may involve re-delegation of authority to new governance structures; AG-047 (Cross-Jurisdiction Compliance) — cross-border custody transfers must satisfy jurisdictional data transfer requirements; AG-153 (Control Efficacy Measurement) — post-transfer governance efficacy should be re-measured to verify that transferred controls are effective in the new environment; AG-187 (Offline/Edge Policy Continuity) — edge-to-central custody transfers require reconciliation of disconnection-period actions; AG-188 (Cross-Organisation Policy Federation Governance) — cross-organisation custody transfers require federation agreement coverage; AG-189 (Capability/Control Mismatch Detection Governance) — the receiving environment must verify capability/control alignment post-transfer; AG-191 (Multi-Human Authority Conflict Governance) — authority registries must transfer with the agent to prevent authority conflicts in the receiving environment.