WebMCP Identity and Reputation Layer

• 

  Identity & Reputation Layer

Inspiration

I am relying more and more on AI and agents to automate everyday tasks. As that automation grows, and as LLMs become increasingly capable of processing and acting on information, websites have also increased the barriers they use to protect themselves from bots and malicious scrapers.

The problem is that these same protections can also block legitimate agents. Agents acting on behalf of a real user with a real task to complete.

That tension is what led me to this idea: how can a website welcome a legitimate agent without opening the door to every anonymous scraper?

What it does

WebMCP Identity & Reputation Layer creates a reputation profile and an auditable action history for each agent.

Every interaction is recorded as an AuditEvent: a traceable event containing the agent identity, the tool that was invoked, the result, the reputation delta applied, and the resulting score.

With this history, a website can apply different interaction limits to different agents. Instead of using one generic rate limit for everyone, it can adjust the limit based on the trust that each agent has accumulated over time.

Authentication works through an email OTP handshake verified through WebMCP. The agent requests a code, the server generates and sends it, and the agent handles the OTP then the agent receive an active session.

That handshake is the entry point. The reputation and audit system is the core of the project. It is what allows the website to continuously evaluate how much trust it should place in an agent over time.

For this prototype, I am using a limited set of controlled identities to validate the trust engine end-to-end before tackling the larger question of how to scale the identity registry (see What's Next).

How we built it

I built the prototype using WebMCP, Next.js, and Resend.

The authentication flow uses an OTP orchestrated through WebMCP. Resend handles the OTP delivery between the server and the agent.

The project exposes four WebMCP tools through document.modelContext:

authenticate_agent, Runs the two-step authentication flow: requesting and verifying the OTP. Each step is recorded as its own AuditEvent. get_agent_profile, Returns the agent's identity, reputation score, and current rate-limit status. perform_demo_action, Executes an authenticated action on the website (catalog search), subject to the agent's current rate limit. Every execution is recorded as an AuditEvent and contributes to the reputation score. get_agent_history, Retrieves the chronological, auditable history of the AuditEvents generated by the previous tools.

Challenges we ran into

The biggest challenge was building a functional authentication flow between an agent and WebMCP in a short amount of time, especially since WebMCP was a technology I had not worked with before.

It also wasn't enough for the flow to simply work. I needed to make the trust model visible and easy to demonstrate: the service provider should be able to see the agent's profile and, based on its history, determine how many interactions that specific agent should be allowed to perform.

Accomplishments that we're proud of

I was able to build a basic but complete flow that demonstrates something concrete: it is possible to add an authentication and trust layer where the backend dynamically adjusts the number of interactions an agent is allowed to perform based on its profile, rather than applying the same fixed limit to every agent.

What we learned

I learned more about the potential of WebMCP as a complementary layer for websites.

One thing that surprised me is that WebMCP doesn't have to be about choosing between agent interaction and human interaction. It creates a middle ground where both can participate in the same workflow.

I also learned that, while there are already many authentication solutions available, the specific problem of agent identity and reputation still does not have an established standard.

That makes this an interesting piece of open ground.

What's next for WebMCP Identity and Reputation Layer

My next steps are to strengthen the authentication layer toward a 2FA approach that can meet compliance requirements, while continuing to develop the per-agent identity and reputation system, which is the central part of the project.

There is also a bigger question I have not fully solved yet:

Should a centralized provider manage agent identity and reputation, or should this information live in a public and auditable registry? And what about the data involved? I don't want to enable social engineering attacks based on a complete behavioral trail left by an agent. So, should the system be 100% public, 100% private, or a combination of both?

I think solving this technical question will be one of the biggest challenges of the project. The goal is to find an approach that could eventually support a shared standard for agent identity and reputation across the industry.

Built With

• nextjs
• resend
• webmcp