Proofenance Agentic Identity
Know who's really in the chat
Our MCP server lets you identify and verify users inside AI conversations, so you get real people, not bots, with proof you can trust and a token you can validate.
Why identity in AI chat actually matters
When someone buys, signs up, or does anything meaningful inside an AI chat, you need to know they're a real person. Fake emails, throwaway numbers, and bots are everywhere. We built a system that ties the chat to verified identity: email and phone confirmation, document-based checks, and a signed identity token your systems can validate. No more "trust me, I'm human." You get proof.
What is MCP? The Model Context Protocol explained
MCP stands for Model Context Protocol. It's an open protocol that lets AI applications (your chat client) talk to external services (like our identity server) in a standard way. Instead of every product inventing its own way for the model to call APIs or run tools, MCP defines how tools are discovered, called, and how results flow back into the conversation.
MCP server
A service that exposes tools (callable functions the AI can invoke). Our MCP server exposes tools like verify_identity (start a verification) and get_identity_status (check status and get the identity token). The server runs at https://mcp.proofenance.com; you connect with your key and secret.
MCP client
Your AI chat app or agent. It connects to one or more MCP servers, discovers their tools, and when the model decides the user needs to be verified, it calls our tool. The client sends the request, gets back the verification link or status (and eventually the identity JWT), and feeds that into the next turn of the conversation. One integration gives your agent the ability to verify users without building your own identity stack.
So MCP isn’t just “an API”; it’s the standard layer between the brain (the LLM) and the world (identity, data, and more). We run an MCP server so your agent can trigger verification and receive a signed identity token in the same flow where the user is chatting. For a full deep dive on MCP, agentic AI, and commerce, Tobin wrote an interesting article.
How we verify: email, phone, and real identity
We use a layered approach so you can choose the right level of assurance for your use case, from lightweight contact confirmation to full document-based identity verification.
Email confirmation
The user receives a link at the email they give in chat. They may be directed outside the chat to open it; after completing the step they are redirected back to the chat, or they can complete verification asynchronously and return to the conversation later. Until they complete that step, they're not verified. Simple, fast, and already blocks a lot of casual abuse and fake signups.
Phone number confirmation
We send an SMS to the number the user gives. They can either tap a link in the message or enter the code sent the same way directly into the chat (handy with "insert from SMS" on devices). That ties the session to a number they control and makes it much harder for bots or throwaways to pass.
Real identity verification
For higher stakes (compliance, high-value transactions), we support full document-based identity checks. The visitor must upload documents in the browser so we can ensure accuracy and avoid AI mishandling of sensitive data. Once done, they're returned to the chat. That real identity is then reflected in the token you receive.
The user may be directed outside the chat for some steps (e.g. opening an email link or uploading documents in a browser). They are redirected back to the chat after completing the flow, or can complete verification asynchronously and return to the conversation later. All of these methods can be completed asynchronously; the same user, sub, and personId are persisted. If your backend later requests identity using the identity JWT (or personId) after the user has provided more information, we return an updated token with the extra data.
The identity token: what you actually get
When a user is verified, we issue a signed identity JWT that encodes the confirmed identity elements. It is available in two ways: in the AI chat, so the conversation context has the verified identity data (e.g. from the get_identity_status MCP tool response), and via the Proofenance API, so your backend can make requests using the personId (the sub in the identity JWT). You get that personId when you start the identity check and again in the token once verification is complete, so your backend can use it to retrieve or validate identity through our API.
Your backend or AI pipeline can read and validate the token (e.g. with our JWKS) so you never have to trust the chat client alone.
Identity JWT claims (when verification is complete)
- sub: Person ID (stable identifier for the verified person in our system)
- aud: Audience; set to your account's company name
- given_name / family_name / name: Verified name from identity check
- birthdate: Date of birth when provided and verified
- address: Verified address (street_address, locality, postal_code, country)
- identity_verified_at: Unix timestamp when identity (name/address) was verified
- email: The verified email address
- email_verified_at: When the email was last verified
- phone_number: The verified phone number
- phone_number_verified_at: When the phone number was last verified
- Custom claims: Key-value pairs added to the token as defined in your API call when requesting the identity status (e.g. internal IDs, roles)
The token is signed with RS256. You validate it using our public JWKS; no shared secret with us required on your side.
Setting up and connecting the MCP to your company
Our MCP is secure and requires your Proofenance account to enable Proofenance Agentic Identity. We issue credentials you can use to authenticate your AI chats with your Proofenance account.
1. Create MCP credentials in Proofenance
In your Proofenance company account (dashboard or account settings), create an MCP access key. You get a key and a secret, and optionally a short-lived Bearer JWT for that key. The key and secret are long-lived until you revoke them; the JWT is handy for clients that prefer Bearer auth and can be refreshed when needed.
Behind the scenes, our API talks to the MCP server to create the key and store it securely. You never run the MCP server yourself; we host it at https://mcp.proofenance.com.
2. Point your AI chat (MCP client) at our server
Configure your AI chat app or MCP client with:
- URL:
https://mcp.proofenance.com(MCP protocol at the root, no path prefix) - Auth: Either HTTP Basic (username = key, password = secret) or Bearer (Authorization: Bearer <JWT>). Most clients support Basic auth out of the box. Use the key as username and the secret as password.
Once connected, the client can call our MCP tools (e.g. start verification, get identity status). Each conversation can then go through the verification flow; when the user completes it, you get back a session identifier and, when ready, the identity JWT.
3. Run the verification flow in chat
Your AI triggers Proofenance's verify_identity tool (or equivalent) to start a verification. You choose which aspects to verify; the user completes each step. All methods can be done asynchronously and the same personId is persisted throughout.
- Email:The user may be directed outside the chat to open the link; after completing the step they are redirected back to the chat, or they can complete verification asynchronously.
- Phone:Proofenance sends an SMS. The user can tap a link in the message or enter the code directly into the chat (e.g. via "insert from SMS" on devices).
- Documents:For full identity checks, the user uploads documents in the browser for accuracy and to avoid AI mishandling; once done, they are returned to the chat.
When the user has completed the required steps, your app calls the MCP tool get_identity_status (an AI tool name your client invokes, not a REST or GraphQL endpoint; using the same MCP auth as your account). When status is complete, the response includes the identity JWT and the verified identity payload. If the user later adds more information, a later request returns an updated token with the extra data.
That token is available in the AI chat context so your agent has the data, and the personId (sub) in the token (or returned when you started the check) lets your backend call the Proofenance API to retrieve or validate identity.
Retrieving and validating identity: in the chat and in the backend
The identity JWT is available in the AI chat context (from the get_identity_status MCP tool response) so your agent has the verified identity data. Your backend can also retrieve and validate identity using the Proofenance API with the personId (sub) returned when you start the check or from the token. Always verify the token signature with our JWKS before trusting claims.
In the AI chat
The identity JWT is returned in the response from the get_identity_status MCP tool (an AI tool name, not a REST or GraphQL endpoint), so it is available in the chat context. Your agent can use the decoded claims (name, email, phone_number, sub, etc.) for the conversation and for any in-chat logic without calling your backend first.
In your backend (Proofenance API)
Your backend can use the personId (the sub in the identity JWT) in requests to the Proofenance API. You get this personId when you start the identity check and again in the token once verification is complete. Use it to fetch or validate identity server-side. Validate any identity JWT you receive using our JWKS before trusting its claims.
How to use the token
After you receive the identity JWT (e.g. in the response from the get_identity_status MCP tool), you can pass it to your backend. Decode and validate the signature using our public key (JWKS). Then read sub, given_name, email, phone_number, identity_verified_at, etc., for access control, compliance, or personalization.
Validating the token with our JWKS
We publish a JWK Set at:
https://proofenance.com/.well-known/jwks.json
Use any JWT library that supports JWKS (e.g. fetch the JWKS, resolve the key by kid, then verify the token with RS256). Ensure iss is https://proofenance.com and aud (audience) is your account's company name. Once signature and claims are valid, the token is real and the identity claims are trustworthy.
Open identity standards and claims
Our identity JWT is built on open standards so you can validate it with standard libraries. The token format and registered claims follow JWT (RFC 7519); public keys are exposed as a JWKS (RFC 7517). Many identity claims (e.g. sub, name, given_name, email, address) align with OpenID Connect Core 1.0 Standard Claims. We add verification-specific claims (e.g. identity_verified_at, phone_number_verified_at) on top. For full claim definitions, see the JWT registered claim names and the OpenID Connect Core 1.0 spec.
Benefits of using our system
You get a single, standards-based way to bring verified identity into any AI chat, without building your own verification stack or trusting unverified user input.
Bot-proof by design
Verification requires real data: a real email click, a real phone check, or real document upload. Bots can't pass without controlling those channels.
Cryptographically signed tokens
Identity is encoded in a JWT signed by us. You validate with our public JWKS. No shared secrets; industry-standard and auditable.
Built for agentic AI
MCP fits right into AI agents and chat products. Start verification from the conversation and get the identity token back when the user completes the flow.
Know the real user
For ecommerce, compliance, or high-value actions, you get verified name, address, and contact details, not just a nickname in the chat.
One integration, many use cases
Same MCP server and token format for support bots, sales chats, agentic ecommerce, and internal tools. Configure once per company.
Audit trail
Verification events and token issuance are tied to your company and person records in Proofenance, so you have a clear trail for compliance and support.
Who is this for? Use cases for identity in AI chat
Any product where an AI or chat interface leads to a high-value action (purchase, signup, sensitive operation) benefits from verified identity. Here are the main patterns we see.
AI-native stores & sales bots
You sell in chat or via an AI agent. Before shipping goods or allowing high-value actions, you need to know the user is real. Our MCP tools let the agent trigger verification in the same conversation and receive the identity token for your backend.
Support & account recovery
Chatbots that reset passwords, change contact details, or unlock accounts should verify the user first. Email/phone or document verification via MCP keeps support flows secure without sending users to a separate portal.
Regulated & high-value verticals
Art, luxury, financial services, or any sector with KYC/AML requirements. Agentic interfaces still need to prove who the user is; the identity JWT gives you an auditable, JWKS-validated claim for compliance.
Internal tools & agents
Internal AI agents that book travel, approve expenses, or access sensitive data can gate actions on verified identity. Same MCP server and token format; configure once per company and reuse across use cases.
Marketplaces & two-sided platforms
When buyers and sellers interact via chat, verifying both sides reduces fraud and builds trust. Each party completes the flow; you get separate identity tokens so you know exactly who is on each side of the transaction.
Conversational onboarding
Onboarding flows that run inside a chat (e.g. “Tell me about your business”) can require identity verification before granting access. Trigger verification via MCP, get the token, then continue the conversation with a verified user.
Frequently asked questions
Security and trust: how we keep the token safe
The identity JWT is signed with our private key (RS256); only our public key can verify it. We publish the public key in a JWKS so you can validate tokens without ever sharing a secret with us. That means:
- Tamper-proof: If someone changes a claim (e.g. name or email), the signature fails and you reject the token.
- Issuer-guaranteed: Only Proofenance can produce a token that validates against our JWKS, so you know we issued it after a real verification.
- No shared secrets: You don’t store or exchange a secret with us for identity; you only need our public key, which you can cache and refresh from the JWKS URL.
Always validate the token on your backend before trusting any claim. Never rely on the raw token string from the client without verifying the signature first.
Want the full picture? Read our in-depth article
We’ve published a long-form guide on MCP, agentic AI, agentic ecommerce, and why verified identity is the missing piece. It covers tokens, JWKS validation, integration patterns, and compliance in one place.
MCP, Agentic AI Commerce & Verified Identity: full guideIntegrate with our API and docs
Credentials are created and managed via the Proofenance app and our GraphQL API (e.g. createMcpAccessKey, getMcpCredentials). For the full identity API (starting verification, checking status, receiving the identity JWT), see our API reference. We document endpoints, request/response shapes, and how to pass the identity token into your own services.