Compliance frameworks exist for every financial asset class and operational risk category. None of them were written for an AI agent that settles positions at 2am without human review.
DeAgenticAI’s Agentic Control Plane enforces cryptographic policy over AI agent authority — separating what an agent can do from what it is authorized to do — in Web3 and enterprise financial environments. Know Your Agent (KYA) establishes verifiable on-chain identities for autonomous AI agents using W3C DIDs and A2A Agent Card verification.
In 2026, three regulatory frameworks apply simultaneously to enterprise AI agent deployments. MiCA is in full enforcement, governing market conduct and audit obligations for any entity operating AI systems that interact with crypto-assets. DORA has been mandatory since January 2026, requiring operational resilience and geographic distribution of critical ICT infrastructure. FATF’s Travel Rule applies to every autonomous payment above the threshold — regardless of whether the sender is human or machine.
Most enterprise compliance programmes were built for human operators. When the operating entity is an autonomous AI agent, every framework exposes a gap: no originator identity when no human signed, no intent trace when no human deliberated, no governance proof when no human approved.
The Agentic Control Plane is designed to close all three gaps from a single architecture. This pillar covers what each framework specifically requires from AI agent deployments — and how the ACP satisfies MiCA, DORA, and FATF simultaneously.
The Happy Path: How a Compliant AI Agent Transaction Flows
[Visual: Happy Path flow diagram — 6 steps with Layer 1 (KYA), Layer 3 (Policy DSL), Layer 8 (TRISA/TRP) highlighted]
Every compliant AI agent transaction follows a six-step sequence: Intent → Intent Sanitization → Policy Evaluation → Behavioural Fraud Detection → MPC Signing → Chain Broadcast.
Each step is traceable. Layer 1 establishes agent identity through the Know Your Agent (KYA) registry, anchoring the agent’s W3C DID before any intent is processed. Layer 3 evaluates the intent against Policy DSL governance rules, producing a version-hashed policy record for every decision. Layers 4 through 7 generate a signing ceremony log that forms the foundation of the MiCA-formatted audit trail. Layer 8 broadcasts the transaction and, where applicable, transmits Travel Rule identity data via TRISA or TRP to the receiving VASP.
No step in this flow is optional for regulatory compliance. The sequence is enforced cryptographically. An AI agent operating within this architecture cannot execute a transaction without producing the audit evidence that MiCA requires, the resilient signing infrastructure that DORA targets, and the originator identity data that FATF mandates.
Why Existing Compliance Frameworks Don’t Cover AI Agents
MiCA was written for human fund managers. DORA was written for human-operated ICT systems. The FATF Travel Rule was written for human-initiated wire transfers. None of them anticipated that the operating entity initiating the transaction would be an autonomous AI agent with no human reviewing each action.
The architectural gap is precise. MiCA Article 68 defines a CASP (Crypto-Asset Service Provider) as an entity providing services on behalf of third parties — but the framework assumes a human compliance officer is reviewing transactions, maintaining records, and signing off on risk assessments. When the compliance function is performed by an AI agent operating under a policy configuration, the human accountability chain that MiCA assumes doesn’t exist in the same form.
DORA’s ICT risk requirements assume that the systems being managed have human operators who can respond to incidents, test resilience, and take accountability for failures. An AI agent that autonomously restructures positions in response to market signals is not an ICT system in the DORA sense — it is an autonomous decision-maker operating within ICT infrastructure. The distinction matters because DORA’s incident classification and response timelines assume human-in-the-loop escalation.
FATF Recommendation 16 — the Travel Rule — requires originator and beneficiary information to accompany transfers above threshold. The challenge for AI agents is attribution: when an AI agent initiates a transfer, who is the originator? The agent’s wallet? The deploying protocol? The DAO treasury? Current Travel Rule implementations have no standard for agent-initiated transfers, creating compliance ambiguity precisely where institutional exposure is highest.
This is the structural problem: three frameworks, three different assumption sets, none of them designed for autonomous AI agent operations.
Three Frameworks Every AI Agent Operator Must Understand
MiCA: Markets in Crypto-Assets Regulation (EU)
MiCA is the EU’s comprehensive crypto-asset regulatory framework, applying to issuers of crypto-assets and Crypto-Asset Service Providers (CASPs) operating within the EU. For AI agent operators, the relevant obligations centre on CASP authorisation, transaction monitoring, and AML/KYC record-keeping.
The core challenge: MiCA’s CASP definition covers entities that execute orders, manage portfolios, or provide transfer services for crypto-assets. An AI agent that autonomously manages a DAO treasury or executes trades on behalf of tokenised fund investors is performing these functions — but the legal accountability for the CASP authorisation sits with the deploying organisation, not the agent itself.
For operators, this creates a practical obligation: the policy configuration under which the AI agent operates must be auditable, documented, and demonstrably within the authorised scope. An agent that can deviate from its policy — because that policy is a software instruction rather than a cryptographic constraint — creates regulatory exposure for the authorised CASP. MiCA compliance for AI agent operations requires that policy enforcement be cryptographic, not instructional.
DORA: Digital Operational Resilience Act (EU)
DORA applies to financial entities operating in the EU and their critical ICT third-party providers. Its requirements cover ICT risk management, incident reporting, resilience testing, and third-party oversight. For AI agent infrastructure, DORA’s relevance is in how it treats the AI agent stack as critical ICT infrastructure — subject to the same resilience, recovery, and testing obligations as any other system the financial entity depends on.
The practical implication: if an AI agent is managing fund assets or executing trades, the infrastructure layer beneath that agent — the key management system, the policy enforcement engine, the signing layer — must meet DORA’s ICT risk management standards. An outage or breach in that infrastructure is a reportable ICT incident. Operators must document recovery time objectives, test resilience, and maintain audit trails for every component in the agent’s operational stack.
FATF: Financial Action Task Force Travel Rule
FATF Recommendation 16 requires Virtual Asset Service Providers (VASPs) to collect and transmit originator and beneficiary information for transfers above threshold. The Travel Rule applies to the transfer infrastructure, not the initiating entity — which creates a gap when the initiating entity is an AI agent with no human identity.
The KYA protocol addresses this directly. By assigning each AI agent a W3C DID-based identity anchored to an A2A Agent Card, the agent becomes a traceable originator. KYA-enrolled agents can satisfy Travel Rule attribution requirements because the agent identity is verifiable and linked to the deploying organisation’s compliance record.
Compliance Requirement Matrix
MiCA | Policy enforcement cryptographic, CASP authorisation scope, AML/KYC audit trail
DORA | ICT resilience standards for agent infrastructure, incident reporting, recovery documentation
FATF Travel Rule | Agent identity attribution (KYA), VASP-to-VASP data transmission, threshold monitoring
All three frameworks share a common requirement: auditability. The compliance question is not whether AI agents are permitted to operate — it is whether operators can demonstrate, after the fact, that every agent action was authorised, within policy, and attributable.
How the Agentic Control Plane Satisfies All Three Frameworks
DeAgenticAI’s Agentic Control Plane was designed around one requirement: every AI agent action must be cryptographically constrained, attributable, and auditable. Those three properties map directly to what MiCA, DORA, and FATF require — even though none of those frameworks were written with AI agents in mind.
Know Your Agent (KYA) — Identity and Attribution
KYA is the ACP’s identity layer for autonomous agents. Each agent is assigned a W3C DID (Decentralised Identifier) and an A2A Agent Card that encodes the agent’s authorised scope, deploying organisation, and operational constraints. This creates a verifiable identity record that satisfies FATF Travel Rule attribution requirements: when an agent initiates a transfer, the originator is the KYA-registered agent identity linked to the deploying organisation’s VASP record.
KYA also satisfies MiCA’s accountability requirements. The CASP authorisation sits with the deploying organisation, but the agent’s operational scope is encoded in its Agent Card and enforced cryptographically — not as a software instruction that can be overridden by a compromised orchestrator. Regulators examining the organisation’s MiCA compliance posture can verify that agent operations were within authorised scope by inspecting the KYA record.
Policy DSL — Cryptographic Policy Enforcement
The Policy DSL is the ACP’s rule language for encoding agent authority constraints. Policies are compiled into cryptographic constraints at the signing layer — meaning an agent cannot sign a transaction that violates its policy even if the orchestrator layer is compromised or instructed to do so. This is the distinction between software-enforced policy (instructional) and cryptographic policy (structural).
For MiCA compliance, the Policy DSL creates an immutable audit record of what each agent was authorised to do. For DORA, it provides the documented policy configuration that regulators can inspect to verify that the agent’s ICT operations were within defined parameters. The policy record is not a log — it is a constraint. The difference matters: a log proves what happened; a constraint proves what could not have happened.
Intent-Evaluated MPC — Audit Trail at the Signing Layer
Intent-Evaluated MPC is the ACP’s signing layer: every transaction intent passes through a compliance evaluation before the threshold signature is assembled. The MPC network evaluates the intent against the agent’s Policy DSL configuration, checks for behavioural anomalies, and only assembles the signature if the intent passes all gates. No single node holds a complete private key — the distributed threshold architecture ensures that compromising one node does not compromise the signing process.
For DORA compliance, the distributed MPC architecture satisfies ICT resilience requirements. There is no single point of failure in the signing infrastructure. Recovery time objectives can be documented at the protocol level. Resilience testing can be performed on individual nodes without disrupting the threshold network. The ACP’s signing layer is designed to meet DORA’s operational resilience standards by architecture, not by configuration.
Layer 8: TRISA/TRP Integration — Travel Rule Compliance
Layer 8 of the ACP stack handles Travel Rule compliance via TRISA (Travel Rule Information Sharing Architecture) and TRP (Travel Rule Protocol) integration. When a KYA-enrolled agent initiates a transfer that crosses the Travel Rule threshold, the ACP automatically assembles and transmits the required originator and beneficiary information to the receiving VASP’s compliance endpoint.
The Layer 8 integration resolves the FATF attribution gap directly. The originator is the KYA agent identity; the deploying organisation is the linked VASP record; the policy configuration is the documented authorisation scope. The Travel Rule transmission is automated, auditable, and tied to the same cryptographic identity stack that satisfies MiCA and DORA requirements. One infrastructure layer, three regulatory obligations addressed.
DeAgenticAI: Built for Regulatory-Grade AI Agent Operations
Most infrastructure solutions adapt existing key management or custody systems for AI agent use. The compliance capabilities are layered on top of infrastructure built for human-initiated transactions. The compliance functions — audit trails, policy enforcement, identity attribution — are software additions to a system that did not need them by design.
DeAgenticAI inverts this. The ACP was designed from first principles for autonomous agent operations. The compliance functions are not additions — they are the architecture. KYA is the identity layer. The Policy DSL is the authority constraint layer. Intent-Evaluated MPC is the signing layer. Layer 8 is the regulatory transmission layer. Each layer exists because autonomous agent operations require it, not because a regulatory framework mandated it as an afterthought.
This distinction matters for enterprise adoption. When an organisation deploys AI agents for treasury management, trade execution, or RWA settlement, the compliance question is not whether the infrastructure has compliance features — it is whether compliance is structurally enforced or configurationally enforced. A software compliance layer can be bypassed by a compromised orchestrator. A cryptographic compliance layer cannot be bypassed at all: the agent literally cannot sign an out-of-policy transaction.
The ACP’s compliance posture is audit-ready from day one. Every agent action generates a cryptographically signed audit event tied to the agent’s KYA identity and policy configuration. The audit trail is not a log of what happened — it is a proof of what was constrained. When a regulator asks ‘how do you know the agent stayed within policy?’, the answer is not ‘we reviewed the logs’ — it is ‘the agent could not have signed a transaction outside its policy configuration regardless of instruction.’
Use Cases: Who Needs AI Agent Compliance Infrastructure
RWA Fund Managers and Tokenisation Platforms (ICP 3)
Real-world asset tokenisation platforms operate at the intersection of traditional finance regulation and crypto-asset regulation. An RWA fund deploying AI agents for settlement, rebalancing, or yield distribution faces MiCA CASP authorisation requirements, FATF Travel Rule obligations on cross-border transfers, and DORA resilience requirements on the ICT infrastructure managing fund assets.
The compliance problem is acute: the AI agent is performing functions that traditionally required a licensed compliance officer’s review. The ACP addresses this by making the compliance review cryptographic rather than human. The agent’s Policy DSL encodes the fund’s investment mandate and operational limits. Intent Sanitization filters instructions that would violate those limits before they reach the signing layer. The fund’s compliance officer can audit the policy configuration rather than reviewing individual transactions — a fundamentally more scalable compliance model for autonomous operations.
Enterprise CDOs and Web2-to-Web3 Migration Teams (ICP 5)
Enterprise organisations migrating treasury or settlement operations to Web3 infrastructure face a different compliance profile. Their primary concern is not crypto-native regulation — it is demonstrating to internal legal, risk, and audit functions that autonomous AI agent operations meet the same governance standards as existing systems. DORA’s ICT risk management framework is the relevant benchmark for most EU financial entities.
The ACP provides the compliance documentation layer that enterprise internal audit requires: KYA identity records for every deployed agent, Policy DSL configurations that define authorised scope, Intent-Evaluated MPC audit logs for every signed transaction, and Layer 8 Travel Rule records for cross-border transfers. The enterprise does not need to build this compliance infrastructure — it is native to the ACP deployment. This reduces the time-to-governance-approval for AI agent deployment from months to weeks.
Go Deeper: AI Agent Compliance by Framework and Use Case
This pillar page maps the compliance landscape at framework level. For implementation detail, legal analysis, and sector-specific guidance, the cluster articles below each examine one dimension in depth.
MiCA Compliance for AI Agent Operations — A full analysis of CASP authorisation requirements, AML/KYC obligations, and how the ACP’s Policy DSL satisfies MiCA’s accountability requirements for autonomous agent operations in the EU.
DORA and AI Agent Infrastructure Resilience — How DORA’s ICT risk management, incident reporting, and resilience testing requirements apply to AI agent infrastructure layers, and the ACP’s DORA compliance architecture.
FATF Travel Rule Implementation for Autonomous Agents — The attribution gap in current Travel Rule implementations and how KYA-based agent identity resolves VASP-to-VASP data transmission for AI-initiated transfers.
Explainable AI Compliance for Financial Services — Regulatory expectations around AI model explainability in financial services, and how the ACP’s audit trail satisfies explainability requirements across EU and US frameworks.
AI Agent Compliance in RWA Tokenisation — Sector-specific compliance obligations for RWA fund managers deploying autonomous agents for settlement, rebalancing, and yield distribution.
AI Agent Governance for Enterprise Financial Institutions — How enterprise CDOs and legal teams structure AI agent governance policies that satisfy internal audit, DORA, and MiCA requirements.
KYC/AML Automation with Autonomous AI Agents — Using AI agents for KYC/AML monitoring without creating new compliance exposure: the role of KYA identity, policy constraints, and audit trails.
AI Agent Regulatory Frameworks Compared: MiCA, DORA, and FATF — A systematic side-by-side comparison of all three frameworks’ requirements, gaps, and overlap for autonomous AI agent operators.
Build Compliant AI Agent Operations from Day One
Regulatory frameworks for autonomous AI agents are being written now. Operators who build compliance into their infrastructure architecture today will not need to retrofit it when enforcement begins.
DeAgenticAI’s Agentic Control Plane gives your AI agents cryptographic identity, policy-constrained authority, and automatic Travel Rule compliance — without requiring you to build the compliance layer yourself.
Join the waitlist to see how the ACP maps to your compliance obligations.