Trinity Gate

Trinity Gate lets AI agents act through WebMCP while proving capability, authority, execution, and outcome before anything is called done.

Comment

No AI action is done until Trinity Gate can prove it.

Inspiration

AI agents are becoming capable of taking real actions across the web, but capability alone does not make an action complete.

An agent can have the wrong permissions, require human approval, encounter an execution failure, or simply lack the capability needed to perform part of a request. Yet users can still be left with a conversational response that sounds like the work was done.

Trinity Gate explores a stricter model:

An AI agent should never claim an external action is complete unless it had the capability and authority to perform it, execution actually occurred, and authoritative evidence proves the intended result.

What it does

Trinity Gate evaluates agent actions through four gates:

CAPABILITY → AUTHORITY → EXECUTION → VERIFICATION

Only VERIFIED_COMPLETE means done.

The demo uses one combined request:

“Upgrade Acme Corp to Priority support and email them the updated agreement.”

The two requested actions deliberately produce different outcomes.

Account update

The account-change capability exists, but changing the customer's support tier is consequential.

Trinity Gate returns APPROVAL_REQUIRED.

The human sees the exact target and proposed change and must explicitly approve it in the application. No WebMCP tool can grant that approval on the human's behalf.

After approval, the agent can execute the change:

Acme Corp: Standard → Priority

But successful execution is still not enough.

Trinity Gate rereads authoritative application state and compares the observed result with the exact action that was executed. Only after that evidence matches does the account action become:

VERIFIED_COMPLETE

Email action

The same user request also asks the agent to email the updated agreement.

Trinity Gate intentionally exposes no email capability.

Instead of implying the message was sent, it reports:

CAPABILITY_UNAVAILABLE

Action not performed.

Because the account change is verified while the email action never occurred, Trinity Gate reports the overall request as:

PARTIALLY_COMPLETE

One successful action cannot hide another action that never happened.

Why WebMCP

WebMCP is central to the product rather than an added integration.

Trinity Gate's web application exposes structured capabilities directly to an AI agent through WebMCP. The agent can discover what the application actually allows it to do, inspect authoritative state, prepare actions, evaluate them, execute eligible actions, and request verification.

At the same time, the application retains control of consequential authority and proof.

This creates a cleaner human-agent relationship:

  • the agent discovers and uses structured web capabilities;
  • the human retains consequential approval authority;
  • the application determines what actually happened and what evidence supports the final claim.

Without that separation, tool invocation and successful completion can easily be treated as if they mean the same thing.

Trinity Gate makes them explicitly different.

How we built it

Trinity Gate is a React and TypeScript application built with Vite and deployed on Vercel.

The hackathon demo deliberately uses deterministic browser-side application state instead of a CRM, email provider, database, or external SaaS backend. This keeps the WebMCP behavior reproducible for judges while still exercising real browser-native WebMCP tools.

The deployed application registers eight tools through:

document.modelContext.registerTool(...)

They are:

  • trinity_gate_diagnostic
  • list_customers
  • get_customer
  • prepare_action
  • evaluate_action
  • execute_action
  • verify_action
  • locked_demo_request

Each tool exposes an explicit name, description, and input schema.

Human approval is deliberately not exposed as a WebMCP tool.

The same governed domain logic is shared by the visible application and the WebMCP handlers, covering capability, authority, approvals, execution records, authoritative rereads, evidence, verification, request aggregation, stale-state protection, and deterministic reset behavior.

Verification and testing

We wanted the project's own development process to follow the same principle as the product: proof before claims.

The finished project was verified with:

  • 24/24 unit tests passing
  • Playwright browser testing across desktop, tablet, mobile, and reduced-motion configurations
  • native WebMCP discovery and safe-call testing in compatible headed Chrome
  • production lifecycle verification against the deployed application
  • deterministic Reset Demo verification
  • Gitleaks secret scanning
  • Semgrep OSS security analysis
  • clean TypeScript build and lint checks

Native testing confirmed all eight deployed WebMCP tools were discoverable and that no agent-callable approval or rejection tool exists.

Challenges

The hardest part was not registering a WebMCP tool. It was deciding what a trustworthy completion claim actually means.

That required separating several concepts that are often collapsed together:

  • capability from authority
  • approval from execution
  • execution from verification
  • individual action success from overall request success

We also had to ensure that approval was bound to the exact action, target, intended state, and relevant state version so stale or mismatched approval could not authorize a different action.

Another challenge was making partial completion explicit. If one action succeeds and another cannot even be attempted, the overall request must not be summarized as success.

Accomplishments we're proud of

The part we are most proud of is that Trinity Gate does not merely demonstrate an approval screen.

It demonstrates an end-to-end trust model:

discover → inspect → prepare → evaluate → approve → execute → reread → verify

The agent cannot approve itself.

Execution alone cannot produce VERIFIED_COMPLETE.

A missing capability cannot produce fake success.

And a partially completed multi-action request remains visibly partial.

What we learned

WebMCP makes it possible for web applications to expose structured capabilities to agents without forcing those agents to infer actions from visual interfaces.

But exposing a capability creates a second problem: deciding how much authority the agent should have and what evidence is required before a human should trust its completion claim.

We learned that these are separate questions:

Can it do this?

May it do this?

Did it do this?

Can we prove the intended result occurred?

Trinity Gate exists to keep those questions separate.

What's next

Trinity Gate is the standalone WebMCP proof built for this challenge, but the trust model behind it is designed for a much larger system I am building called Trinity Syntara.

Trinity Syntara is an AI operating system for coordinating agents, persistent context and memory, permissions, human decision boundaries, and verified action across real workflows and external systems.

The goal is not simply to give AI more tools. It is to give AI the correct amount of authority and make sure it can prove what actually happened before reporting work as complete.

Trinity Gate isolates and proves one critical part of that larger problem for the open web:

CAPABILITY → AUTHORITY → EXECUTION → VERIFICATION

In Syntara, this same principle is intended to operate continuously across broader agent workflows. An agent may be able to interact with development tools, communications platforms, business applications, or other connected systems, but capability alone will never be treated as proof of completion.

The same rules demonstrated in Trinity Gate remain important:

  • an agent cannot claim authority it was never granted;
  • consequential actions can require explicit human approval;
  • successful execution is not the same as verified completion;
  • unavailable capabilities must be reported honestly;
  • partial completion must remain visible;
  • authoritative evidence determines the strongest completion claim the system is allowed to make.

Future directions for Trinity Gate itself include richer approval policies, persistent or signed evidence, broader connectors, and multi-system authoritative verification.

Syntara is not part of the hackathon submission, and none of its private implementation is included here. Trinity Gate is the standalone public WebMCP proof of this trust model.

Links

Live application:
https://trinity-gate.vercel.app

Source code:
https://github.com/gstephens-cyber/trinity-gate

Demo video:
https://www.youtube.com/watch?v=meDUsAOvj3A

Built With

Share this project:

Updates