Owner-controlled agent access

Ajar Protocol

A safer contract for AI agents using websites.

Today agents scrape pages, borrow sessions, and submit forms without a clear contract. Ajar lets a website publish what agents may read, what needs user authority, what must be simulated first, and what proof both sides keep afterward.

v0.1 draft · Phase 1 (Gateway MVP) in progress · Apache-2.0 / CC-BY-4.0

Problem statement and Ajar resolution

The problem is not that agents cannot click websites. They can. The problem is that clicking gives no reliable boundary between public data, private data, and real-world action. Ajar turns those boundaries into signed protocol objects.

Problem

Agents scrape pages built for people

Ajar resolution

Ajar serves signed semantic Views from the same URLs, so agents can read the meaning without guessing from HTML.

Problem

Login gives too much power

Ajar resolution

Ajar keeps cookies out of the model. Users link an account to a principal key and delegate only the scopes an agent needs.

Problem

Owners cannot say what is allowed

Ajar resolution

Ajar gives owners a signed manifest and policy surface for exposure, audience, pricing, rate limits, and gates.

Problem

Actions are hard to trust

Ajar resolution

Ajar makes risky actions simulate first, freeze into a signed offer, commit only under mandate, and end with a receipt.

How Ajar solves it

Ajar does not ask sites to replace HTML, checkout, or payments. It adds a signed layer beside the existing site, so owners keep control and agents get a stable contract.

The core rule is simple: public reads can be open by policy, account reads need user authority, and consequential actions need simulation, mandate checks, and receipts.

1. Publish

The owner installs a Gateway or plugin, reviews generated Views and Actions, then signs the manifest.

2. Discover

The agent fetches /.well-known/ajar.json, verifies the owner signature, and learns what is exposed.

3. Separate access

Public data can be read by policy. Account data requires a linked user account and delegated authority.

4. Rehearse

Before risky work, the Kernel asks the site to SIMULATE and checks the result against the mandate.

5. Commit

The site issues a signed offer. The agent commits only if the mandate, caps, risk, and cost still match.

6. Keep proof

The site and agent store a dual-signed receipt for audit, dispute handling, and accountability.

What happens with authentication

Ajar avoids the dangerous shortcut: giving the model a full logged-in session. The site still uses its normal login. Ajar adds account binding and limited delegation.

Public data

Catalog pages, docs, public prices, and blog posts can be exposed without a user session.

Account data

Orders, carts, invoices, profiles, and tickets need a linked account and user authority.

Risky actions

Purchases, messages, exports, deletes, and legal changes need mandates, simulation, offers, and receipts.