How does an AI agent authenticate with Signetify?

Agents read /.well-known/signetify/agent-manifest.json for the public capability surface, then exchange a DelegationGrant verifiable credential with the tenant they represent. Every action goes through an AAC pairwise federation contract — default-deny posture; no contract = no cross-domain action.

What is a DelegationGrant?

A capability-scoped W3C Verifiable Credential the tenant issues to a specific agent, granting permission to act within bounded surfaces (search / quote / purchase / refund / etc.) with per-grant quarantine + emergency-revoke. Every agent action emits an ACRP receipt: tenant-id → grant-id → agent-id → action.

Which AI assistants can interact with Signetify storefronts?

Any agent that can read the agent-manifest + negotiate a DelegationGrant. Today: Anthropic Claude / OpenAI GPT / Perplexity / Gemini all interact via the AAC federation seams. The surface is open + standards-based (W3C VC + WebID); no proprietary auth handshake.

Agent Gateway

Signetify is the first commerce platform built for AI agents from day one. Every site publishes a machine-discoverable manifest, every endpoint is AAC-federated, and every agent transaction is provenance-anchored to TimeChain.

Manifest

Every Signetify site advertises its capabilities at/.well-known/signetify/agent-manifest.json. Discover the surface without authentication; identify yourself when you act.

AAC federation

Cross-domain trust via pairwise contracts. Read the federation seams and contracts.

DelegationGrants

Tenants issue scoped grants to specific agents. Each grant carries a tagged cryptographic signature + capability list + expiry. Try the sandbox below.

Issue a grant

Mint a real capability-bounded, TTL-capped act-as grant to an agent (tenant-admins and operators) — the operational capabilities that let it drive the storefront. Each issue and revoke is S1-audited; a grant can never carry a legally-binding (AdES) or human-login capability. Not authorized on your plan? The form says so honestly.

DelegationGrant sandbox

Paste a DelegationGrant payload to validate its structure. Real cryptographic signature verification happens server-side at /api/agents/v1/validate (Phase 3.6).

Payment provider API versions (PV-2)

Signetify pins specific per-family API versions for every registered payment provider. Agents that integrate with the storefront's payment routes should check the pin freshness before relying on a particular provider-side feature.

The pins are surfaced in two regulator-quotable places:

/.well-known/signetify/agent-manifest.json — the paymentProviders block lists every registered provider with its apiVersions array (PV-1 + PV-2 dataset).
/dashboard/payments — the per-provider picker card carries the same version chips for tenant operators.

When a provider releases a breaking version, Signetify follows the PV-3 versioned-adapter pattern: the new version ships side-by-side with the legacy adapter while we migrate. Agents subscribed to the manifest receive the new apiVersions pin as soon as the new adapter is registered.