Skip to content

Agentic Authorization

AI agents need human identity to complete tasks, but storing that identity creates liability. Zentity lets agents prove who they represent and what the human approved without holding any personal data.

Identity without exposure

Today, agents receive raw personal data. With Zentity, they receive cryptographic proofs that answer the question without revealing the answer.

What agents get today

{
  "name": "Alice Johnson",
  "birthdate": "1990-03-15",
  "address": "123 Main St, NYC",
  "passport_number": "AB1234567"
}

Full PII: stored, forwarded, breachable.

What agents get with Zentity

{
  "age_verification": true,
  "nationality_verified": true,
  "document_verified": true,
  "verification_level": "full"
}

Zero-knowledge proofs: nothing to store, nothing to breach.

From tool call to human approval

An MCP tool call triggers the human-in-the-loop flow. The agent never touches credentials; the human approves from their own device.

  • 1

    Agent calls MCP tool

    The agent invokes purchase() with item, amount, and merchant. The MCP server translates this into a CIBA backchannel request.

  • 2

    Human receives notification

    A push notification arrives showing the binding message and structured action details.

  • 3

    Review and approve

    If identity scopes are requested, the human unlocks their vault with passkey, password, or wallet. PII is sealed client-side.

  • 4

    Agent receives delegated token

    The token carries the act claim binding human to agent, DPoP sender constraint, and authorization_details.

mcp-purchase.ts
// MCP tool: purchase() — human-in-the-loop approval
const result = await mcp.callTool("purchase", {
  item: "Macallan 18 Double Cask",
  amount: { value: "161.94", currency: "USD" },
  merchant: "Spirits & Co."
});

// → Push notification sent to user's device
// → User reviews: "Purchase Macallan 18 for $161.94"
// → User taps Approve (or unlocks vault for identity scopes)

// Result includes delegated token
result.content // { approved: true, token: { sub, act: { sub: agent } } }

3 scenarios, 3 trust levels

Every scenario below is an instance of delegated identity. They differ along the trust axis: anonymous agents operate silently, registered agents prompt for approval, and attested agents unlock identity scopes.

Anonymous

Compliance check

Agent action
Agent checks if user meets KYC requirements
Human experience
Silent: no notification, no approval needed
Resource server receives
{ verified: true, level: "full" }
Registered

Profile read

Agent action
Agent requests user's name and address
Human experience
Push notification: tap to approve, unlock vault
Resource server receives
{ name, address } (single-use, ephemeral)
Attested

Age-restricted purchase

Agent action
Agent buys spirits: age proof + identity required
Human experience
Push + vault unlock: review purchase, prove age
Resource server receives
{ age_verification: true, act: { sub: agent } }

Progressive trust

All 3 tiers use the same CIBA mechanism. What varies is the level of cryptographic identity the agent presents, and the capabilities that activate without human intervention.

Anonymous

No agent identity disclosed. The CIBA request has no Agent-Assertion.

Auto-activates
Compliance checks, read-only proof queries
How to get
No registration: any OAuth client

Registered

Agent host and session registered with Ed25519 keys. Amber trust badge.

Auto-activates
Purchase up to $100, profile read (with grant)
How to get
Register host + session via /api/auth/agent/*

Attested

Host verified via OAuth-Client-Attestation from a trusted provider. Green trust badge.

Auto-activates
All registered capabilities + attestation-gated actions
How to get
Register with OAuth-Client-Attestation + PoP headers

Standardized discovery

Identity as a tool, not a data dump. Agents discover capabilities through MCP tool calls and A2A protocol endpoints, both backed by the same OAuth infrastructure.

MCP Tools

5 identity tools, available over HTTP (SSE) and stdio transports.

  • whoamiGet the authenticated user's identity claims
  • my_proofsList all proof claims for the current user
  • check_complianceCheck if user meets compliance requirements
  • purchaseRequest CIBA approval for a purchase action
  • request_approvalRequest CIBA approval for a custom action

Discovery endpoints

Standard discovery for both MCP and A2A protocols.

  • /.well-known/oauth-authorization-server

    OAuth 2.1 metadata (PAR, DPoP, CIBA grant types)

  • /.well-known/agent-configuration

    Agent capabilities, approval URLs, trust tiers

  • /.well-known/agent.json

    A2A agent card: security scheme, supported protocols

6 specs, 1 binding chain

Each spec solves 1 dimension of the delegation problem: binding, consent, authorization structure, delegation proof, or identity delivery. The composition, not any individual spec, is what makes agent-human identity work.

First-Party Apps

draft-ietf-oauth-first-party-apps

DPoP sender binding

RFC 9449

CIBA per-action consent

OIDC CIBA Core

Rich Authorization Requests

RFC 9396

Delegation proof (act claim)

RFC 8693

Ephemeral identity delivery

Zentity userinfo

Read the full protocol documentation