Lubna Alli

The agentic economy now has a naming system, a testing regime and a payment rail in progress. What it doesn’t have yet is an answer to the oldest question in identity: who is actually on the other side, and who answers for them?

I spent the last year building identity verification for small businesses. The most useful thing that work taught me is that verification is never one question. Verifying a document is not verifying a person. Verifying a person is not verifying their authority to act. And verifying authority is worthless if no one has agreed who is liable when it’s misused. Every fraud pattern I saw lived in the gap between those layers.

AI agents are about to stress-test every one of those gaps at once. Gartner predicts that at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028, and that over 40% of agentic AI projects will be cancelled by the end of 2027, with inadequate risk controls among the reasons. Trust is not a side issue for agents. It decides which ones survive.

Three trust layers are being built in parallel

Over the past year, three different parts of the industry shipped answers to three different trust questions.

• Agent identity. The Linux Foundation’s Agent Name Service extends DNS so operators can check who an agent represents, what permissions it holds, and whether its code has been tampered with. It supports decentralized identifiers and Legal Entity Identifiers, which matters more than the headline suggests.
• System conformity. The Linux Foundation’s Appia Foundation, with Mastercard, Google, Microsoft and OpenAI among its members, turns standards like ISO/IEC into reusable conformity assessments. Its key design choice is evidence pass-through: an assessment done once upstream can travel down the value chain instead of being repeated by every buyer.
• Payment authorization. Payment networks have gone furthest here. Mastercard’s Agent Pay framework registers and verifies AI agents before they can transact using agentic tokens, and carries purchase intent data so issuers and merchants can see what the consumer actually asked for.

Each of these is genuinely useful. None of them, on its own, answers the question a counterparty actually needs answered before trusting an agent: whose agent is this, what has it been allowed to do, and who pays if it gets it wrong?

How the pieces compare

Initiative	The question it answers	What it can’t tell you
Agent Name Service Linux Foundation	Is this agent who it claims to be?	Whether this action falls within authority its principal actually granted
Appia Foundation Linux Foundation	Does this AI system meet the standard it claims?	Who agreed to carry the risk when the standard turns out to be wrong
Agent Pay Mastercard	Did a real customer authorize this payment?	How to bind agents outside the payment rail, where no liability rulebook exists yet
Building Inter-party Trust in AI All Tech Is Human with Mastercard	How can one business trust another business’s AI system?	Who stands behind an agent, and what it has been authorized to do
This piece	Whose agent is this, what may it do, and who answers for it?	Proposes adding the principal to the trust interface

The principal problem

In identity verification, the hard part is rarely the credential. It’s the binding: proving that this credential belongs to this accountable party, who has delegated this specific authority, for this period, and can revoke it.

The best recent work on AI trust is circling the same problem from the procurement side. Building Inter-party Trust in AI, the white paper All Tech Is Human produced with Mastercard from a workshop of dozens of organizations, starts from a blunt observation: businesses are being asked to rely on AI systems they did not build and cannot fully inspect. It frames trust as an interface problem, about how evidence moves between parties, and sets the goal of making risk “legible, attributable, and manageable” across organizational boundaries.

Attributable is the word that matters for agents. They make attribution harder in three ways.

1. Agents multiply. A single business may run dozens of agents, built on models it didn’t train, orchestrated by vendors it procured, acting on data from partners it has never audited. The white paper notes that agentic systems don’t so much introduce a new category of risk as make the supply chain harder to see. That is exactly the shape of a delegation chain.

2. Authority drifts. The paper lists expanded permissions among the changes that make a one-time disclosure go stale. For agents, permissions aren’t an edge case of change; they are the main thing that changes. A human employee with a corporate card has a job title, a manager and a spending policy. An agent has whatever scope it was given at setup, usually once, by a developer, through an API key. Meanwhile, consumers are moving faster than the plumbing: a Mastercard survey found that a third of consumers would already trust an AI agent to spend up to $1,000 without prior approval.

That is not a delegation model. It’s a skeleton key.

3. Liability is unassigned. The paper is candid that today’s AI supply chain runs on contracts, liability transfer and incomplete disclosure rather than shared understanding. Its healthcare example shows why that’s corrosive: when accountability falls on the deploying institution rather than the business that built the tool, upstream actors have weaker incentives to provide the evidence safe use depends on. Conformity testing can tell you a system behaves as specified. It cannot tell you who agreed to carry the risk when the specification turns out to be wrong.

Two fields the trust interface is missing

The white paper’s most practical contribution is a minimum viable trust interface: a structured intake where buyer and vendor agree up front on the system and its use, its risk profile, the evidence needed, how sensitive evidence is shared or protected, what testing applies, how results feed the decision, and what triggers escalation. For its more mature version, it suggests running agreed tests in a protected environment, including prompt-injection and tool-use boundary tests for LLM agents.

That is the right architecture. But every one of those fields asks about the system. For agents, the intake needs two more that ask about the principal.

8. On whose authority does this agent act? Not a developer account, but a verified person or legal entity that can be held accountable. Agent Name Service’s support for Legal Entity Identifiers is the right instinct; it should be the default, not an option.

9. What is it permitted to do, and until when? Spend limits, data categories, decision types and an expiry, inspectable by the counterparty and revocable by the principal. Tool-use boundary tests tell you whether an agent stays inside its limits. They can’t tell you whether those limits were ever authorized.

Add those two fields and the paper’s escalation triggers gain an obvious new one: any change to an agent’s principal or scope. Its liability conversation gains an anchor, because risk can be assigned to a named party before deployment rather than argued over after an incident.

One caution as these pieces connect. Portable conformity evidence is a breakthrough for efficiency, but a system can pass every assessment and still act outside what its principal actually authorized. Identity and delegation have to travel alongside conformity evidence, or we will build a supply chain of well-tested systems that nobody is answerable for.

Who benefits

The question I keep coming back to is the one I’ve asked of every trust system I’ve studied: who benefits from how it’s designed?

The white paper deliberately scopes itself to business-to-business trust, on the reasoning that it sits upstream of consumer trust. I think that’s right, and agents make it more right. Every delegation chain ends at someone: the customer whose card, data or decision the agent is acting on. If agent identity is built as a developer convenience, it will benefit whoever deploys agents fastest and push the risk downstream to the people least able to inspect the system. If it’s built as accountability infrastructure, binding agents to principals, making delegation visible and assigning liability up front, it protects them.

The building blocks exist. The industry now has to decide whether to connect them.

The test of a trustworthy agent was never whether it’s smart. It’s whether, when it fails, we already know who answers for it.

---

Lubna Alli works on AI trust, digital identity and responsible technology strategy. She previously led go-to-market strategy for a 0-to-1 identity verification product and advised CIOs and CTOs at Info-Tech Research Group.