Authentification and Authorization Middleware

Inspiration

AI agents are starting to get real access: they can read your files, call your APIs, act on your behalf. But most agent platforms treat that access as all-or-nothing. Give an agent a credential and it either has full run of your account or none at all, and there's no clean way to pull it back once a task is already running. That's the same mistake early web apps made with session tokens before OAuth existed, except now the thing holding the credential is a language model that can be tricked, jailbroken, or just wrong. We wanted to build the layer that should already exist: real, enforced, revocable permission boundaries for agents, not a system prompt asking one nicely to behave.

What it does

Agent Launchpad's middleware gives every agent its own identity, separate from the human who created it. A human delegates a narrow, scoped, time-bound grant to an agent, never more access than they themselves have, and the agent gets a signed token good only for that grant, only for the life of its current Run. Every single action the agent takes gets checked live against a central policy engine before it's allowed to happen: is the grant still valid, has it been revoked, does it cover this exact scope, does it belong to this exact resource owner. A human can pull an agent's access back at any moment, mid-task, and the very next request the agent makes fails immediately, not eventually. High-risk actions require a human to explicitly approve them first, tied to the exact parameters so an approval can't be replayed for something else. And every decision, allowed or denied, lands in an audit trail with who, what, and why.

How we built it

We built it as a policy decision point sitting directly in the request path between the agent's sandboxed runtime and the platform's resource API, not as a UI-layer check that a clever prompt could talk its way around. Delegated grants and action tokens are custom HMAC-signed credentials modeled after OAuth token exchange, cryptographically bound to a specific user, agent, scope set, and Run. The check runs on every request against live state, not against whatever was true when the token was minted, which is what makes revocation actually mean something. We wrote it in TypeScript against the existing Fastify starter kit, kept the core authorization logic as one pure, testable function, and built a full automated test suite alongside a zero-dependency smoke test so the whole chain can be verified without needing a live model key.

Challenges we ran into

The one that taught us the most: our tests passed cleanly in our own dev environment but failed once we ran the same suite on faster hardware. Two records issued a millisecond apart were getting the same timestamp, and our "pick the most recent one" logic broke its tie the wrong way, silently handing out the wrong grant. It never showed up until real-world timing exposed it. We also hit a set of container-networking issues that only appeared once we actually tried running the whole thing as a container on macOS instead of just in our cloud sandbox: a missing curl binary in the runtime image, and a host-networking assumption that only holds on Docker Desktop and quietly breaks on Colima, Podman, or native Linux Docker. Both were the kind of bug that never shows up until someone outside your own machine actually tries to run it.

Accomplishments that we're proud of

Getting revocation to be genuinely live, checked on every request instead of cached at issue time, so pulling an agent's access actually takes effect instantly instead of "eventually, once the token expires." Catching and fixing a real, hardware-timing-dependent bug with a deterministic regression test instead of just hoping it wouldn't recur. And building this as something that's actually enforced in the backend, not represented by a disabled button in the frontend, which was the whole point from the start.

What we learned

That the most dangerous bugs in a system like this aren't the ones that fail loudly, they're the ones that succeed silently with the wrong answer, like a timestamp tie-break handing out a wider grant than intended. And that a demo passing in your own dev environment proves a lot less than you'd think; the moments that actually taught us something were when a teammate ran the exact same commands on a different machine and got a different result.

What's next for Authentication and Authorization Middleware

A real correlated trace across a Run, tool calls, sandbox events, and policy decisions tied together in one timeline, which we scoped out of this build in favor of getting the authorization chain itself right. Sub-delegation, so an agent could hand a narrower slice of its own already-narrow grant to a sub-task without ever being able to widen it. Key rotation instead of a single long-lived signing secret. And moving the audit log to genuinely tamper-evident storage, hash-chained or shipped off-host, instead of an append-only file that's honest today but not cryptographically provable.