-
-
Demo
Inspiration
We didn't come up with this from a whiteboard exercise. It came from watching how we already work. Between the three of us, we've been handing real tasks, "fix this bug," "wire up this endpoint", to coding agents for months. And every time, the same small dread: to do anything useful, the agent needs everything. Full repo access. Full CI permissions. Sometimes a peek at secrets it has no reason to touch. You grant it once, out of convenience, and then forget it's still sitting there.
The idea clicked properly when we were reading Egoist Machines' own framing of AI Passport, "grant one task, then remove access automatically", and realized nobody had actually built that for the tool we personally trust the least with broad access: our own coding agents.
What it does
Latchkey issues a single, scoped, expiring pass for an AI coding agent, instead of the usual four separate, standing credentials across GitHub, CI, a secrets vault, and Slack. The pass says exactly what it's for: this repo, this branch, these file paths, this many CI runs, these named secrets, gone in four hours. Every one of those four tools checks the same pass before doing anything. Every action, allowed or blocked, lands in one shared log. And if something looks wrong, one revoke kills access across all four systems at the same instant, not one dashboard at a time.
How we built it
FastAPI on the backend, async throughout, with passes issued as signed JWTs carrying scope, budget, and expiry. We mocked the four tools as their own endpoints rather than wiring up real GitHub/CI/Slack APIs, the point we needed to prove wasn't "we can integrate with four APIs," it was "one pass, checked identically everywhere." We used Google Antigravity to move fast on both the API layer and the frontend, which mattered a lot given the timeline, we locked the final idea with about two days left before submission, after going through a few other directions first (a customs-agent version, a hiring-disclosure version) before landing on the one we actually had the strongest personal stake in.
Challenges we ran into
The honest one: a signed JWT can't be un-signed. Once issued, it's valid until it expires, you can't reach into someone's pocket and take it back. So "revoke" isn't really revocation of the token itself; it's a server-side check against a revocation list that every tool consults before trusting the token at all. We debated hiding this detail to keep the pitch cleaner, and decided not to, it's a real tradeoff anyone building this for real would hit immediately, and naming it honestly felt more credible than pretending the JWT alone was the whole mechanism.
The other challenge was just time. Three people, two days, one working demo, one polished UI, one memo. We split it deliberately, one person owns the grant/verify/revoke logic, one owns the tool panels and the visual "aha" moment when revoke fires across all four at once, one owns making the write-up actually answer the judging criteria instead of just sounding good.
Accomplishments that we're proud of
Getting the revoke moment to actually feel like something, watching all four tool cards flip to blocked in the same beat, instead of just being a button that returns a 403. That's the whole pitch in one interaction, and it took real iteration to make it read that way instead of like four separate logs updating on their own schedule.
What we learned
That "trust should travel between tools" sounds abstract until you try to build even a toy version of it, and then you immediately run into the actual hard part, which isn't the permission model, it's revocation. Granting scoped access is the easy half. Taking it back, cleanly, everywhere, at once, is where most systems quietly give up and fall back to "delete the token and hope nothing was cached."
What's next for Latchkey
Real integrations, starting with GitHub fine-grained tokens and a CI provider, since those already have scoped-token primitives we could sit on top of rather than fight. Beyond that: reusable scope templates for common agent tasks ("bug fix," "dependency bump," "doc update") so a developer isn't hand-writing a scope from scratch every time, and a shared team view of every pass currently active across a project, the same thing our receipt log does for one pass, but zoomed out to an org.
Log in or sign up for Devpost to join the conversation.