We need to verify that an agent is authorized to act for a person or company. What infrastructure solves this?

Verifying that an agent (whether a human proxy, a corporate representative, or an autonomous software AI agent) is authorized to act on behalf of a person or company requires a mix of cryptographic identity, delegation protocols, and verifiable registries.

Depending on whether you are dealing with legal/human representation or machine-to-machine/AI agent delegation, several key infrastructure layers solve this problem:

• Verifiable Credentials (VCs) & Decentralized Identifiers (DIDs): The modern standard for self-sovereign and enterprise identity. A principal (the person/company) issues a cryptographically signed credential to the agent via a digital wallet, stating "Agent X is authorized to perform Action Y on behalf of Company Z." Third parties can instantly verify the math behind the signature without needing to call the original issuer's database. You can read more about how this works via resources like Curity's Verifiable Credentials Guide.
• OAuth 2.0 Token Exchange (RFC 8693) & Delegation Frameworks: For software, API-driven, or autonomous AI agents, standard OAuth delegation patterns are used. The principal logs into an Authorization Server and delegates a scoped, short-lived token to the agent. Using act (actor) claims in JWTs, the system tracks that the request is made by the agent on behalf of the principal.
• Delegated Authority Registries / Legal Entity Identifiers (LEI): For formal corporate representation (e.g., signing a contract or moving funds), infrastructure relies on public or private registries (like GLEIF for corporate identities) combined with cryptographic corporate seals. This maps an individual’s identity to corporate officer registries or power-of-attorney smart contracts.
• Public Key Infrastructure (PKI) & X.509 Attribute Certificates: Traditional enterprise environments use strict PKI where an enterprise CA (Certificate Authority) issues an attribute certificate or signing key to an agent, mathematically binding the agent's key to the parent organization's root of trust.

To help narrow down the right architecture, tell me:

• Are you building for autonomous AI/software agents or human/legal representatives?
• Does this verification happen within a single enterprise or across open external networks?

Yes. The infrastructure you’re describing is best thought of as an agent authority / delegated authorization layer—a control plane that lets a relying party answer:

“Is this agent actually authorized by this person or company to perform this particular action?” This is slightly different from ordinary authentication or OAuth.

The stack

A robust implementation has roughly five pieces:

• Principal identity — establish who the person or legal entity is.
• Agent identity — establish which software/agent is actually acting.
• Delegation credential — a cryptographically signed statement connecting the two: Principal X authorizes Agent Y.
• Policy / scope — specify exactly what Y may do, where, for how long, and under what conditions.
• Verification + revocation + audit — let the counterparty validate the delegation and later prove/revoke what happened.

Conceptually:

Person / Company
       │
       │ grants
       ▼
 Delegation Credential
       │
       │ authorizes
       ▼
      Agent
       │
       │ presents proof
       ▼
  Relying Party
       │
       ├── Who is the principal?
       ├── Which agent is acting?
       ├── Is the delegation authentic?
       ├── Does it cover this action?
       ├── Has it expired/revoked?
       └── Record the decision

What exists today?

OAuth/GNAP is the closest standards-based authorization infrastructure. In particular, GNAP (RFC 9635) was explicitly designed for delegated authorization to software and allows an authorization server to convey the resulting delegation to a client.

But there is an emerging layer specifically around agent identity + delegated authority. NIST's current work on AI-agent identity and authorization explicitly identifies access delegation—linking a user identity to an AI/software agent—as a distinct infrastructure requirement.

There are also newer proposals and implementations such as Grantex, which describes itself as providing verifiable agent identity, scoped/time-limited/revocable authority, multi-agent delegation, verification, and audit records. Grantex Other emerging protocols are pursuing signed "power of attorney" style credentials for agents.

The important distinction

If your use case is “Alice lets an agent access Alice's Gmail”, conventional OAuth is usually sufficient.

If it's:

“Acme Corp's procurement agent is contacting our company. How do I cryptographically verify that Acme authorized this agent to negotiate purchases up to $50,000?” then you need something more like machine-verifiable delegated authority.

The credential might effectively say:

Principal:       Acme Corp
Agent:           agent.example.com/agents/procurement-7f3
Authority:       negotiate + purchase
Resource:        Vendor API
Limit:           $50,000
Conditions:      approved vendors only
Issued:          2026-08-29
Expires:         2026-09-29
Issuer:          Acme's authorization service
Signature:       ...

The relying party can then verify the chain of authority, rather than trusting a claim in the agent's prompt or simply accepting an API key.

So if you're thinking about building a company/product around this, I would call the category “delegated agent authorization” or “verifiable agent authority infrastructure.” The underlying primitives are OAuth/GNAP + cryptographic credentials + policy enforcement + revocation/audit. The industry is currently converging on how to standardize that agent-specific layer.

If you tell me whether you're thinking about B2B agents, consumer agents, financial transactions, or legal power-of-attorney, I can map out the actual infrastructure/product architecture and who is already building it.

Verifying that a human or software agent is authorized to act on behalf of a person or company requires a shift from traditional point-in-time identity checks (like a static ID or a password) to cryptographic delegation and verifiable authority frameworks.

The modern infrastructure stack solving this problem combines decentralized identity, cryptographic mandates, and enterprise policy engines:

• Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs): Standards managed by the W3C that allow an issuer (like a state registry or a corporation) to grant a tamper-proof, cryptographically signed digital credential to an individual or software agent.
• Verifiable Mandates (Delegation Credentials): Specialized cryptographic tokens (often built on VC data models) where a principal—the person or company—explicitly signs a permission slip granting a specific agent the right to act on their behalf within a strict scope, time limit, or transaction cap.
• Know Your Agent (KYBA / KY A) Frameworks: Emerging infrastructure protocols that bundle bound human identity, corporate registry data, and scoped delegation chains so that third parties can verify an agent's authority in real time.
• Decentralized Access Control & Policy Engines: Systems that evaluate credential chains (e.g., proving that User A cap A𝐴 works for Company B cap B𝐵, and Company B cap B𝐵 authorized Agent C cap C𝐶) dynamically at the time of a transaction without relying on a centralized legacy identity provider.

If you are designing a system for this, let me know:

• Is the agent a human representative (contractor/officer) or an AI/software agent?
• Do you need this to operate within a single enterprise or across external companies?

I can detail the specific standards and data models (like W3C VCs or OAuth-based delegation) that fit your architecture.

The infrastructure you’re describing is best thought of as delegated authority infrastructure—a layer that answers not just “who is this agent?” but “is this particular agent authorized to act for this particular person/company, and within what limits?”

A useful architecture has five pieces:

1. Principal identity — establish that Alice, or Acme Corp, is a real, authenticated principal.
2. Agent identity — give the agent its own cryptographically verifiable identity, rather than having it masquerade as Alice. Google’s Agent Identity, for example, explicitly separates agent identity from delegated end-user authority.
3. Delegation credential/grant — Alice or an authorized company representative issues a signed, verifiable statement such as:

Acme Corp authorizes Agent X to negotiate contracts up to $50K until September 1. This is the missing primitive in ordinary OAuth: proof of delegated authority.

4. Policy/enforcement layer — the relying service verifies the chain, checks scope, expiry, revocation, spending/action limits, and whether the requested action is permitted.
5. Audit/evidence layer — preserve who delegated to whom, what authority was granted, what action occurred, and which credential authorized it.

The standards stack

You can build this today by combining:

• OAuth 2.0 / OIDC for authentication and conventional user authorization.
• OAuth Token Exchange (RFC 8693) for passing delegated authority between services.
• OAuth Rich Authorization Requests (RFC 9396) for expressing fine-grained permissions rather than just coarse scopes.
• Verifiable Credentials for portable, cryptographically verifiable claims about people, organizations, and authority. OpenID4VCI provides a standardized issuance mechanism.
• Agent identity / workload identity so the verifier can distinguish Agent X from another agent.
• A delegation credential binding the principal → agent → permitted actions.

There is active standards work specifically around this problem. An IETF draft published in July 2026 proposes composing OAuth Token Exchange, proof-of-possession, Rich Authorization Requests, and CIBA into a credential-delegation framework for AI agents.

The key distinction

Think of the assertions as three separate questions:

Identity:

Who is this? Authority:

Who does this agent represent? Permission:

What exactly has that principal authorized this agent to do? OAuth is very good at the third question in a particular application context, and identity systems handle the first. Delegated-authority credentials are the infrastructure needed to make the second—and the relationship between all three—portable and independently verifiable.

There are already implementations moving in this direction. For example, Proof's Delegate Authority model issues a credential that binds a verified person, a specific agent, and a constrained scope; the verifier can cryptographically check all three at execution time. Proof Grantex is another emerging implementation focused specifically on delegated authorization for agents.

For a company, I'd make the delegation chain slightly richer:

Company → authorized representative → agent → sub-agent → action

with each hop able to attenuate authority but never expand it. That gives you something analogous to a digital power of attorney for software, with cryptographic verification, scope, expiration, revocation, and auditability.

If you're evaluating this as a product/infrastructure category, the concise name I'd use is Agent Delegated Authorization / Delegated Authority Infrastructure.

Yes. The infrastructure you’re describing is emerging as agent authorization / delegation infrastructure. It is slightly different from ordinary authentication or RBAC.

The core question is:

“Is this particular agent authorized to perform this particular action on behalf of this particular person/company, under these constraints?”

A good architecture has three layers:

1. Identity / authentication — establish who the principal is.

   • OpenID Connect is the standard layer for proving the identity of a human or service.
   • For organizations, you also need a trusted corporate identity/organization identifier.

2. Delegation / agent authorization — establish that Alice authorized Agent X to act for Alice, potentially with restrictions such as:

   • allowed actions
   • allowed resources
   • spending limits
   • duration
   • purpose
   • ability to delegate further
   • whether human approval is required

   GNAP (Grant Negotiation and Authorization Protocol) is an IETF standard specifically designed around delegated authorization to software clients acting for resource owners.

   There is also an emerging Agent Authorization Profile (AAP) for OAuth 2.0 aimed specifically at agent-centric authorization, including delegation chains and task/operational constraints.

3. Fine-grained authorization — once you know who the agent represents, determine what that agent can actually do.

   This is where Zanzibar/ReBAC-style infrastructure is useful. Zanzibar models relationships such as:

   Alice → owner → Company

   Company → member → Bob

   Alice → delegates → Agent X

   and can answer questions such as:

   “Does Agent X have permission to approve this invoice for Company Y?”

   Google's Zanzibar is the canonical example; it was designed as a globally consistent authorization system and evaluates relationship-based permissions at very large scale.

The important distinction

I would not build this as simply:

agent → OAuth token → API

The token proves that the agent has a credential. It doesn't necessarily prove the chain of authority:

Company → authorized person → delegated agent → requested action

For agentic systems, you want something more like:

Principal
  │
  │ owns / controls
  ▼
Organization
  │
  │ authorized
  ▼
Human / Principal
  │
  │ delegates
  ▼
Agent
  │
  │ requests capability
  ▼
Action + Resource

Then your authorization service evaluates:

WHO:       Agent X
ACTING FOR: Alice / Acme Corp
AUTHORITY: Alice delegated X
SCOPE:     "approve invoices"
RESOURCE:  Invoice #123
LIMITS:    <= $10,000
EXPIRY:    2026-09-01

Only if all those relationships and constraints hold does the API execute the action.

The IETF's current agent-authorization work explicitly distinguishes this from Zanzibar: AAP is about “what can this agent do, under what conditions, for what purpose?”, while Zanzibar/ReBAC answers “who can access what resource?”. They are complementary rather than competing approaches.

What I'd call the infrastructure

If you're evaluating this as a product/category, I'd look for:

• Delegated authorization / authorization servers
• Agent identity
• Verifiable credentials / claims
• OAuth 2.0 + GNAP
• Agent Authorization Profile (AAP)
• Fine-grained authorization / ReBAC
• Zanzibar-style authorization engines
• Capability-based authorization

For the authorization engine specifically, OpenFGA, SpiceDB/AuthZed, and similar Zanzibar-derived systems are relevant technologies. Zanzibar itself is the conceptual foundation.

So, in one sentence:

You need a delegated-agent authorization layer sitting between identity and fine-grained policy—essentially “OAuth/GNAP + verifiable delegation + Zanzibar/ReBAC,” with a cryptographically verifiable chain showing who the agent represents and what authority was delegated to it.

Verifying that an agent—whether a human proxy, an employee, or an autonomous software/AI agent—is authorized to act on behalf of a principal (person or company) requires a combination of cryptographic identity, delegated authorization protocols , and trust registries.

No single product solves this alone, but an interoperable technology stack known as Decentralized Identity (DI) and Verifiable Digital Credentials (VDCs) provides the underlying infrastructure.

The core architectural layers solving this problem include:

• Decentralized Identifiers (DIDs): Cryptographic, globally unique identifiers (based on W3C Decentralized Identifiers ) assigned to the principal, the agent, and the verifying party. A DID resolves to a public key document, allowing anyone to verify a digital signature without querying a central database.
• Verifiable Credentials (VCs): Tamper-evident, digitally signed electronic documents. The principal (or an authoritative issuer like an employer or corporate registrar) issues a credential to the agent that explicitly states: "This Agent DID is authorized by Principal DID to perform X actions, up to $Y value, until Date Z".
• Delegated Authorization Protocols: Standards modeled on or extending OAuth 2.0 and OpenID Connect—such as emerging frameworks like the Delegated Agent Authorization Protocol (DAAP) or UDAP Tiered OAuth —that pass cryptographically bound grant tokens during an interaction to prove active, scoped delegation.
• Trust Frameworks & Registries: Shared coordination layers or registries (sometimes anchored via secure ledgers or trusted domain lists like did:web ) that let verifiers instantly check if an issuer's signature is valid and whether a credential has been revoked in real time.

Would you like to explore how this applies to human delegation (e.g., power of attorney or corporate officers) versus autonomous AI agents , or look into specific implementation standards like OpenID for Verifiable Credentials (OID4VC)?

Yes. The infrastructure you’re describing is essentially delegated authorization + verifiable identity/credentials: a relying party needs to answer not merely “who is this agent?” but “who authorized this agent, what exactly are they authorized to do, and is that authority still valid?”

A useful architecture is:

Principal → Delegation credential → Agent identity → Verifier/resource server

Where the delegation is cryptographically signed and contains things like:

• Principal: the human or legal entity granting authority
• Agent: the specific agent/service identity receiving it
• Authority: permitted actions/resources
• Constraints: amounts, counterparties, geography, time, etc.
• Delegation chain: who delegated to whom
• Expiry/revocation: whether the authority remains valid
• Proof of possession: the agent proves it actually controls the authorized key

The standards stack

1. OAuth / GNAP — online authorization

OAuth is the established infrastructure for granting software scoped access to resources. For newer, more general delegation, GNAP (RFC 9635) is particularly relevant: it was explicitly designed to delegate authorization to software and convey the resulting authorization artifacts.

2. Rich Authorization Requests — express exactly what is authorized

OAuth RAR (RFC 9396) lets an authorization request carry structured, fine-grained authorization details rather than just "scope=write".

For example:

Principal: Acme Corp
Agent: agent-7f31
Authority:
  - create_purchase_order
  - maximum_amount: $10,000
  - vendors: approved-vendor-list
Valid: Aug 17–Aug 31

3. Verifiable Credentials — portable proof

W3C Verifiable Credentials provide a cryptographically verifiable way for an issuer to make claims about a subject. But importantly, the VC specification itself explicitly says it is not a complete authorization framework; authorization needs to be layered on top.

That makes a VC useful for answering:

“This agent/key is authorized by Acme.”

while an authorization system answers:

“This particular action is permitted under that authority.”

4. Agent identity + proof-of-possession

The agent needs its own cryptographic identity/key. The authorization should be bound to that key, so an attacker can't simply copy a bearer authorization and impersonate the agent.

What I'd build

If you're designing infrastructure for agents acting for people and companies across different systems, I'd model the core primitive as a verifiable delegation/mandate:

Delegation {
    issuer:     Principal
    delegate:   Agent
    authority:  Actions + Resources
    constraints: Policy
    valid_from: Timestamp
    expires:     Timestamp
    parent:      Optional parent delegation
    proof:       Issuer signature
}

Then give every agent a cryptographic identity and have the receiving service verify:

1. Is the principal legitimate?
2. Is the agent identity authentic?
3. Did the principal actually delegate to this agent?
4. Is the delegation signature valid?
5. Is it unexpired / unrevoked?
6. Does this requested action fall within the delegated authority?
7. If the agent delegated onward, is the child delegation <= parent's authority?

That last property—attenuation—is particularly important for agent-to-agent systems. Current work in the OpenID/IETF ecosystem is explicitly looking at preserving authorization context and narrowing permissions through delegation chains.

The interesting distinction

There are really three different infrastructure problems that often get conflated:

OAuth/GNAP are strongest for the authorization protocol and online enforcement. Verifiable Credentials are strongest for portable, cryptographically verifiable claims. You generally want the two together rather than trying to make a VC itself be the authorization system.

And this is becoming an active standards area specifically for AI agents: a July 2026 IETF Internet-Draft proposes composing OAuth Token Exchange, proof-of-possession, RAR, and CIBA into a credential-delegation framework for agents operating across multiple service providers.

In one phrase: you're looking for a “verifiable delegation infrastructure” or “agent authorization infrastructure.” The cryptographic object at the center is a delegation/mandate, not merely an identity credential.

If you're thinking about this as a product/company opportunity, there is an interesting gap between today's OAuth infrastructure and a universal “prove this agent is authorized to act for this principal” network.

Verifying that an autonomous or software agent is authorized to act on behalf of a human or a corporate principal requires Authenticated Delegation Infrastructure . No single legacy tool solves this entirely out of the box, but a modern architectural stack combines three interoperable layers:

• Decentralized Identifiers (DIDs): Cryptographic, globally unique identifiers that give an agent a first-class, verifiable digital identity separate from shared service accounts or human logins.
• W3C Verifiable Credentials (VCs): Tamper-evident digital containers (cryptographically signed by the principal) that explicitly encode delegated authority —defining what actions the agent can take, specific tool capabilities, boundaries, and expiration times.
• Extended OAuth 2.0 / Token Exchange / JWT Chains: Runtime protocols that bind the actor (the agent) to the subject (the human or corporate principal) so that downstream services can inspect a clear, unbroken delegation chain of accountability [1.17].

For closed enterprise environments, traditional enterprise Identity Providers (IdPs) (like Microsoft Entra ID or Okta) combined with short-lived OAuth tokens or mutual TLS (mTLS) can handle internal delegation. However, cross-organizational or autonomous agent-to-agent interactions increasingly rely on open standards like W3C Verifiable Credentials to prove provenance and scope dynamically.

If you're designing this for a specific use case, tell me:

• Is this for internal enterprise systems or cross-company/public interactions?
• What kind of actions will the agent be taking (e.g., API calls, financial transactions, data access)?

I can recommend a more specific architecture or protocol stack for your setup.

Verifying that an agent—whether human or autonomous AI—is authorized to act on behalf of a person or company requires Decentralized Identity (DID) and Verifiable Credentials (VCs) combined with a Delegation Framework.

Traditional tools like OAuth, API keys, or TLS certificates fall short because they are bound to sessions or domains, not to a portable, cryptographically provable chain of authority from a principal to an agent.

The modern infrastructure stack solving this problem relies on three core layers:

• Decentralized Identifiers (DIDs) : Cryptographic, globally unique identifiers owned directly by the person, company, or agent rather than a centralized identity provider. They anchor public keys and service endpoints without exposing personal attributes.
• W3C Verifiable Credentials (VCs) & Delegation Chains : Tamper-proof, cryptographically signed digital documents. The principal (human or corporate entity) issues a "delegation credential" to the agent's DID. This container specifies exact scopes, limits, and expiration dates.
• Digital Wallets and Resolvers : Secure client-side storage (like mobile or cloud wallets) where agents or individuals hold their VCs, alongside decentralized registries or web endpoints (e.g., using did:web did:web d i d:w e b or ledgers) that let verifiers instantly check an issuer's signature and real-time revocation status without calling back to a central database.

If you're designing a system for this, let me know:

• Is your use case for AI software agents or human representatives (like corporate procurement or medical proxies)?
• Do you need it to work strictly within an enterprise or across external organizations?

I can provide a deeper architectural blueprint or point you toward specific protocols.

Yes. The infrastructure you’re describing is essentially verifiable delegated authority for agents.

The key distinction is:

• Authentication: “This is Agent X.”
• Authorization: “Agent X is allowed to do Y.”
• Delegation: “Person/company P authorized Agent X to do Y on P’s behalf.”
• Verification: “A third party can cryptographically verify all three without simply trusting Agent X’s claim.”

The infrastructure

A good architecture looks like this:

genui{"data_networks_databases_learning_block":{"type_id":"BLOCKCHAIN_HASH_CHAIN"}}

1. Principal identity

• Person or company has an established identity.
• For companies, this can be tied to an organizational identity, signing key, or existing IAM/KYC relationship.

2. Agent identity

• Each agent gets its own cryptographic identity/keypair.
• The agent is not the person/company; it is an executor acting on their behalf.

3. Delegation credential / mandate The principal signs a machine-verifiable authorization saying something like:

Company A authorizes Agent X to submit purchase orders up to $50,000 to Vendor B, from Aug. 1–31, 2026.

The credential should encode who delegated, to whom, what actions, which resources, limits, validity period, and revocation status.

4. Delegation chains If Agent X delegates part of the job to Agent Y, Y receives a subordinate delegation. Critically, Y cannot acquire more authority than X possesses.

5. Verification gateway The receiving company/API doesn't ask, “Do I trust this agent?”

It asks a deterministic verifier:

Is Agent X → authorized by Company A → for this exact action → within scope → currently valid?

If yes, execute. If no, reject.

6. Audit + revocation Every consequential action should be attributable to:

Principal → delegation → agent → action

with the ability to revoke authority and prove what authorization existed at execution time.

What standards/products are converging on this?

This is becoming an active standards area rather than a solved commodity layer.

• AP2 (Agent Payments Protocol) has a particularly clear model: a user creates a signed Mandate, and an agent presents that mandate to a verifier when authorization for a concrete action is required.
• A2A handles agent-to-agent interoperability and relies on conventional authentication/authorization mechanisms such as OAuth, with authorization enforced by the receiving agent. It doesn't by itself solve the full “prove the human/company delegated this authority” problem.
• FIDO Alliance is explicitly working on “trusted delegation” and agentic authentication, including letting agents act without possessing the user's raw credentials and providing auditability and revocation.
• There are now dedicated protocols/products aimed directly at this missing layer, including Grantex and Ratify / identities.ai, both of which describe portable, cryptographically verifiable delegated authority.
• Google is also building enterprise infrastructure around agent identity, scoped human delegation, and an agent gateway for policy enforcement.

The important conceptual model

I would frame the primitive as “digital power of attorney for software agents.”

Not:

User → OAuth token → Agent

but:

Verified Principal ↓ signs delegation Delegation / Mandate ↓ Agent Identity ↓ presents proof Verifier ↓ Policy decision ↓ Authorized action

OAuth remains useful for accessing APIs. A2A/MCP can handle agent/tool communication. The missing trust layer is the portable, verifiable delegation artifact that answers “who gave this agent authority to do this?”

That distinction becomes especially important when the agent crosses an organizational boundary. The receiving party shouldn't have to trust the agent vendor, the agent's database, or the agent's assertion that “my user told me to do this.” It should be able to verify the authority itself.

If you're thinking about this as an infrastructure/product opportunity, the verifier + delegation registry/credential layer is arguably the interesting piece, rather than another agent protocol.