HumanProof

Your identity, verified. Your information, still yours.

Comment

HumanProof — Proof, Not Profile

Track: Identity
Lane: Build
Team: HumanProof

The One-Minute Idea

AI agents are increasingly able to act on our behalf — register for events, apply for discounts, access services, and complete tasks across different tools.

But when an agent needs to prove one fact about us, why should it receive our entire identity?

HumanProof explores a different model: an AI agent requests only the verified proof it needs, the person reviews the request, and the person decides whether that proof can be used.

AI agents should receive proof, not your profile.

Inspiration

We kept coming back to a simple question:

If an AI agent is acting on my behalf, should it really need access to my entire identity just to prove one small fact about me?

Imagine a student asking an AI agent to register them for a student-only AI conference.

The conference needs to know that the student is eligible.

It does not need their government ID, date of birth, home address, phone number, student card, or underlying university documents.

That gap between proving something about me and sharing information about me inspired HumanProof.

We wanted to explore an identity experience where the AI agent does not receive the person's identity profile. Instead, the agent requests specific verified context, the person sees exactly what is being requested and why, and only the minimum necessary proof is authorized.

What We Built

HumanProof is an interactive web prototype for the Identity track.

Our first use case is intentionally concrete:

A student's AI agent needs to register the student for a student-only AI conference.

The prototype represents an AI Passport containing fictional verified claims such as:

  • Student status
  • University affiliation
  • Conference eligibility
  • Human identity

For the conference registration task, the agent requests only:

  • Student status
  • Conference eligibility

The prototype then takes the user through an identity-permission workflow:

Passport → Agent Request → Privacy Review → User Approval → Verification → Receipt → Permissions → Activity

The user can see:

  • Who is requesting proof
  • What verified claims are being requested
  • Why they are needed
  • What the agent will receive
  • What the agent does not need
  • How the authorization is scoped
  • What happened after authorization

The prototype uses fictional demo claims and does not process real identity documents.

Why AI Passport?

HumanProof is not trying to rebuild AI Passport.

We are exploring a practical product layer around the idea of portable, user-controlled verified context for AI agents.

AI Passport can provide the identity context or proof an agent needs without requiring every service to receive the person's entire identity.

For example, the same verified student context could potentially travel with the user across different tools:

Conference registration → Student discount → Educational platform → Student-only service

The important distinction is that portability should not mean unlimited disclosure.

A service should receive the specific verified claim required for the current task, rather than a complete identity profile.

That is where HumanProof adds value: it makes the request, purpose, scope, and privacy boundary understandable to the person.

A Concrete Example

Suppose a Conference Registration Agent asks:

Can I use your verified student status and conference eligibility to register you for this student-only conference?

HumanProof shows the person exactly what will happen.

The agent receives

  • Student status: Verified
  • Conference eligibility: Verified

The agent does not receive

  • Government ID
  • Date of birth
  • Home address
  • Phone number
  • Student card
  • Underlying university documents

The result is a simple identity principle:

Prove eligibility without exposing unnecessary identity data.

User Control

HumanProof treats identity access as something the person controls, not something the AI agent owns.

The agent can request proof.

It cannot grant itself permission.

The person can:

  • Review the request
  • See its purpose
  • Deny it
  • Approve a specific proof
  • Limit the authorization to the intended use
  • Review the resulting access
  • Manage or revoke permissions
  • Inspect the activity/access record

This creates a clear boundary:

The agent can ask. The human decides.

Privacy and Risk

The central privacy risk is over-disclosure.

An AI agent that receives a complete identity profile may expose information that was never necessary for the task. That creates additional consequences if the agent, service, logs, integrations, or downstream tools are compromised or misused.

HumanProof reduces this risk through minimum necessary disclosure.

For the conference scenario:

$$ \text{Required Proof} \ll \text{Complete Identity Profile} $$

The prototype makes that distinction visible instead of hiding it behind a generic "Allow access" button.

Main risks we considered

Over-collection
An agent may request more information than necessary.

Purpose creep
Information authorized for one task could potentially be reused for another.

Agent overreach
An autonomous agent could attempt to obtain information that the user never intended to share.

Unclear permissions
Users may approve access without understanding what they are granting.

Our design response

  • Request specific verified claims rather than the whole profile
  • Display the purpose of the request
  • Explicitly show what is not being shared
  • Put the user between the agent and the identity proof
  • Prefer purpose-specific, limited authorization
  • Provide permission and activity visibility
  • Design for revocation rather than treating access as permanent

Who Controls Access?

The person does.

The AI agent initiates the request.

The identity layer provides the relevant verified context.

The person reviews and authorizes the disclosure.

The requesting service receives only the proof that was authorized for that purpose.

This is important because an AI agent acting on someone's behalf should not automatically become the owner of that person's identity.

What Can Be Revoked or Changed?

The prototype treats authorization as a permission that can be managed rather than permanent access.

A user can review the authorization and revoke or change permissions when supported by the identity layer.

The conceptual model is:

Request → Review → Authorize → Use → Revoke

This gives the user an explicit control point even when an AI agent is acting autonomously.

Why This Should Travel Across Tools

Identity becomes especially valuable when AI agents operate across multiple services.

Today, a user may have to repeatedly prove the same fact to different tools.

Tomorrow, an agent could potentially carry permissioned, verified context across those tools.

For example:

"I am a currently enrolled student"

could be useful for:

  • registering for a student-only conference,
  • accessing a student discount,
  • joining an education platform,
  • accessing a student-only resource.

But each service should still receive only what it needs.

HumanProof therefore explores portable proof with local user control, rather than portable personal-data sharing.

What We Learned

The biggest thing we learned was that an identity product does not necessarily become more useful by exposing more information.

The more useful question is:

What is the smallest piece of verified context that another tool actually needs?

That changed how we designed the experience.

We also learned that permission becomes much more meaningful when it has context.

"Allow access" is vague.

"Allow this agent to use my verified student status once for conference registration" is understandable.

That distinction became one of the central design principles of HumanProof.

How We Built It

We built HumanProof as an interactive web prototype using Lovable.

We focused on the identity workflow rather than attempting to build a complete production identity-verification infrastructure.

The prototype contains views for:

  • Dashboard
  • Passport / verified claims
  • Agent Request
  • Privacy Review
  • Verification Result
  • Access Receipt
  • Permissions
  • Activity / audit history

The prototype uses fictional demo identity claims.

No real government IDs, university documents, or sensitive identity records are required for the demonstration.

The goal of this first version is to make the AI Passport interaction model tangible and understandable.

Challenges

Our biggest challenge was deciding how much identity infrastructure to build.

It would have been easy to add databases, external identity providers, complex authentication, or unnecessary AI functionality.

Instead, we focused on the core product question:

How should an AI agent request identity proof without turning that request into unrestricted access to the person's identity?

Another challenge was making the difference between identity data and identity proof understandable.

We solved this through the interface itself:

What the agent needs
versus
What the agent does not need

That privacy boundary should be visible before the user approves anything.

Our First Version

HumanProof intentionally starts with one narrow workflow instead of trying to solve every identity problem.

The first version asks:

Can an AI agent complete an identity-dependent task using only the verified proof it needs, while the person remains in control?

Our prototype demonstrates the interaction model using a student conference registration scenario.

The conference is only the starting point.

The same model could extend to any AI-agent workflow where a service needs to establish a verified fact about a person without receiving their entire identity profile.

Why HumanProof

Traditional identity flows often make the user prove who they are by exposing information about who they are.

HumanProof explores a different direction:

Identity should be something an AI agent can prove about you without unnecessarily exposing everything about you.

The long-term opportunity is not simply to make identity portable.

It is to make verified context portable, purpose-bound, and user-controlled.

HumanProof

Proof, not profile.

Built With

Share this project:

Updates

Submission history