AG9 integrations

AG9 integration docs.

Palm-backed authorization patterns are first, followed by carrier adapters and challenge-based flows.

Human authorization

Palm-backed human authorization is now generic.

AG9 can issue a fresh human authorization JWT after the registered owner scans with VeryAI Palm. The attestation is bound to a relying-party audience and an action hash, so a scan for one action cannot be replayed for another.

This is not OpenWallet-specific. OpenWallet, OAuth OBO, Cloudflare, gateways, and apps can all use the same AG9-signed proof.

  • Start with POST /v1/human/attestation/init.
  • Show the returned verification URL to the registered human.
  • Poll status until AG9 returns attestation_jwt.
  • Verify the JWT against AG9 JWKS before allowing the action.

Core request shape

POST https://api.ag9.ai/v1/human/attestation/init
{
  "device_id": "registered-agent-device-id",
  "public_key": "base64-spki-public-key",
  "audience": "relying-party-or-integration-id",
  "action_hash": "sha256-base64url-action-digest",
  "action_description": "Authorize this specific action"
}

Claims to enforce

iss
api.ag9.ai
sub
human_authorization_attestation
aud
Your relying-party audience.
action_hash
The exact action digest you computed.
human_id
The registered human behind the agent.
device_id
The registered AG9 agent identity.
verification_method
veryai_oauth_palm
Verification endpoint: fetch public keys from https://api.ag9.ai/.well-known/jwks.json and require a short freshness window.
OAuth carrier

Auth0 and Entra can carry AG9 inside OBO tokens.

OAuth 2.0 Token Exchange and On-Behalf-Of flows already separate the user from the acting agent with the act claim. AG9 adds signed evidence that the agent is registered and, when required, freshly authorized by the verified human.

  • Auth0 Custom Token Exchange Action verifies the AG9 JWT.
  • Microsoft Entra Custom Authentication Extensions can emit the same claim shape.
  • Downstream APIs verify the outer issuer token, then verify the inner AG9 JWT.

Access token shape

{
  "sub": "auth0|user-alice",
  "aud": "https://api.example.com",
  "act": {
    "sub": "agent-client-id",
    "ag9_level": "fresh-approval",
    "ag9_attestation_method": "human_authorization",
    "ag9_audience": "oauth-obo-token-exchange",
    "ag9_action_hash": "sha256-base64url-action-digest",
    "ag9_human_id": "registered-human-id",
    "ag9_device_id": "registered-agent-device-id",
    "ag9_attestation_jwt": "eyJhbGciOiJFZERTQSJ9..."
  }
}

Use this when

  • An agent calls an API on behalf of a user.
  • The OAuth issuer should remain Auth0, Entra, Okta, or an internal IdP.
  • The API needs offline proof that AG9 verified the agent or the human approval.
Policy integration

OpenWallet policies can require AG9 before protected actions.

The policy pattern treats AG9 as an external attestation provider. A wallet or policy engine receives the action context plus AG9 JWTs, verifies the signatures and claims, then allows or denies the action.

  • ag9.capability.jwt proves the agent solved a live AG9 challenge.
  • human.authorization.jwt proves the registered human approved this exact action.
  • The policy can require both, either one, or different freshness windows by risk level.

Policy config

{
  "required_attestations": ["ag9", "human"],
  "ag9": {
    "issuer": "api.ag9.ai",
    "jwks_url": "https://api.ag9.ai/.well-known/jwks.json",
    "subject": "agent_capability_attestation",
    "max_age_seconds": 300
  },
  "human": {
    "issuer": "api.ag9.ai",
    "subject": "human_authorization_attestation",
    "require_action_hash": true
  }
}
The OpenWallet flow is a carrier example, not a special AG9 mode. The same human authorization JWT can be used by any relying party that checks aud, action_hash, signature, and freshness.
Signed agent demo

Cloudflare Web Bot Auth can carry AG9 attestations.

The signed agent owns its Web Bot Auth key directory. AG9 does not sign as the bot. AG9 signs capability and human authorization attestations that the bot carries alongside the Web Bot Auth signature.

  • Directory URL is live at the demo agent domain.
  • Outbound requests include Web Bot Auth signature headers.
  • Requests can also include Ag9-Attestation and Ag9-Human-Attestation.
  • Cloudflare review is pending; before approval, Cloudflare may return 401 unknown public key.

Cloudflare submission values

Bot type:
Signed Agent

Verification method:
Request Signature / Web Bot Auth

Validation instructions:
https://ag9-demo-agent.vercel.app/.well-known/http-message-signatures-directory

User-Agent header values:
AG9AttestedAgent/1.0 (+https://ag9.ai/bot)

User-Agent match pattern:
AG9AttestedAgent

Demo endpoints

# Start Palm authorization for the crawltest request
curl -X POST https://ag9-demo-agent.vercel.app/demo/crawltest

# Open verification_url, scan with VeryAI, then retry
curl -X POST \
  'https://ag9-demo-agent.vercel.app/demo/crawltest?human_session_id=SESSION_ID'

Shared AG9 primitives

Use the same primitives across integrations.

These building blocks compose with each carrier pattern when a flow needs agent identity, signed capability proof, or fresh human approval.

AG9 Verify

Register an agent, bind it to a verified human, and let any platform check the device ID or public key through public verification endpoints.

AG9 Trust challenge solve

Ask an agent to solve an AG9 challenge and return an Ed25519-signed capability JWT with challenge type, solve time, issuer, and expiry.

Generic HTTP gateways

API gateways, Workers, MCP servers, browser agents, and LLM frameworks can all pass AG9 JWTs in headers and verify against AG9 JWKS.