Agents acting for people

Every observation says how much it can be trusted. This page explains the ladder, the one rule the protocol defends hardest, and how an agent that works for you acts at your level without a second password.

The design goal is trust that is light, but explicit. The protocol does not invent a new identity system. It starts from a relationship that already exists, the monitor and the person who owns it, and it records every step a claim takes.

The ladder

Two fields sit beside the tier. origin says what kind of source made the observation: human, agent, webhook, probe or system. verified says how it was checked, and its top two values, human_verified and certified, follow the same rule as src.

A machine cannot rate itself

The rule is short: a machine cannot claim a person's level of certainty.

• A probe or a webhook can report measured.
• An agent's own claims start at unverified. A person promotes them after review.
• An agent that asserts src is refused with TIER_NOT_ASSERTABLE.
• On a monitor owned by a machine, nothing reaches src, human_verified or certified. The server refuses with PROVENANCE_CEILING.
• Leaving a field out never reaches the top. With no tier stated, an observation stops at measured. With no verification stated, it stops at reported. Whoever means src has to say so.

Every refusal is kept. The server appends an ai.mentu.monitor.rejected observation with the reason and the raw input, so an attempt to climb the ladder is itself part of the record.

An agent acts at its owner's level

Agents work for people, and a rule that locks out a person's own agent is not a good rule. So an agent can act at the level of the person it works for, and say so in one field.

That person is the monitor's owner. The owner gave the agent the monitor's token, and that is the relationship the protocol trusts. The agent names the owner in on_behalf_of:

{
  "type": "com.example.ci.review",
  "subject": "release-0.1.2",
  "actor": "agent:claude",
  "on_behalf_of": "human:you",
  "origin": "human",
  "tier": "src",
  "data": { "status": "approved" }
}

The observation is accepted at your level, and the record keeps both names. actor says the agent saw it. on_behalf_of says it was for you. Anyone reading later can tell the machine and the person apart, and nothing forces the record to choose one of them.

What an agent cannot do

on_behalf_of can only name the monitor's owner. An agent borrows the level of the person whose token it holds, never the level of someone it merely names.

The refusal is for a claim that contradicts itself. The server cannot see who is at the keyboard, and it does not pretend to. What it can refuse is a record that says two incompatible things at once.

Where the protocol cannot verify, it discloses

A server can check who owns a monitor, or it can take the owner's word for it. Both are allowed, and the difference is always visible.

• A server started with --registration-token requires that token to create a monitor. Its monitors are marked attested: the server established who owns them.
• A server started without one is open. Its monitors work exactly the same way, and every state they serve carries the gap unattested_origin, which says plainly that nobody independent vouched for the owner.

Every observation also carries attested in its provenance, copied from its monitor at the moment it was written. The two fields divide the work: attested says whether the owner was established or declared, and on_behalf_of adds nothing a reader must trust beyond that, because it can only repeat the owner's name.

A refusal that people route around teaches a reader nothing. A disclosure they cannot route around tells the reader what a claim is worth.

Why it is built this way

The first version of this rule was a gate that a request could open by itself: it read the right to make a claim out of the same request that made the claim. An independent audit showed five ways through it, and only one of them was being tested. The rule is now enforced where the owner is decided, not in the request, and the conformance check C26 probes five ways to inflate a claim, checks that defaults stop below the top, and checks that a real delegation is honoured.

The full reasoning is principle P1 in the specification, and every change to it is in the decision log.

Next steps