What is Ajar
Ajar gives websites a signed contract for AI agents: what is public, what needs user authority, what actions exist, and what proof remains afterward.
Ajar opens websites to AI agents under owner-controlled policy. It gives a site a signed Capability Manifest, semantic Views, typed Actions, Mandates, Receipts, and 402-native metering without replacing HTML, checkout systems, payment rails, MCP, or agent frameworks.
Problem statement
Most agents reach a website the same way a person does: load the page, scrape the HTML, follow links, submit a form, and sometimes carry a browser session. That works for demos, but it is a poor contract for real websites.
Four things go wrong:
- The agent cannot reliably tell public content from account data.
- The website owner cannot publish a clear machine-readable policy.
- The user cannot delegate only a narrow job without handing over broad session power.
- A purchase, message, deletion, export, or legal action often leaves weak proof of what was approved and what happened.
What Ajar resolves
| Problem | Ajar resolution |
|---|---|
| Agents scrape HTML and guess meaning | Semantic Views expose signed, structured content from the same URLs |
| Owners cannot govern agent access | The signed Manifest declares exposed resources, actions, tiers, prices, and gates |
| User login is too broad for delegation | Principal-signed Mandates grant narrow scopes, caps, domains, expiry, and revocation |
| Risky actions are easy to misfire | SIMULATE, signed Offers, signed Commits, and Receipts make execution checkable |
| Reads, writes, and payments blur together | R0-R3 risk classes separate public reads, reversible writes, irreversible actions, and financial/legal effects |
For deeper explanations, read the Concepts section. It breaks down each problem and the Ajar resolution in plain language before you enter the normative spec.
How Ajar solves it
- Owner publishes the contract. The site owner installs a Gateway, plugin,
or native integration. The owner reviews generated Views, Actions, policy,
pricing, and gates, then signs the manifest at
/.well-known/ajar.json. - Agent verifies before acting. The agent Kernel fetches the manifest, checks signatures, and learns what is exposed and under what conditions.
- Public reads stay simple. Catalog pages, docs, public prices, and blog posts can be exposed without a user session if owner policy allows it.
- Account reads require authority. Orders, invoices, carts, profiles, saved addresses, and support tickets require a linked account and a principal mandate.
- Risky actions rehearse first. For irreversible, legal, financial, or personal-data actions, the Kernel asks the site to SIMULATE and checks the result against the mandate.
- Commit leaves proof. The site signs an Offer, the agent commits only if policy and mandate still match, and both sides keep the Receipt.
The model does not need the user's cookie. The user logs in normally, links the account to a principal key, and signs a mandate for a specific agent key. The model can propose work, but the Kernel and Gateway check signed authority before the site touches the real account.
Primitives
| Need | Ajar primitive |
|---|---|
| Meaning | Semantic Views served from the same URLs as HTML |
| Actions | Typed Actions with R0-R3 risk classes |
| Safety | SIMULATE dry runs and two-phase Offer/Commit |
| Authority | Principal-signed Mandates with scope, caps, expiry, and revocation |
| Accountability | Dual-signed Receipts and audit trails |
| Economics | 402-native metering with pluggable settlement |
How it works
- A site owner installs or runs an Ajar Gateway, plugin, or native integration.
- The owner reviews generated Views, Actions, policy, pricing, and gates.
- The owner signs a Capability Manifest at
/.well-known/ajar.json. - An agent Kernel discovers the manifest, verifies signatures, reads Views, simulates actions, checks mandates, commits only when allowed, and stores receipts.
The owner key is the root of authority. Automation drafts; owners decide.
Reading order
Start with the protocol specification if you are implementing. Read architecture for the system walkthrough, security model for threat boundaries, and owner control for policy semantics.
New contributors should begin with onboarding, then the roadmap and build order.