{
 "slug": "skyfire-catena-labs-agent-payment-stacks-cannot-own",
 "topic_id": "TOPIC-101",
 "cluster": "Competitive Deconstruction",
 "tier": "Tier B",
 "title": "An agent payment rail cannot also be the accountability layer",
 "summary": "Platforms built to let agents transact without human involvement are solving a real problem. The thing they remove by design is the thing accountability requires.",
 "lede": "The selling point is autonomous checkout without human friction. That is a genuine capability with genuine demand, and it is structurally the opposite of what proving human authority needs.",
 "date": "2024-03-15",
 "category": "Comparison",
 "author_id": "nadia-ferreira-strand",
 "tags": [
  "agent payments",
  "accountability",
  "partnership",
  "autonomy",
  "delegation",
  "comparison"
 ],
 "image_title": "Agent Rail Cannot Own Accountability",
 "schema": "Article",
 "key_takeaways": [
  "Agent payment platforms optimise for removing human involvement per transaction, which is what makes them useful.",
  "Human accountability requires a record of what a human authorised, which the autonomy objective actively removes.",
  "These are layers rather than competitors: the rail moves value, the accountability layer establishes who stood behind it."
 ],
 "body": [
  {
   "type": "h2",
   "text": "What the rail is for"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "The accountability layer sits above the rail and is verified by parties on both sides",
   "caption": "Two layers, neither of which needs to know much about the other.",
   "nodes": [
    {
     "label": "Human signs a delegation",
     "note": "scope, ceiling, expiry",
     "good": true
    },
    {
     "label": "Agent transacts on the rail",
     "note": "settlement, pricing, identity"
    },
    {
     "label": "Transaction references the delegation",
     "note": "one field"
    },
    {
     "label": "Counterparty verifies the chain offline",
     "note": "before performing",
     "good": true
    }
   ]
  },
  {
   "type": "p",
   "html": "Agent payment infrastructure solves problems that existing rails handle badly: identifying agents, settling small amounts, machine-readable pricing, programmatic access to services."
  },
  {
   "type": "p",
   "html": "Each of those is real. Existing payment infrastructure assumes a person at a checkout, and an agent buying API access a thousand times a day does not fit."
  },
  {
   "type": "h2",
   "text": "The objective that creates the gap"
  },
  {
   "type": "table",
   "head": [
    "Design goal",
    "Consequence"
   ],
   "rows": [
    [
     "Transactions without human intervention",
     "No human authorisation record per transaction"
    ],
    [
     "Low friction at scale",
     "Approval steps are removed deliberately"
    ],
    [
     "Agent-native identity",
     "Identity is the agent's, not a person's"
    ],
    [
     "Programmatic spending limits",
     "Bounds set in configuration, not signed by a person"
    ]
   ]
  },
  {
   "type": "p",
   "html": "Read the right column as a description rather than an accusation. These are the correct consequences of the stated goals, and a platform that added a human approval per transaction would have failed at its own purpose."
  },
  {
   "type": "h2",
   "text": "The question that arrives later"
  },
  {
   "type": "p",
   "html": "When an agent transaction is disputed, the questions are ones the rail cannot answer."
  },
  {
   "type": "ul",
   "items": [
    "Which human authorised this agent to spend on this organisation's behalf?",
    "What scope did they authorise — amount, counterparties, duration?",
    "Can that authorisation be verified by the counterparty, the bank, or a court?",
    "Was it still in force at the time of the transaction?"
   ]
  },
  {
   "type": "p",
   "html": "A configuration record showing a spending limit is an internal setting. It is not a record of a human commitment, and in a dispute it is an assertion by the party relying on it."
  },
  {
   "type": "h2",
   "text": "Why the rail should not build it"
  },
  {
   "type": "p",
   "html": "Three structural reasons, and the third is the strongest."
  },
  {
   "type": "ol",
   "items": [
    "<strong style=\"font-weight:600\">Objective conflict.</strong> Adding human authorisation friction works against the product's core claim.",
    "<strong style=\"font-weight:600\">Scope.</strong> The accountability layer spans every consequential agent action, not only payments. A payment rail has no view of the permission grant or the data export.",
    "<strong style=\"font-weight:600\">Neutrality.</strong> A record of what a human authorised is most useful when the party relying on it is not the party that issued it. Evidence produced by one side of a transaction is worth less than evidence either side can verify independently."
   ]
  },
  {
   "type": "h2",
   "text": "How the layers compose"
  },
  {
   "type": "code",
   "text": "# Accountability layer  — neutral, verifiable by anyone\n  human signs a delegation:\n    agent X may spend up to N, with counterparties C,\n    until date D, revocable immediately\n\n# Rail  — moves value, handles settlement\n  agent transacts under that delegation\n  each transaction references the delegation\n\n# Counterparty, bank, auditor\n  verify the delegation chain offline\n  a transaction outside the scope produces no valid chain"
  },
  {
   "type": "p",
   "html": "Neither layer needs to know much about the other. The rail carries a reference; the accountability layer does not care which rail was used."
  },
  {
   "type": "h2",
   "text": "Why this is a partnership rather than a competition"
  },
  {
   "type": "table",
   "head": [
    "Need",
    "Rail",
    "Accountability layer"
   ],
   "rows": [
    [
     "Agent identity",
     "Yes",
     "Uses it"
    ],
    [
     "Settlement",
     "Yes",
     "No"
    ],
    [
     "Machine-readable pricing",
     "Yes",
     "No"
    ],
    [
     "Human delegation record",
     "No",
     "Yes"
    ],
    [
     "Offline verification by third parties",
     "No",
     "Yes"
    ],
    [
     "Coverage of non-payment actions",
     "No",
     "Yes"
    ]
   ]
  },
  {
   "type": "p",
   "html": "There is no row where both are required and neither has it. That is the definition of complementary rather than competing."
  },
  {
   "type": "h2",
   "text": "The commercial argument for the rail"
  },
  {
   "type": "p",
   "html": "A rail whose transactions carry verifiable human delegation is a rail that merchants and banks will accept. One whose transactions arrive as unattributable automation is one they will price as fraud risk."
  },
  {
   "type": "p",
   "html": "That is the practical reason for a payment platform to want this layer to exist without building it: acceptance is the constraint on agent commerce, and acceptance follows evidence."
  },
  {
   "type": "h2",
   "text": "Why the rail should not build it"
  },
  {
   "type": "p",
   "html": "Three structural reasons, and the third is the strongest."
  },
  {
   "type": "table",
   "caption": "Structural obstacles",
   "head": [
    "Reason",
    "Detail"
   ],
   "rows": [
    [
     "Objective conflict",
     "Adding human authorisation friction works against the product's core claim"
    ],
    [
     "Scope",
     "Accountability spans every consequential agent action; a payment rail has no view of a permission grant or a data export"
    ],
    [
     "<strong style=\"font-weight:600\">Neutrality</strong>",
     "Evidence produced by one side of a transaction is worth less than evidence either side can verify independently"
    ]
   ]
  },
  {
   "type": "p",
   "html": "There is a commercial argument for the rail wanting this to exist without building it. Acceptance is the constraint on agent commerce: a rail whose transactions carry verifiable human delegation is one that merchants and banks will accept, and one whose transactions arrive as unattributable automation gets priced as fraud risk."
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“A configured spending limit is the same thing.”</strong> It is an internal setting. In a dispute it is an assertion by the party relying on it, not a record of a human commitment a third party can check."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“This is a competitive pitch.”</strong> There is no row in the comparison where both parties are required and neither has it. That is the definition of complementary rather than competing."
  }
 ],
 "faq": [
  {
   "q": "Are agent payment platforms doing something wrong?",
   "a": "No. They solve real problems that existing rails handle badly. Removing human involvement per transaction is their purpose, not an oversight."
  },
  {
   "q": "Why can't the rail add human authorisation?",
   "a": "It conflicts with their core claim, it covers only payments rather than all consequential actions, and evidence is worth more when the issuer is not a party to the transaction."
  },
  {
   "q": "Isn't a configured spending limit enough?",
   "a": "It is an internal setting. In a dispute it is an assertion by the party relying on it, not a record of a human commitment a third party can verify."
  },
  {
   "q": "Why would a rail want this to exist?",
   "a": "Acceptance. Merchants and banks will accept transactions carrying verifiable human delegation and price unattributable automation as fraud risk."
  },
  {
   "q": "Why does neutrality matter?",
   "a": "A record is most useful to the party who did not issue it. Evidence produced by one side of a transaction carries less weight than evidence either side can verify."
  },
  {
   "q": "Why would a rail want this?",
   "a": "Acceptance. Merchants and banks will take transactions carrying verifiable human delegation and will price unattributable automation as fraud risk."
  }
 ],
 "sources": [
  {
   "t": "FTC — business guidance on marketplaces and consumer protection",
   "u": "https://www.ftc.gov/business-guidance"
  },
  {
   "t": "Visa — security and trust perspectives on agentic commerce",
   "u": "https://corporate.visa.com/en/sites/visa-perspectives/security-trust.html"
  },
  {
   "t": "Restatement (Third) of Agency — overview (Cornell LII, Agency)",
   "u": "https://www.law.cornell.edu/wex/agency"
  },
  {
   "t": "CISA — known exploited vulnerabilities and incident reporting",
   "u": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
  }
 ],
 "related": [
  {
   "slug": "my-agent-did-defense-businesses-will-dispute",
   "title": "The 'my agent did it' defence",
   "category": "Future of Work"
  },
  {
   "slug": "bankers-guide-agentic-commerce-happens-ai-bots",
   "title": "A banker's guide to agents holding credentials",
   "category": "Future of Work"
  },
  {
   "slug": "fido-alliance-agentic-authentication-inside-race-standardize-verifiabl",
   "title": "Standardising verifiable user instructions",
   "category": "Future of Work"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Agent%20Rail%20Cannot%20Own%20Accountability/1200_630/blog.jpg",
 "wordcount": 945,
 "url": "/blog/skyfire-catena-labs-agent-payment-stacks-cannot-own.html",
 "reading_time": "4 min read",
 "meta_description": "Platforms that let agents transact without human involvement solve a real problem. What they remove by design is what accountability needs.",
 "hub": {
  "slug": "topics/category-comparisons",
  "title": "Category comparisons"
 },
 "answer": "Because its design goal is transacting without human involvement, which is exactly what removes the record accountability needs. Platforms such as Skyfire and Catena Labs solve agent identity, settlement and machine-readable pricing well. A delegation record is most useful when the party relying on it did not issue it.",
 "answer_q": "Why can't an agent payment rail own the human accountability layer?",
 "entities": [
  {
   "name": "Skyfire",
   "type": "Organization",
   "url": "https://skyfire.xyz/",
   "primary": true
  },
  {
   "name": "Catena Labs",
   "type": "Organization",
   "url": "https://catenalabs.com/"
  }
 ],
 "glossary": [
  {
   "term": "Agent payment rail",
   "def": "Infrastructure for identifying agents, settling small amounts and exposing machine-readable pricing — problems existing card rails handle badly."
  },
  {
   "term": "Delegation chain",
   "def": "A record connecting an agent's action to the human who authorised that class of action, with scope and expiry, verifiable by a third party."
  },
  {
   "term": "Acceptance",
   "def": "Whether merchants and banks will take a transaction. The real constraint on agent commerce, and it follows evidence."
  }
 ],
 "checklist": {
  "title": "What the delegation record must contain",
  "id": "fields",
  "desc": "Five fields that turn a dispute into arithmetic.",
  "steps": [
   {
    "name": "The principal.",
    "text": "A named human, authenticated with user verification, not an account."
   },
   {
    "name": "The scope.",
    "text": "Action class, counterparties, per-transaction and aggregate ceilings."
   },
   {
    "name": "The expiry.",
    "text": "So a stale delegation does not persist indefinitely."
   },
   {
    "name": "Revocation that is enforced.",
    "text": "At the point of effect, not at a gateway."
   },
   {
    "name": "Offline verifiability.",
    "text": "So the counterparty, the bank and a court can all check it without calling anyone."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav issues the delegation and the receipt; the rail moves the value. The chain verifies offline against a published key, so a merchant, a bank or a court can check it without an account with either party.",
  "href": "../docs.html",
  "label": "See delegation chains"
 }
}