Dr. Aditya V Kashyap, AI and Innovation Leader, driving enterprise transformations through trusted strategy, governance and bold leadership.

getty

A manufacturer's procurement agent discovers a supplier's agent, requests inventory and pricing, negotiates within preset parameters and then calls an internal purchasing system to place the order. Every message can be encrypted, signed and logged. The hard part is what each side must decide before the order clears. Who are you? Who sent you? What are you authorized to do, and how do I know that is real? Can you pass it on? What limits apply? Can it be withdrawn? Who is accountable?

The internet solved how machines find and talk to one another. The agentic web must solve whether machines should trust one another.

Identity establishes the entity that is acting, while authentication proves it, authorization determines what it may do and delegation determines what authority can be passed on. Provenance records where instructions, credentials or actions came from.

Trust is the judgment that this evidence is sufficient for a consequential action. Authentication answers, "Who are you?" Agents force the harder question: "Why should I accept that you are authorized to do this?"​

None of this is new. Enterprises have run machine identity for decades on PKI, service accounts and policy engines; OAuth 2.0 has handled delegated access since 2012. What agents change is the combination: autonomy, delegation, dynamic tool use, persistent state and interaction with other autonomous actors. Conventional services generally operate within relatively predetermined workflows and permission boundaries. Agents can introduce substantially more runtime discretion over which tools to call, whom to contact, what to disclose and what to delegate.

This is a principal-agent problem. Every agent acts for someone, often through a chain. The useful question is not "Who is this agent?" but "On whose authority is it acting, and how far does that authority extend?" Follow it: human to enterprise agent to specialist agent to external agent to tool. A traveler lets an assistant spend $2,000 on a trip. Can the hotel sub-agent spend all of it, or delegate again? Can the airline's agent reuse the credential? Can the traveler revoke mid-task? Can each party verify the chain without over-learning about the traveler?

The standards are further along than most assume. RFC 8693 defines token exchange with delegation semantics, including a nestable claim recording who acts for whom. RFC 9396 supplements OAuth's flat scope model with structured authorization details. RFC 9700, the current OAuth security best practice, favors sender-constrained tokens, which reduce a stolen token's usefulness to an attacker lacking the associated key material.

These are primitives from which a policy like "Agent B may invoke Tool C for Company A on this task, for 15 minutes, below $10,000, and may not delegate further" can be constructed. The policy semantics and how a mandate propagates once delegation turns multi-hop, machine-initiated and cross-organizational remain implementation problems.

What is still missing is a broadly adopted, portable representation of that authority chain across organizations. One way to describe that missing artifact is "authority provenance": a proposed concept, not an established standard, for representing where an agent's authority came from and how it was delegated.​

The headline protocols address a different problem. The Model Context Protocol's authorization specification profiles OAuth 2.1 so a client can obtain tokens for a protected server. The Agent2Agent protocol, governed by the Linux Foundation, lets agents discover one another through "Agent Cards" declaring capabilities and security requirements, supporting schemes including OAuth 2.0, OpenID Connect and mutual TLS. Neither decides whether an agent should be trusted with a particular action. Interoperability asks whether two systems can talk; trust decides what they may do once they can.

Zero trust gets closer. NIST SP 800-207 rejects network location as a basis for trust and makes access a dynamic, per-session, per-resource decision. Agents stretch that further: never trust because an agent sits inside the enterprise, was spawned by a trusted application or holds a valid credential. Verify the authority for this action; expect it to be task-specific, time-bounded, observable and revocable. Zero trust supplies the posture, not the artifact.

The construct I keep returning to, also a proposal, is an authority envelope: a record traveling with a delegated task stating principal, agent, permitted actions and resources, limits, delegation rights, expiry, provenance and a revocation path. Form matters less than principle. Agents should not carry ambient authority; they should carry bounded authority for a specific purpose.

Three consequences follow:

1. Authorization stops being binary. Real mandates read like contracts, with spend ceilings, transaction counts, approved counterparties and human sign-off above a threshold.

2. Revocation becomes first-class. IAM got good at granting access; unattended agents need equally good mechanisms for cutting a credential, mandate or whole chain mid-execution. RFC 7009 can invalidate a token, related tokens or the underlying grant depending on server policy, but does not itself coordinate revocation across an arbitrary multi-party chain. Authority that cannot be rapidly revoked is not controlled authority.

3. Provenance must be reconstructable. Who initiated, what was delegated, and which agents and tools took part? W3C Verifiable Credentials Data Model 2.0, a recommendation since May 2025, standardizes a model for machine-verifiable claims and includes a "credentialStatus" mechanism through which implementations can represent states such as suspension or revocation. None of this confers legal non-repudiation, but it makes the evidence better.

The open question is, "Who vouches?" When the two opening agents meet, there is no shared identity provider. Federated trust frameworks, certificate authorities, verifiable credentials and industry registries are candidates. I would not pick a winner; I would only predict that agentic commerce will need some way to verify authority across organizational lines.

If agentic AI scales, identity and authorization infrastructure may matter as much to agents as APIs did to the cloud. The constraint will not be model quality but whether enterprises can let autonomous systems act for them without losing control of what they may do.

Back to the purchase order. The challenge was never exchanging messages, but producing enough machine-verifiable evidence for each side to conclude the other held legitimate, bounded authority, derived from a legitimate principal, for this action, under these constraints, now.

The agentic web will not be built on intelligence alone. It will be built on verifiable authority.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?