Where AI Passport is used best
Delegating tasks to AI agents — via scoped, time-boxed, revocable grants instead of all-or-nothing access. Track: Agents · Lane: Build.
Inspiration
We started by actually digging into what AI Passport is — not just the pitch, but Egoist Machines' own description of the mechanics: scoped field requests with a declared purpose and duration, user approval, proposed writes, and a receipt for every read or write. That last part stuck with us. Right now, handing a task to an AI agent — book a flight, check a calendar, make a purchase — means an all-or-nothing trust decision. There's no middle ground between "connect it and hope" and "don't connect it at all," and once access is granted, most systems have no clean way to pull it back mid-task. We wanted to see what it looks like if every agent gets a passport-issued grant instead — narrow, timed, and revocable — the way OAuth scoped access to apps, but for the self.
What it does
Checkpoint is a working mockup of an Agent Delegation Passport. An agent (TripBot, CalendarBot, GiftBot) shows up at the "control booth" asking for a specific field, a stated purpose, and a duration — never blanket profile access. You approve it as-is, edit the scope down, or deny it outright. Every approved grant gets stamped into a "passport ledger" with its own ID, limits, and expiry. A "simulate agent action" button shows the agent actually using that grant, and every action appends a timestamped receipt. Hit "revoke" on any active grant and the very next action attempted against it gets blocked and logged — permission dies mid-task, not just before it starts.
The problem we're solving
AI agents are starting to act on people's behalf, but today that almost always means connecting an agent and giving it everything, or not connecting it at all. There's no way to say "you may book one flight under $600, using only my travel dates and budget, for the next 24 hours, and nothing else." And once access is granted, there's usually no clean way to pull it back if something goes wrong mid-task.
Who it's for
Anyone delegating a task to an AI agent for the first time — travel booking, shopping, calendar management — and developers building agents who need a standard, trustworthy way to ask for exactly the access their agent needs.
How AI Passport is used
The AI Passport becomes the place where scoped grants are issued, tracked, and revoked. When an agent needs to act, it requests specific fields for a declared purpose and duration — not blanket profile access. The passport holder approves, edits the scope down, or denies the request. Every approved grant is a signed, expiring record; every action the agent takes against that grant appends a receipt to the same record. Because the grant lives in the passport rather than inside any one app, the same delegation model works whether the agent is booking a flight, checking a calendar, or making a purchase.
What context, permission, proof, or access is involved
- Context carried: only the specific fields named in the grant (e.g.
travel_dates,budget_cap) — never the full profile - Permission: an explicit approve / edit-then-approve / deny decision per request, shown in plain language before anything happens
- Proof: each grant is a structured, signed record the agent must present before it can act; each action produces a receipt
- Access: scoped to one action type, capped (spend limit, single-use vs. repeat), and time-boxed with automatic expiry
Who controls access
The passport holder — at the point of request and continuously afterward. They can see every active grant and its full receipt trail in one ledger at any time, not just at the moment they clicked "approve."
What can be revoked or changed
- Any active grant can be revoked instantly, including mid-task — the next action attempted against it is blocked and logged
- Scope can be edited down before approval (e.g. halving a spending cap) rather than only accepted or rejected wholesale
- Grants expire automatically even if the user never revisits them
Risks or misuse concerns
- Scope creep — an agent could ask for broad permissions "just in case." We surface the requested fields and purpose in plain language every time, with edit-down as a first-class action.
- Revocation lag — a receipt proves an action happened; it can't undo it. Hard caps (spend limits, single-use flags) bound the damage before revocation is even needed.
- Agent chaining around scopes — one agent could hand off to a broader
agent to bypass a narrow grant. Grants are non-transferable to a
different
agent_id; any handoff needs its own fresh grant and receipt trail. - Over-collection by the passport itself — it should never hold more than a given grant requires; it's a router for scoped access, not a second copy of the user's entire data.
How we built it
It's a single self-contained HTML/CSS/JS file — no framework, so it's easy to open and click through without setup. We leaned into the "passport" metaphor deliberately: a navy "control desk," parchment-colored ledger pages, and a brass "GRANTED" / red "VOID" stamp that presses down with a small animation when a grant is approved or revoked. Underneath sits a real JSON schema for what a grant object contains — agent identity, scope, constraints, duration, status, and receipt history — rendered inline so the demo and the data model tell the same story.
Challenges we ran into
The hardest part wasn't the interaction, it was restraint. Our first pass tried to show every possible feature and it drowned the one thing that needed to be obvious: that revoking a grant has teeth, immediately, even mid-action. We stripped it back to three agent scenarios and one clear revoke-then-block moment. Getting the schema and UI to actually agree with each other was another one — we kept rewriting the JSON until every field in the ledger card traced back to a field in the schema.
Accomplishments that we're proud of
A fully interactive, revocation-first flow in a single HTML file with zero dependencies — you can open it and immediately grant, edit, simulate, and revoke, and watch the receipts prove it happened. The stamp/void visual isn't just theming — it's the clearest possible signal of "this access is live" vs. "this access is dead."
What we learned
That permissioning is a language problem before it's a technical one — the hard part is naming a scope in words a non-technical person would trust ("book one flight, under $600, for 24 hours") rather than a checkbox that just says "travel access." Revocation is the real test of a system like this — granting access is easy to demo, but making a mid-task "no, stop" feel instant is what makes people comfortable delegating to agents at all.
What's next for Checkpoint — an Agent Delegation Passport
- Real multi-agent handoffs, where a second agent needs its own fresh grant
- A "trust score" per agent developer based on how consistently their agents stay inside granted scopes
- Wiring the mockup to an actual AI Passport connection so grants and receipts are real, not simulated
- Spend and access analytics — a weekly digest of what was granted, used, and revoked
- Testing the language of each scope description with non-technical users
