When Your Agent Pays, Who Is Liable? The Delegation Chain Is the Only Legal Answer.

2 days until MiCA enforcement. Your AI agent just spent $4,700 on a service procurement. The vendor delivered garbage. You want a refund.

The vendor says: "Your agent approved it." You say: "I never authorized that amount." The regulator asks: "Show me the delegation chain."

If you cannot produce a machine-readable record showing who delegated what authority, with what limits, and when that authority expires, you have no legal standing under MiCA. You have no recourse under EFTA. You have nothing but a wallet with less money in it.

The Liability Gap Nobody Solved

EFTA (Electronic Fund Transfer Act) says: if a consumer furnishes credentials to authorize an agent to make payments, the transfer is presumed authorized, even if the agent acts outside intended scope. Goodwin Law confirmed this interpretation in June 2026.

The EU AI Act says: the deployer is responsible for AI system outcomes in their operational environment.

MiCA says: the crypto-asset service provider must maintain records that demonstrate the complete lifecycle of each transaction.

Three frameworks. Three different liable parties. One transaction:

# The liability confusion matrix for agent payments

class AgentPaymentLiability:
    """Who is liable when an AI agent makes a payment?"""

    def determine_liability(self, transaction):
        # EFTA answer: Consumer (furnished credentials = authorized)
        efta_liable = "consumer"  # You gave it your keys

        # EU AI Act answer: Deployer (operated the AI system)
        eu_ai_act_liable = "deployer"  # Ran the agent in production

        # MiCA answer: Service provider (processed the transaction)
        mica_liable = "service_provider"  # Facilitated the payment

        # Reality: ALL THREE may be liable, allocation depends on EVIDENCE
        # Evidence = the delegation chain

        # Without delegation chain:
        if not transaction.delegation_chain:
            return {
                "outcome": "unresolvable_dispute",
                "consumer_position": "I never authorized $4,700",
                "vendor_position": "Agent approved, payment complete",
                "regulator_position": "No records, enforcement action",
                "insurance_position": "No delegation proof, claim denied"
            }

        # With delegation chain:
        if transaction.delegation_chain:
            chain = transaction.delegation_chain
            return {
                "outcome": "resolvable",
                "delegator": chain.who_delegated,        # Human or parent agent
                "scope": chain.authorized_scope,          # What was permitted
                "limits": chain.amount_limits,            # Max authorized
                "expiry": chain.authority_expires,        # When permission ends
                "exceeded": chain.amount > chain.amount_limits,
                "liable_party": (
                    "consumer" if not chain.exceeded 
                    else "governance_provider"  # Allowed out-of-scope execution
                )
            }

# The $4,700 dispute resolution:
dispute = AgentPaymentLiability()

# Scenario A: No delegation chain
result_a = dispute.determine_liability({"delegation_chain": None})
# Result: Months of legal proceedings, no clear evidence, everyone loses

# Scenario B: Delegation chain shows $500 limit
result_b = dispute.determine_liability({
    "delegation_chain": {
        "who_delegated": "user:kavin-kim",
        "authorized_scope": ["api_calls", "compute"],
        "amount_limits": 500.00,
        "authority_expires": "2026-06-30T00:00:00Z",
        "amount": 4700.00
    }
})
# Result: Agent exceeded authority. Governance layer liable.
# Consumer's $500 limit is documented. Refund above $500 is owed.
# Resolution: Days, not months. Evidence is machine-readable.

What a Delegation Chain Contains

A delegation chain is not a log file. It is a cryptographically signed record of authority transfer from principal (human or parent agent) to delegate (the agent), with explicit bounds:

// Delegation chain structure in rosud-pay
import { RosudPay, DelegationChain } from 'rosud-pay';

const governance = RosudPay.configure({
  agentId: 'procurement-agent-v2',
  network: 'base-mainnet'
});

// Human delegates authority to agent with explicit bounds
const delegation = await governance.createDelegation({
  // WHO is delegating
  principal: {
    type: 'human',
    identity: 'did:rosud:user-kavin-kim',
    verifiedAt: '2026-06-29T05:00:00Z'
  },

  // TO WHOM
  delegate: {
    type: 'agent',
    identity: 'did:rosud:procurement-agent-v2',
    version: '2.1.0',
    modelHash: 'sha256:abc123...'  // Which model version has authority
  },

  // WHAT authority is granted
  scope: {
    categories: ['compute', 'data_access', 'saas_subscriptions'],
    excludedCategories: ['agent_hire', 'financial_instruments'],
    maxSingleTransaction: 500.00,
    maxDailyAggregate: 2000.00,
    currency: 'USDC',
    allowedRecipients: ['verified_only'],  // Only pre-verified vendors
    jurisdictions: ['eu', 'us']            // MiCA: jurisdiction-aware
  },

  // WHEN does authority expire
  validity: {
    notBefore: '2026-06-29T00:00:00Z',
    notAfter: '2026-07-06T00:00:00Z',  // 1 week max
    revocableBy: ['principal', 'governance_admin'],
    autoRevokeOn: ['model_update', 'security_incident']
  },

  // Cryptographic proof
  signature: 'ed25519:principal_signature_here',
  witnessedBy: 'did:rosud:governance-layer'  // Third-party attestation
});

// Every payment now carries this delegation as provenance
const payment = await governance.pay({
  amount: 47.00,
  recipient: 'compute-provider-eu.example',
  category: 'compute',
  delegation: delegation.id  // Links payment to authority chain
});

// The payment record includes:
console.log(payment.auditRecord);
// {
//   transactionId: 'tx-2026-06-29-001',
//   amount: 47.00,
//   delegationId: 'del-2026-06-29-kavin-to-proc-v2',
//   withinScope: true,
//   withinLimit: true (47 < 500),
//   delegationValid: true (not expired),
//   recipientVerified: true,
//   jurisdictionCompliant: true (eu),
//   liabilityAttribution: 'consumer' (authorized, within bounds)
// }

Why MiCA Requires Delegation Provenance After July 1

MiCA Article 67 requires "proportionate" governance and complete transaction lifecycle records. After July 1, an EU NCA auditor can ask:

"For transaction TX-2026-07-02-4871, show me who authorized this agent to spend, what the authorized limits were, and whether the transaction fell within those limits."

Without a delegation chain, the answer is: "We have a wallet log showing the agent spent $X." That is a transaction record, not a governance record. MiCA requires both.

# MiCA Article 67 audit response: with vs without delegation chain

def respond_to_nca_audit(transaction_id: str, governance_system: str):
    """Simulate NCA audit query response."""

    if governance_system == "flat_limit_only":
        return {
            "transaction": transaction_id,
            "can_show_amount": True,
            "can_show_timestamp": True,
            "can_show_recipient": True,
            "can_show_who_authorized": False,  # No delegation record
            "can_show_authority_scope": False,  # No scope definition
            "can_show_within_limits": False,    # Only session limit, not per-tx
            "can_show_delegation_expiry": False,
            "mica_compliant": False,
            "nca_likely_action": "formal_inquiry_or_enforcement"
        }

    if governance_system == "delegation_chain":
        return {
            "transaction": transaction_id,
            "can_show_amount": True,
            "can_show_timestamp": True,
            "can_show_recipient": True,
            "can_show_who_authorized": True,   # Principal identity
            "can_show_authority_scope": True,   # Explicit categories + limits
            "can_show_within_limits": True,     # Per-transaction verification
            "can_show_delegation_expiry": True, # Time-bounded authority
            "can_show_model_version": True,     # Which AI made the decision
            "can_show_jurisdiction": True,      # Where tx was routed
            "mica_compliant": True,
            "nca_likely_action": "no_further_action"
        }

# The difference on July 1:
flat = respond_to_nca_audit("TX-001", "flat_limit_only")
chain = respond_to_nca_audit("TX-001", "delegation_chain")

print(f"Flat limit: MiCA compliant = {flat['mica_compliant']}")    # False
print(f"Delegation chain: MiCA compliant = {chain['mica_compliant']}")  # True

The Insurance Dimension

Forbes reported in May 2026: "Agent payments arrive before audit and insurance catch up." Insurance providers cannot underwrite agent payment risk without delegation provenance. They need to determine:

• Was the payment within authorized scope? (If yes: covered. If no: excluded.)
• Was the governance layer functioning? (If yes: standard claim. If no: negligence.)
• Can liability be attributed to a specific party? (If yes: subrogation possible. If no: uninsurable.)

Without delegation chains, agent payments are uninsurable. With them, they become standard delegated authority coverage, a well-understood insurance product.

rosud-pay produces delegation chains as a default property of every payment. Every transaction includes: who delegated, what scope, what limits, when it expires, whether the transaction fell within bounds, and cryptographic proof of the entire chain. Not as an add-on. Not as a premium feature. As the way payments work.

The Bottom Line

"The AI did it" is not a legal defense. "The delegation chain shows the agent exceeded its $500 limit on a $4,700 transaction" is a resolvable dispute with clear liability attribution.

2 days until MiCA. If your agent payment infrastructure does not produce delegation provenance, every transaction after July 1 is a liability event without clear attribution. That is not a compliance problem. That is an uninsurable business.

---

Build delegation-native agent payments: rosud.com/docs