The Agentic AI Trust Problem: How Do You Know Who, or What, You're Talking To?

A company's accounts payable system receives a request to update a supplier's bank details. The request arrives through a connected system, correctly formatted, referencing a real purchase order. It comes from an AI agent that says it is acting for the supplier.

Everything looks routine. Then the questions start.

Who owns this agent? Who authorized it to change payment data? Is this the same agent that was approved last quarter, or a different one presenting the same credentials? What is it actually permitted to do? Did a human ask for this change, or did the agent read an instruction embedded in a document and act on it? If the money leaves and never comes back, who is accountable?

None of these questions have satisfying answers in most organizations today. That gap is the agentic AI trust problem, and it is the practical bottleneck standing between pilot projects and production deployment.

The shift underneath it is bigger than any single security control. For twenty years, digital trust meant verifying humans: passwords, tokens, biometrics, device signals. Agentic AI trust requires verifying humans, machines, models, agents, actions, and intent, often in the same transaction. This article maps that problem, separates what existing infrastructure already solves from what remains genuinely unsettled, and offers four conceptual frameworks for reasoning about it.

What Is the Agentic AI Trust Problem?

The agentic AI trust problem is the difficulty of establishing that an AI agent is what it claims to be, has legitimate authority to act, has not been manipulated, is acting on a real human instruction, and can be held to account afterward. It arises because AI agents take actions in live systems rather than only producing text, and because the trust signals humans and machines have historically relied on were not designed for autonomous software acting on someone else's behalf.

Five things must hold for an agent interaction to be trustworthy: Identity + Authorization + Integrity + Intent + Accountability. Most current failures come from treating the first one as if it covers all five.

The Five Layers of Agentic AI Trust

This is a ReadInBrief conceptual framework, not an industry standard. It is offered as a way to structure a problem that tends to get flattened into "AI agents are risky."

1. Identity: Who is this agent?

Can the receiving system establish which specific agent is making a request, distinguish it from every other agent, and tie it to an owning organization and a responsible human? Identity is the foundation, and it is also the layer where existing technology is furthest along.

2. Authorization: What is this agent allowed to do?

Knowing an agent's identity says nothing about its permissions. A correctly identified agent with excessive access is arguably more dangerous than an unidentified one, because it clears the first check and proceeds unimpeded.

3. Integrity: Is this still the agent we trusted?

Agents are assembled at runtime from models, prompts, tools, memory, and retrieved content. Any of those can change between the moment of approval and the moment of action. A tool definition can be modified after review. A document can carry instructions the agent treats as commands. The credential can be valid while the behavior is not.

4. Intent: Why is this action happening?

Somewhere behind every agent action there should be a human goal. Between that goal and the action sit interpretation, planning, and tool selection, all probabilistic. Verifying that an executed action reflects what a person actually wanted is the hardest layer to solve technically, because intent is not directly observable. The best current approaches capture consent as a signed artifact at the moment it is given rather than trying to reconstruct it later.

5. Accountability: Who answers if this goes wrong?

If an agent moves money incorrectly, deletes records, or leaks data, the organization needs to reconstruct what happened and identify who is responsible. Autonomy without accountability creates a governance gap that no amount of authentication closes.

Read as a sequence, the model is: Identity leads to Authorization leads to Integrity leads to Intent leads to Accountability. Each layer assumes the one before it and none of them substitute for the others.

Why Agentic AI Changes the Trust Equation

A conventional chatbot follows a simple path. The user asks a question, the model generates an answer, and the interaction ends. If the model gets something wrong, the cost is a bad answer.

An agentic system looks different:

User
  ↓
AI Agent
  ↓
Planning / Reasoning
  ↓
Tools
  ↓
APIs
  ↓
Business Systems
  ↓
Actions

Once an agent can send emails, modify records, query sensitive databases, schedule meetings, make purchases, trigger workflows, write and execute code, contact customers, or touch financial systems, a wrong decision is no longer a wrong answer. It is a wrong action, already taken, in a system of record.

This is the shift that matters: when AI moves from generating information to taking action, the trust problem stops being about output quality and becomes an access control, identity, and governance problem. The OWASP GenAI Security Project made the same distinction structurally when it published a Top 10 for Agentic Applications in December 2025, separate from its earlier LLM Top 10. The agentic list covers risks that only exist once software plans, holds memory, calls tools, and acts with delegated authority: goal hijacking, tool misuse, identity and privilege abuse, supply chain compromise, memory poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents.

One concept from that work deserves wider circulation. Alongside least privilege, OWASP proposes least agency: autonomy itself should be granted sparingly and deliberately, not treated as a default setting. Restricting what an agent can access is a different control from restricting how far it can act without checking back.

The First Trust Question: Am I Talking to a Human or an AI?

Human trust has always run on informal signals. A familiar voice. A recognizable face on a video call. A writing style that sounds like the colleague who supposedly sent the message. A phone number that has called before. None of these were ever strong authentication, but collectively they worked well enough to run a great deal of commerce and internal decision making.

Generative AI degrades most of them at once.

Voice is the clearest case, because it carries the most instinctive trust and is now the cheapest to fake. Pindrop, whose entire product positioning turns on the question of who is really on the other end of a call, analyzed more than 1.2 billion customer calls for its 2025 Voice Intelligence and Security Report. It measured deepfake fraud attempts rising more than 1,300 percent during 2024, moving from roughly one per month to about seven per day, with synthetic voice attacks up 475 percent at insurance companies and 149 percent at banks. The report puts estimated contact center fraud losses for 2024 at 12.5 billion dollars.

Those numbers describe attacks on human-operated channels by synthetic voices. They matter for the agentic question because they establish something important: the audio channel can no longer carry identity by itself, and the same will become true of video and text as generation quality improves. Any trust architecture that assumes a human can tell the difference is building on sand.

There is a legitimate version of this too. Organizations are deploying AI voice agents for customer service and sales. A customer receiving a call from a competent AI agent has no reliable way to distinguish it from a fraudster's AI agent, and increasingly no reliable way to distinguish either from a human. Disclosure norms help with the honest case and do nothing about the dishonest one.

But the Bigger Question Is: Which AI Agent Is This?

Human versus AI is the intuitive framing and the less important one. As agents proliferate inside enterprises and across the open web, the operative question for any receiving system becomes: which agent is this, acting for whom, with what mandate?

The encouraging news is that this is partly a solved problem wearing unfamiliar clothes. Enterprises have managed non-human identity for years through service accounts, API keys, certificates, OAuth clients, and workload identity systems like SPIFFE. An AI agent making an API call is, at the transport layer, a workload making an API call.

NIST's National Cybersecurity Center of Excellence took exactly this position in a February 2026 concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization. The proposal is to demonstrate how existing identity standards, including OAuth 2.0, SPIFFE/SPIRE, and the Model Context Protocol, can be applied to AI agents rather than inventing a parallel stack. Its core premise is that agents should be identifiable entities inside enterprise identity systems rather than anonymous automation running under shared credentials. That paper sits alongside a broader AI Agent Standards Initiative launched by NIST's Center for AI Standards and Innovation in February 2026, and the in-progress Control Overlays for Securing AI Systems, which will extend SP 800-53 controls to single-agent and multi-agent deployments.

Commercial implementations are ahead of the standards. Microsoft's Entra Agent ID gives agents first-class identity objects inside Entra ID, with two design choices worth noting. Agent identities hold no credentials of their own; they obtain short-lived tokens through an agent identity blueprint using federated identity credentials, so a compromised agent has no long-lived secret to steal. And each agent identity can record a sponsor, the human user or group accountable for it, which is an identity-layer answer to a governance question.

On the open web, the equivalent work is happening at the request level. Cloudflare's Web Bot Auth proposal uses HTTP Message Signatures (RFC 9421) to let agent operators publish public keys at a well-known endpoint and cryptographically sign outgoing requests. A site can then verify that a request genuinely came from a given operator rather than trusting a User-Agent string, which anyone can forge, or an IP range, which is shared and rotates. The approach has moved beyond one vendor: AWS WAF added Web Bot Auth support in November 2025, and Amazon Bedrock AgentCore signs browser requests using the same mechanism.

So the honest assessment on identity is that it is the most tractable of the five layers. What is genuinely new is not the cryptography but the scale, the churn, and the fact that these identities act on behalf of specific humans in ways service accounts never did.

Knowing the Agent Isn't Enough

Consider a procurement agent that authenticates perfectly. Its signature validates. Its certificate chains correctly. It belongs to a supplier your company has worked with for six years.

That establishes identity. It establishes nothing about whether the agent may approve a 500,000 dollar purchase order, change bank details on file, read payroll data, delete customer records, or email confidential documents outside the organization.

Authentication asks: who are you? Authorization asks: what are you allowed to do? Agentic systems need both, and the second is where most current deployments are weakest, because agents tend to inherit the full permission set of whatever credential they were handed. OWASP ranks identity and privilege abuse third on its agentic top ten for precisely this reason.

The failure mode is mundane rather than exotic. An agent is built to summarize support tickets, so it gets an API key with read access to the support platform. That key also happens to carry read access to customer payment metadata, because that is how the scope was defined. Nobody attacks anything. The agent simply has more reach than its task requires, and the day something manipulates its instructions, that reach becomes the blast radius.

Who Gave the AI Agent Permission to Act?

Delegation is the piece that has no clean precedent in machine identity.

Trace a consumer example. Ravi asks his personal AI assistant to book a flight. The assistant contacts an airline system, which contacts a payment provider. The airline needs to establish a chain of facts: this is genuinely Ravi's agent, Ravi authorized this specific booking, the agent is permitted to spend up to some limit, it may or may not select upgrades, it may or may not modify the booking later, and the authority expires at some point.

Traditional OAuth handles a version of this: a user consents to an application accessing a resource with certain scopes. What it handles less well is a delegation that is task-bound rather than resource-bound. "This agent may read your calendar" is an OAuth scope. "This agent may spend up to 40,000 rupees on flights to Delhi this week, once" is a mandate, and mandates are what agentic commerce actually needs.

The most concrete attempt to formalize this is the Agent Payments Protocol (AP2), introduced by Google in September 2025 as an extension to the Agent2Agent protocol and developed with more than sixty payments and technology organizations. AP2 encodes authority as cryptographically signed mandates: an Intent Mandate capturing what the user asked for, a Cart Mandate specifying the exact transaction, and a Payment Mandate authorizing the transfer. Each is independently verifiable and resistant to post-approval modification, which gives a merchant something better than an agent's assertion that a human approved this.

The same delegation question translates directly into enterprise systems. An employee delegates to an enterprise agent, which reaches a CRM, which touches a customer record. Every link needs to answer: on whose authority, within what limits, for how long, and revocable by whom.

What Happens When AI Starts Talking to AI?

Now compose the problem. A realistic near-term flow looks like this:

Customer Agent
  ↓
Merchant Agent
  ↓
Payment Agent
  ↓
Fraud Agent
  ↓
Banking System

No human participates directly in any individual step. Each agent must decide whether to trust the one upstream, and each is making that decision with partial information.

Some of the machinery exists. The Agent2Agent (A2A) protocol, announced by Google in April 2025 and donated to the Linux Foundation that June, standardizes how agents from different vendors discover each other and delegate tasks without exposing their internal state. The Linux Foundation reported in April 2026 that supporting organizations had grown past 150, including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow, with A2A reaching version 1.0 and adding cryptographically signed Agent Cards. Alongside it, the Model Context Protocol, donated by Anthropic to the Linux Foundation's Agentic AI Foundation in December 2025, standardizes the vertical connection between an agent and its tools.

What these protocols provide is a common language for discovery, delegation, and signed assertions. What they do not provide, and do not claim to provide, is a way to know whether the agent on the other end is behaving as its operator intended. Signed Agent Cards prove provenance. They say nothing about whether that agent's instructions were poisoned four steps upstream. OWASP lists insecure inter-agent communication and cascading failures as distinct risks for this reason: in a chain of agents, a single manipulated link propagates, and each downstream agent treats the corrupted output as legitimate input from an authenticated peer.

Could One AI Agent Impersonate Another?

Yes, though the realistic version is less dramatic than the phrase suggests. An attacking agent does not need to psychologically impersonate anything. It needs to obtain whatever the receiving system uses to recognize the legitimate agent.

The documented attack surfaces are familiar ones applied to a new target:

Credential and token theft. Agents hold API keys, OAuth tokens, and service credentials, often in more places than a traditional application would.

Session hijacking. The MCP specification's security best practices explicitly warn against using session identifiers for authentication, precisely because they can be lifted and reused.

Token passthrough. When an intermediary forwards a token it did not validate to a downstream service, the downstream system may treat it as vetted. MCP's specification forbids this as an anti-pattern, since it breaks audience validation and destroys the audit trail: the downstream service sees the token owner, not the agent that actually made the call.

Confused deputy attacks. An agent or proxy with broad legitimate authority is manipulated into exercising it for someone else. The MCP security documentation describes a specific OAuth variant involving static client IDs and consent handling in proxy servers.

Spoofed endpoints and malicious servers. An agent configured to reach a tool server has limited means of verifying that the server is the one it was reviewed against.

Supply chain compromise. OWASP ranks agentic supply chain vulnerabilities fourth, noting that agents assemble components at runtime rather than at build time, which puts a large portion of the dependency graph outside the reach of conventional application security tooling.

None of this requires new attack theory. It requires accepting that agents are now high-value credential holders with broad reach and, frequently, weaker operational controls than the systems they access.

What If the Agent Is Real but Its Instructions Have Been Manipulated?

This is the distinction that most agentic AI security discussion misses, and it is the one that makes identity insufficient on its own.

An agent can be legitimate, correctly authenticated, appropriately authorized, and still behave dangerously, because the content it processes can carry instructions.

Indirect prompt injection works like this:

Agent reads an external document or webpage
  ↓
Content contains instructions written for the model, not the human
  ↓
Agent interprets the content as direction
  ↓
Agent attempts a privileged action using its legitimate credentials

Microsoft's developer guidance on indirect prompt injection in MCP describes the mechanism and its tool poisoning variant, where malicious instructions live in a tool's own metadata. Tool descriptions are read by the model but usually never displayed to the user, which makes the attack invisible at the interface layer. Academic threat modeling published in 2026 examining tool poisoning across major MCP clients found client-side validation of tool metadata to be inconsistent, with several widely used clients offering little protection against hidden parameters or cross-tool manipulation.

The security implication is precise: every credential check in the chain passes. The agent is who it says it is. It is doing something it is technically permitted to do. The instruction simply did not come from the human who authorized it.

This is why the Intent layer cannot be collapsed into the Identity layer, and why researchers red-teaming AP2 in early 2026 observed that signed mandates give strong guarantees about what gets executed while saying nothing about how the decision to execute was reached. Cryptography secures the transaction. It does not secure the reasoning that produced it.

Can the Agent Trust the Tools It Uses?

Invert the question, and a second problem appears that most security programs are not structured to handle.

The two-way trust problem, as a ReadInBrief framing: the system must trust the agent, and the agent must trust its tools, and the tool must verify the agent. Three trust relationships, usually owned by different teams, frequently none of them owning the composite.

An agent consuming a tool takes on risk from:

• Tool descriptions that misrepresent what the tool does

• Compromised or modified integrations, including tools whose definitions change after approval

• Tools requesting or holding excessive permissions

• External content retrieved through tools that carries injected instructions

• Third-party servers with unknown operational security

The practical consequence is that "we vetted this agent" is an incomplete statement. The reviewable unit is the agent plus its current tool set plus the content sources it can reach, and that unit changes without anyone filing a change request.

Does MCP Solve the AI Agent Trust Problem?

No. The Model Context Protocol standardizes how AI applications connect to tools and resources. It does not resolve identity, authorization, prompt injection, tool trust, or governance.

What MCP does contribute is real but bounded. It gives clients a uniform way to discover and invoke tools, defines an OAuth-based authorization model, and, in its security best practices documentation, names specific anti-patterns such as token passthrough and session-based authentication as prohibited. Standardizing the connection layer also standardizes the place where controls can be applied, which is genuinely valuable for security teams who would otherwise be governing dozens of bespoke integrations.

What it does not do is make any particular server trustworthy, prevent a model from being misled by a tool description, or decide whether a given agent should be permitted a given action. NIST's NCCoE paper treats MCP as one input to an agent identity architecture rather than as the architecture itself, which is the right reading. Treating protocol adoption as a security posture is a category error.

When an AI Agent Calls Your Bank

A hypothetical, to make the layers concrete.

A call arrives at a financial institution. A voice says: "I'd like to transfer eight thousand dollars from my account."

The institution now faces a branching problem. The caller could be the customer. It could be the customer's authorized AI assistant. It could be an AI agent the customer once authorized whose credentials have since been compromised. It could be a cloned voice built from a podcast appearance. It could be a fraudster's agent with no relationship to the customer at all. Given the Pindrop data on synthetic voice volumes in contact centers, the last two options are not hypothetical at the population level.

Work through the five layers and the inadequacy of copying human authentication becomes obvious.

Identity. Voice is now a weak identity signal, not a strong one. If the caller is an agent, the meaningful identity question is cryptographic, not acoustic.

Authorization. If it is a legitimate agent, what is its transfer limit? Was that limit set by the customer, and is it verifiable at the bank, or only asserted by the agent?

Integrity. Is this the same agent configuration the customer authorized, or has its tool set or instruction context changed?

Intent. Did the customer ask for this transfer, or did the agent infer it from an email that turned out to be a phishing message?

Accountability. If the transfer is fraudulent, whose liability is it? The customer who delegated, the agent vendor, the bank that executed, or the model provider?

Knowledge-based authentication answers none of these. Neither does voice biometrics alone. The architecture that eventually works will probably combine cryptographic agent credentials, verifiable delegation artifacts, risk scoring on the action rather than the caller, and human confirmation on a separate channel for high-consequence transactions.

What Could an AI Agent's Digital Identity Look Like?

It helps to separate what exists from what is emerging from what is speculation.

Available and deployed today: OAuth 2.0 and OpenID Connect, X.509 certificates and mutual TLS, workload identity systems including SPIFFE/SPIRE, short-lived tokens, scoped API credentials, and enterprise agent identity products such as Microsoft Entra Agent ID. HTTP Message Signatures for request-level agent verification are deployed at Cloudflare and AWS.

Emerging, with real implementations but unsettled practice: signed delegation mandates of the kind AP2 defines, signed Agent Cards in A2A, agent registries, policy-bound credentials that encode task limits rather than only resource scopes, and standardized agent-to-agent authorization patterns. NIST's own agent identity work is at concept-paper stage, with an AI Agent Interoperability Profile targeted for late 2026.

Speculative: portable cross-organizational agent reputation, universal agent registries with meaningful enforcement, attestation of an agent's full runtime configuration including its model and prompt state, and anything resembling a globally recognized agent credential.

The gap between the second and third categories is where most vendor marketing currently operates.

Should Agentic AI Adopt Zero-Trust Principles?

Yes, and the mapping is unusually direct. Zero trust, as articulated in NIST SP 800-207, holds that trust is never granted implicitly based on network location or prior authentication, and must be continuously evaluated per request.

Applied to agents:

Agent identity
  ↓
Request
  ↓
Permission check
  ↓
Risk evaluation
  ↓
Action
  ↓
Audit

Four principles carry particular weight here. Least privilege, because agents accumulate access faster than humans do. Short-lived credentials, because a long-lived agent secret is a long-lived liability. Context-aware authorization, because the same action can be routine or alarming depending on time, volume, and target. And action-level controls, because authorizing an agent once at session start is not equivalent to authorizing each thing it subsequently does.

That last point is the crux. Traditional access control authenticates a session. Agentic systems need authorization decisions attached to individual consequential actions, because a single authenticated session may produce hundreds of them, and only some deserve scrutiny.

When Should AI Agents Still Ask Humans?

Not every action warrants the same friction. A useful ReadInBrief framing is risk-adjusted autonomy: autonomy should decrease as consequence increases, and the tiering should be explicit rather than emergent.

This aligns with OWASP's least agency principle: autonomy is a permission to be granted per action class, not a property of the agent as a whole. An agent can be fully autonomous for research and fully gated for payments, and most useful enterprise agents should be exactly that.

The Agentic AI Trust Ladder

A second ReadInBrief conceptual framework, useful for assessing where a given deployment actually sits.

Level 0: Unknown Agent. Traffic arrives with no verifiable identity. User-Agent strings and IP ranges are the only signals, both trivially forged.

Level 1: Identified Agent. The agent presents a claimed identity, but the receiving system cannot cryptographically verify it. Better than nothing for logging, worthless against an adversary.

Level 2: Authenticated Agent. Identity is cryptographically verified through signed requests, certificates, or federated tokens. The system knows who. It still does not know what they may do.

Level 3: Authorized Agent. Verified identity is bound to an explicit permission set, ideally scoped to task rather than to resource, with expiry and revocation.

Level 4: Contextually Verified Action. The specific action is evaluated against policy, risk signals, delegation evidence, and consequence tier at the moment of execution, not only at session start.

Level 5: Auditable and Accountable Agent. Every consequential action is logged with sufficient context to reconstruct what happened, attributed to an accountable human or organization, and reviewable after the fact.

The important claim embedded in this ladder: trust should attach to the action, not only to the agent. A Level 5 agent performing an unusual action at an unusual time against an unusual target should still be stopped. Most current deployments sit between Level 1 and Level 3.

What a Trusted Enterprise Agent Architecture Could Look Like

One possible shape, not the only correct one:

Employee / Customer
  ↓
Identity Provider
  ↓
AI Agent
  ↓
Agent Identity
  ↓
Policy / Authorization Layer
  ↓
Tool Gateway
  ↓
MCP / APIs
  ↓
Enterprise Systems
  ↓
Audit + Monitoring

The identity provider authenticates the human and issues the delegation. The agent identity is a first-class, individually addressable principal with an accountable owner, ideally holding no long-lived credentials itself. The policy and authorization layer makes per-action decisions using identity, delegation evidence, and context, and it is the natural place to enforce risk-adjusted autonomy. The tool gateway is where organizations gain leverage they cannot get anywhere else: a single chokepoint that controls which tools and MCP servers an agent may reach, validates tool definitions, and prevents agents from silently acquiring new capabilities. Secrets management keeps credentials out of agent memory and prompts. Audit and monitoring capture what happened, and fraud detection applies behavioral analysis to agent activity in the way it currently applies to human activity.

Two observations from how these deployments actually go. First, the tool gateway is the highest-leverage component and the one most often missing. Second, the policy layer only works if it can see the delegation chain, which means the delegation has to be captured as data at the point of consent rather than reconstructed from logs afterward.

12 Questions to Ask Before Trusting an AI Agent

A checklist for security and technology leaders evaluating an agent for production:

1. Can we cryptographically identify this agent, or only its claimed name?

2. Which organization owns it, and which named human sponsors it?

3. Who authorized it to act, and is that authorization captured as verifiable evidence?

4. Which systems can it reach, and does that list match its actual task?

5. What actions can it perform, tiered by consequence?

6. What data can it read, and does that include anything its task does not require?

7. Do its credentials expire, and how short-lived are they?

8. Can we revoke its access immediately, and has anyone tested that path?

9. Which actions require human approval, and is that gate enforced technically or by policy alone?

10. Can we detect abnormal behavior, including a legitimate agent acting unusually?

11. Is every consequential action logged with enough context to reconstruct the decision?

12. When something goes wrong, who is accountable, and is that documented before deployment rather than after the incident?

Questions 3, 9, and 12 are the ones most often unanswered, and they map to the Intent and Accountability layers that identity infrastructure does not cover.

If an AI Agent Makes a Decision, Can We Reconstruct What Happened?

Partially, and the limits are worth stating honestly.

Observable and loggable: tool calls and their parameters, data accessed, actions executed, authorization decisions and their inputs, human approvals, policy evaluations, and the content retrieved into context.

Not directly observable: why the model selected one tool over another, how it weighted competing instructions, and what internal representation led to a given plan. Chain-of-thought text, where available, is an artifact the model produces rather than a faithful trace of its computation, and treating it as an audit record overstates what it is.

Conventional application logging captures the wrong granularity for this. An access log showing "agent X read record Y at time Z" omits the context that makes the event interpretable: which user task this served, which retrieved document may have influenced it, which delegation authorized it. Agent observability, as a discipline, is roughly where application performance monitoring was two decades ago. NIST's NCCoE concept paper explicitly raises auditing and non-repudiation for AI agents as open questions, which is a reasonable signal of maturity.

The practical guidance: log the agent's inputs and outputs at tool boundaries, log the authorization decision alongside the action, and preserve the delegation artifact. Those three make most incidents reconstructable without requiring access to model internals.

When an AI Agent Makes a Mistake, Who Is Responsible?

Legal answers here are unsettled and jurisdiction-dependent, and this article will not pretend otherwise. From a systems design perspective, though, the accountable parties are enumerable: the user who delegated, the enterprise that deployed, the agent developer, the foundation model provider, the tool or MCP server provider, the SaaS platform being acted upon, and the infrastructure provider.

The design failure is not that responsibility is ambiguous in principle. It is that most deployments never assign it in advance, so the question first gets asked during an incident, when the answer is least likely to be reached calmly.

Two mechanisms help. The first is a named human sponsor per agent, which several enterprise identity products now support as a first-class field, so accountability is recorded in the identity system rather than in tribal knowledge. The second is a documented decision, before deployment, about which failure modes belong to which party, including the uncomfortable ones. An enterprise that cannot answer "who owns this if it moves money incorrectly" before launch is not ready to launch.

Autonomy without accountability creates a governance gap, and the gap grows with the number of agents.

Will AI Agents Eventually Have Reputation Scores?

This is analysis rather than reporting. The idea is intuitive: agents accumulate a history of successful transactions, policy compliance, and fraud signals, and counterparties price trust accordingly, the way payment networks score merchants.

Arguments for: reputation would let systems make graduated decisions about unfamiliar agents rather than binary allow-or-block ones, and it would create an incentive for operators to run their agents well.

Arguments against, and they are substantial. Reputation systems are manipulable, and an adversary with resources can build a clean history before defecting. Scores encode bias from whatever data trains them. Portability across organizations raises privacy questions about what a score reveals regarding the humans behind the agent. False positives would exclude legitimate agents with no clear appeals path. And centralized scoring hands a small number of intermediaries substantial control over which agents can participate in commerce.

The likelier near-term outcome is narrower: reputation-like signals operating inside individual platforms and payment networks, closer to existing merchant risk scoring than to a portable agent credit rating.

Do AI Agents Need a Digital Passport?

The phrase "AI agent passport" is an explanatory concept, not a deployed standard, and should be treated as such when it appears in vendor material.

What such a credential would need to assert is reasonably clear: agent identity, owning organization, accountable human operator, model and provider, authorized capabilities, permission scope, issuing authority, expiration, and some attestation of security posture.

Several existing pieces do parts of this. A2A's signed Agent Cards assert identity and capabilities. Web Bot Auth asserts operator provenance at the request level. Entra agent identities carry ownership and sponsorship inside a tenant. AP2 mandates carry delegated authority for a specific transaction. What does not exist is a single portable credential that carries all of it across organizational boundaries with agreed semantics and revocation, and NIST's interoperability profile work suggests the industry is at least a year from converging on one.

Whether it should exist is a genuine open question. A universal agent passport implies a registration authority, and the governance question of who operates it is harder than the technical one.

AI Trust and AI Safety Are Not the Same Thing

These terms are used interchangeably and refer to different problems.

Agentic AI trust sits across all six. An organization with excellent model safety evaluations and no agent identity architecture has solved one column. This matters practically because these questions typically belong to different teams, and the composite risk lives in the seams between them.

Authentication Alone Won't Solve Agentic AI Trust

Worth stating plainly, because it is the article's central technical claim.

A perfectly authenticated agent can still hold excessive permissions, misinterpret an ambiguous instruction, be manipulated through injected content, rely on a compromised tool, or execute an action no human ever requested. Every one of those failures occurs after identity has been established correctly.

Identity is necessary. It is the entry condition for everything else, and organizations without it cannot build the other layers. But treating agent identity as the solution to agentic AI trust is the same mistake as treating a valid passport as proof that a traveler intends no harm.

The Emerging Agentic AI Trust Stack

Verified work, mapped to the trust problem each piece addresses.

The pattern across this list is worth noting: almost every serious effort extends existing security infrastructure rather than replacing it. That is a good sign about the industry's direction and a useful counter to claims that agentic AI requires an entirely new trust stack.

What Happens When AI Agents Start Spending Money?

Agentic commerce compresses every layer of the trust problem into a single transaction with immediate financial consequence.

The questions a merchant must answer are concrete: Who authorized this purchase, and can that authorization be verified independently of the agent's assertion? What spending limit applies? Is this agent operating for the customer it claims? Can the customer dispute a transaction their agent initiated, and against whom? Can a fraudster deploy a convincing purchasing agent at scale?

AP2's mandate structure is a direct answer to the first two, and its adoption by a large payments coalition suggests the industry recognizes that an agent's claim of user consent is not sufficient evidence. The unresolved parts are the dispute and liability mechanics. Existing chargeback frameworks assume a human cardholder who either did or did not authorize a transaction. An agent that was legitimately authorized but made a poor decision, or was manipulated into a purchase, does not map cleanly onto either category. Payment networks are actively working on this, and the resolution will be as much rulebook as protocol.

The Internet May Need a Trust Layer for AI Agents

Two defensible positions here, and honest analysis presents both.

The case for a new trust layer. Agent traffic is growing faster than the mechanisms for governing it. The web's existing trust infrastructure was built for humans using browsers and for servers talking to servers, not for autonomous software acting on a human's behalf across organizational boundaries. Delegation, in particular, has no clean primitive: OAuth scopes describe resource access, not bounded task authority. The rapid emergence of A2A, AP2, Web Bot Auth, and agent identity products in under two years suggests the market is discovering genuine gaps rather than inventing problems.

The case against. Every one of those efforts is an extension of something existing. Web Bot Auth is HTTP Message Signatures. AP2 is signed assertions over established payment rails. Entra Agent ID is service principals with better ergonomics. NIST's own framing is that existing identity standards should be applied to agents rather than replaced. Historically, new trust layers built from scratch fail, and incremental extensions of PKI, OAuth, and zero trust architecture succeed. The infrastructure may simply evolve.

The likely synthesis: existing standards handle identity and authentication adequately, while delegation, intent evidence, and cross-organizational accountability need genuinely new primitives layered on top. That is a narrower gap than "the internet needs a trust layer for AI" implies, and a more tractable one.

Five Agentic AI Trust Questions That Could Define the Next Few Years

1. Will AI agents receive standardized digital identities?

Partial standardization looks likely within enterprises, where Entra Agent ID and equivalents are already deployed. Cross-organizational standardization is harder and depends on whether NIST's interoperability work and the Linux Foundation protocols converge or fragment.

2. How will humans delegate authority safely?

This is the least solved and most consequential question. AP2's mandate model is the strongest current answer, but it is scoped to payments. The general case, delegating bounded task authority to software across trust boundaries, remains open.

3. How will agents authenticate other agents?

A2A provides the mechanism. The unresolved part is what an authenticated peer's assertions are worth, given that authentication says nothing about whether that agent's instructions were manipulated upstream.

4. How will businesses detect malicious agents?

Probably by extending fraud detection rather than inventing agent-specific security: behavioral baselines, anomaly detection on action patterns, and risk scoring at the action level. The organizations best positioned are those that already do this for human users.

5. Who will be accountable for autonomous transactions?

This will likely be settled by payment network rules, contracts, and regulation before it is settled by technology, and the answer may differ by jurisdiction and sector.

Trust May Become the Most Important Infrastructure for Agentic AI

Return to the opening scenario. The finance system received a legitimate-looking request from an agent claiming to act for a supplier.

The question that felt urgent was: is this a human or an AI? That turns out to be the shallow version. The questions that actually determine whether the request should be processed are: which agent is this, who authorized it, what is it permitted to do, has anything manipulated the instructions it received, can we reconstruct this decision later, and who answers if it is wrong.

Identity infrastructure answers the first two and is further along than most coverage suggests. Authorization is solvable with discipline that most organizations have not yet applied. Integrity and intent remain genuinely hard, because they concern how a probabilistic system reached a decision rather than whether a credential was valid. Accountability is not a technical problem at all; it is a governance decision that organizations keep deferring until an incident forces it.

The competitive story around agentic AI has been about capability: which agents can do the most, plan furthest, use the most tools. That framing may be measuring the wrong thing. Capability determines what an agent could do. Trust determines what an organization will actually let it do, and every capability that cannot be safely authorized stays in a pilot environment. The agentic systems that reach production at scale will not necessarily be the most capable ones. They will be the ones whose actions an enterprise can verify, bound, observe, and answer for.

FAQs

Frequently Asked Questions

What is the agentic AI trust problem?

The agentic AI trust problem is the difficulty of establishing that an AI agent is who it claims to be, has authority to act, has not been manipulated, is following a genuine human instruction, and can be held accountable afterward. It emerges because agents take real actions in live systems, where a wrong decision becomes a wrong action rather than a wrong answer.

Can AI agents be trusted?

Individual agents can be trusted for specific, bounded actions under verifiable conditions. Blanket trust is not appropriate. A useful approach ties trust to the action rather than the agent: an agent may be fully autonomous for low-consequence tasks such as internal search, while high-consequence actions like transferring funds require explicit human approval regardless of how well the agent is authenticated.

How do you authenticate an AI agent?

Through the same cryptographic mechanisms used for other non-human identities: OAuth 2.0 tokens, X.509 certificates, mutual TLS, workload identity systems such as SPIFFE/SPIRE, and signed HTTP requests using message signatures. Enterprise products like Microsoft Entra Agent ID issue agent identities that obtain short-lived tokens rather than holding long-lived credentials, reducing what an attacker can steal.

What is AI agent identity?

AI agent identity is a distinct, verifiable identity assigned to an AI agent so systems can distinguish it from human users, from other agents, and from conventional applications. A useful agent identity includes an owning organization, an accountable human sponsor, a defined permission scope, and credentials that expire and can be revoked immediately.

Can an AI agent impersonate another AI agent?

Yes, though usually through credential compromise rather than imitation. An attacker who obtains an agent's API keys, tokens, or session identifiers can present as that agent to any system relying on those credentials. Spoofed endpoints, token passthrough between services, and compromised tool servers create additional paths for one agent to act with another's authority.

How can companies secure AI agents?

Give every agent a distinct verifiable identity, scope permissions to the specific task rather than inheriting broad credentials, use short-lived revocable credentials, route tool access through a gateway that controls which tools an agent can reach, require human approval for consequential actions, log every action with enough context to reconstruct it, and assign a named accountable owner before deployment.

What is non-human identity?

Non-human identity refers to identities belonging to software rather than people: service accounts, API clients, workloads, machines, and now AI agents. Enterprises have managed these for years, but agents differ in that they act on behalf of specific humans, make runtime decisions, and often reach far more systems than a conventional service account.

How does Zero Trust apply to AI agents?

Zero trust, defined in NIST SP 800-207, holds that trust is never implicit and must be evaluated per request rather than granted by network location or prior authentication. For agents this means least privilege, short-lived credentials, context-aware authorization, and authorization decisions attached to individual consequential actions rather than granted once at the start of a session.

Does MCP make AI agents secure?

No. The Model Context Protocol standardizes how AI applications connect to tools and defines an OAuth-based authorization model, and its specification names anti-patterns such as token passthrough as prohibited. It does not verify that any given server is trustworthy, prevent prompt injection or tool poisoning, or decide whether an agent should be permitted a particular action. Standardizing connections is not the same as securing them.

What is the difference between AI safety and AI security?

AI safety concerns whether a system causes harm through its own behavior, including unintended or misaligned outputs. AI security concerns whether attackers can compromise or manipulate the system. A model can be safe and insecure, or secure and unsafe. Agentic AI trust requires both, plus identity, authorization, governance, and accountability.

How can you tell if you're talking to AI?

With decreasing reliability. Voice, video, and writing style are no longer dependable signals, and Pindrop's analysis of over a billion contact center calls documented deepfake fraud attempts rising more than 1,300 percent during 2024. Disclosure requirements help with legitimate AI use and do nothing about fraudulent use. Durable answers will come from cryptographic verification of the calling system rather than human perception.

Can AI voice agents be authenticated?

The agent can be, through cryptographic credentials at the connection or API layer. The voice itself cannot serve as reliable authentication, since synthetic speech can now reproduce a specific person's voice from short samples. Practical approaches combine call-metadata analysis, liveness and deepfake detection, device signals, and out-of-band confirmation for high-risk actions.

Who is responsible for an AI agent's actions?

Legally this remains unsettled and varies by jurisdiction. From a design perspective, candidates include the delegating user, the deploying enterprise, the agent developer, the model provider, the tool provider, and the platform acted upon. The practical requirement is to assign a named accountable owner and document liability boundaries before deployment rather than during an incident.

Do AI agents need digital identities?

Yes, for any agent touching enterprise systems. Without a distinct identity, agent actions cannot be attributed, permissions cannot be scoped, access cannot be revoked cleanly, and audit trails collapse into whatever shared credential the agent borrowed. NIST's NCCoE has proposed applying existing identity standards to agents rather than treating them as anonymous automation.

What is delegated authorization for AI agents?

Delegated authorization is the mechanism by which a human grants an agent bounded authority to act on their behalf. Beyond identity, it should specify what the agent may do, within what limits, for how long, and how the grant is revoked. The Agent Payments Protocol formalizes this for commerce using cryptographically signed mandates that capture user intent, transaction details, and payment authorization separately.

Key Takeaways

What Businesses Should Understand Now

1. Machine identity becomes central. Every agent touching enterprise systems needs a distinct, verifiable identity with a named accountable owner, not a borrowed service account.

2. Authentication and authorization are different problems. Knowing which agent is calling says nothing about what it should be permitted to do, and permission scoping is where most current deployments are weakest.

3. Identity cannot prevent manipulated behavior. A correctly authenticated, correctly authorized agent can still be steered by injected content. Prompt injection defeats credential checks by never triggering them.

4. Tool trust runs in both directions. The system must trust the agent, and the agent must trust its tools. A tool gateway that controls which tools an agent can reach is the highest-leverage control most organizations are missing.

5. Voice and deepfake technology have degraded human trust signals. Contact centers and any process relying on voice recognition need detection layers and out-of-band confirmation for consequential requests.

6. Autonomy should scale inversely with consequence. Grant full autonomy for low-risk actions and require human approval for critical ones, enforced technically rather than by policy alone.

7. Observability and accountability need designing in. Log actions with authorization context and preserve delegation evidence, and decide who owns failures before launch.

8. Existing security infrastructure remains the foundation. Nearly every credible agent trust initiative extends OAuth, PKI, workload identity, and zero trust rather than replacing them. Teams strong in identity and access management are better positioned than they think.