DocsGetting started / Verification and the trust gate

Verification and the trust gate

One rule sits in front of everything: no action ever runs against a business that has not verified that action. Not a setting, not a default. There is no path around it.

What verifying an action means

Verifying an action means the owner has seen it, approved it, and set the terms: the hours it can run, how many an agent may create, and which fields an agent may fill. Until that happens the action exists only in test mode, where nothing reaches the business.

The gate, part by part

  1. The plateHas the owner verified this action?The owner’s side. Their tick is struck into it once they have seen the action and approved it. Until then the action exists only in test mode, and nothing reaches the business.
  2. The keepIs the request inside the terms they set?Cut to three limits the owner chose: the hours it can run, how many an agent may create, and which fields an agent may fill. A request outside any of them does not fit.
  3. The barWho is the agent, and did it complete?The one part that moves. It lifts once for one real outcome, and every lift is written down with the agent’s identity where the agent offers it, so it can be replayed. Attempts do not lift it. Duplicates do not lift it twice.

Three knocks at it

  1. An action the owner has not verified.Refused. It stays in test mode, where nothing reaches the business.
  2. A verified action, outside the hours the owner set.Refused, logged, and the owner is notified.
  3. A verified action, inside the terms.Runs once. One verified completed action: logged, attributed where the agent names itself, replayable.
  • What the owner set, and the record
  • The bar: the one part that moves
  • A knock the gate refused
The designed mechanism, not a recording. The gateway’s do tool refuses every call the owner has not switched on. The audit below measures the part that reads sites.

A verified completed action

A verified completed action is the unit we bill. It is one real outcome, a booked job, a submitted quote, an appointment, that ran through a verified action and completed. Duplicates do not count. Attempts do not count. Every one is logged with the agent’s identity where the agent offers it, and can be replayed, so an argument about whether a booking happened is settled by the record.

How we hold ourselves to it

5,449

outbound requests audited across fifteen businesses we have never spoken to, none carried anything we typed

The guarantee that was actually measured is that nothing we type reaches a business, which is stronger than never submitting and is the one that can be checked from outside.

The scanner and the mapper are built and only ever read sites; they never write to them. The gateway at frontlatch.com/mcp runs over the business index. In the console at /app an owner can switch an action on and set its limits, and for one routing choice, email-confirm, the gateway reads it: a matching do call becomes a pending, logged attempt with a one-tap confirm email, instead of a refusal. The one other exception is signup: where an owner has switched agent sign-ups on, do fills in that site's own sign-up form (or, if the owner registered their own endpoint, asks that endpoint) to create an account, but only after the user confirmed in their own chat, and never with a password or card number, and a form that asks for a password or a CAPTCHA is handed back to the user. Only the owner’s own endpoint answering “created” verifies a sign-up; a form-path “created” is the site’s page speaking, so it is reported as unverified and never billed. Login, purchase and every other form are still never run.

Every other call is refused. The owner’s limit is enforced on the email-confirm path.

See what an AI agent can do on your site.

Scan my siteHow the score works