Machine Passport

Evidence-backed machine readiness for humans and AI agents. WebMCP lets agents compare machines, explain blockers, and stage the next safe step—while humans keep execution authority.

Comment

Inspiration

I started Machine Passport from a very practical problem I keep running into: having several machines does not mean you actually know which one is ready for a specific job.

A machine can have the best CPU, the most RAM, or the strongest GPU and still be the wrong machine for an unattended workload because qualification is incomplete, recovery is unproven, deployment is fragile, or an important security fact is simply unknown.

That led to the question behind the whole project:

What if an AI agent could help choose the safest machine for the job from evidence — without giving the agent authority to change the machine?

That is Machine Passport.

The central idea is simple:

The fastest machine is not always the safest machine for the job.

What it does

Machine Passport turns machine evidence into a versioned passport and then evaluates readiness for a specific role across four dimensions:

  • FIT
  • DEPLOYMENT
  • QUALIFICATION
  • SECURITY

The result is deterministic rather than an LLM opinion.

One rule became especially important while building it:

UNKNOWN stays UNKNOWN.

If evidence is missing or a collector could not obtain it, Machine Passport does not silently turn that absence into a pass or a fail.

In the public demo, Atlas has the strongest hardware, but for an unattended AI workload it is NOT_READY.

Beacon is a more modest machine, yet it is READY_WITH_LIMITATIONS and has no hard blockers.

That difference is the product.

Why WebMCP matters

Without WebMCP, Machine Passport is already useful as a human dashboard.

With WebMCP, the page becomes something an agent can work with directly.

Instead of trying to infer machine state from rendered UI or DOM structure, the page exposes five typed tools over the same state the human sees:

  • list_machines
  • get_machine_passport
  • assess_role_readiness
  • compare_machines
  • stage_change_proposal

The first four are genuinely read-only.

The fifth can stage a bounded proposal in application state.

That means I can ask:

Which machine is safest for an overnight AI workload, what blocks the runner-up, and what is the smallest safe next step?

The agent can inspect the evidence, compare the machines, explain the result, and stage the proposed next step.

The proposal then appears in the same page for human review.

That shared state is the part I find most interesting about WebMCP: the human and the agent are not operating two separate versions of reality.

Human authority is part of the design

I deliberately did not give the WebMCP tools SSH, PowerShell, device access, or machine mutation.

Machine Passport is the pre-action decision layer.

The agent can inspect and stage.

The human decides.

Even after the human clicks Approve for Review, the proposal still says:

execution_state = NOT_EXECUTED

That is not unfinished functionality. It is the authority boundary of this version.

Agents inspect and stage. Humans decide. Machines stay untouched.

How I built it

The public challenge version is intentionally small and inspectable.

It is a static web application with:

  • a normalized MachinePassport schema,
  • strict JSON validation,
  • explicit evidence provenance,
  • deterministic readiness rules,
  • conservative UNKNOWN semantics,
  • five WebMCP tools,
  • shared proposal state,
  • and a human review interface.

The public app uses three clearly synthetic machines: Atlas, Beacon, and Relay.

The same frozen import and readiness core was also privately validated against one sanitized real machine passport.

I kept that claim deliberately narrow. This is not a fleet-management product and I am not claiming production deployment.

The current version has 157 deterministic tests, including malformed imports, UNKNOWN preservation, readiness aggregation, proposal transitions, blocker semantics, retry-safe staging, and machine-mutation invariants.

Challenges I faced

One of the most useful lessons came from testing the real agent journey instead of only testing the code.

During a live ChatGPT run, an identical tool retry initially created a duplicate proposal.

That exposed something unit tests had not made obvious enough: an agent-facing action needs to tolerate repeated calls.

I changed staging so that an identical active request returns the existing proposal instead of creating another one.

Another issue was blocker semantics. A limitation on an otherwise healthy readiness dimension was being presented too strongly. I changed the policy so a finding becomes a blocker only when its evidence intersects a dimension that is actually NOT_READY or UNKNOWN.

Those fixes reinforced the same lesson:

the contract exposed to an agent has to be stricter than the UI alone suggests.

What I learned

Building Machine Passport changed how I think about agentic interfaces.

The interesting question is not only:

What can the agent do?

It is also:

What should the agent be able to know, what should it be allowed to stage, and where should its authority stop?

WebMCP made that separation tangible.

It also showed me that machine readiness is different from telemetry.

Telemetry tells you what a machine has or what it is doing.

Machine Passport tries to answer a different question:

Given the evidence we actually have, is this machine ready for this role — and if not, what is the smallest safe next step?

What's next

The natural next step is to let specialist collectors and diagnostics feed Machine Passport evidence while keeping collection separate from adjudication.

That could make the passport useful across local workstations, GPU nodes, lab machines, and unattended AI systems without changing the core idea:

evidence first, deterministic readiness second, bounded agent action third, human authority last.

Built With

Share this project:

Updates

Submission history