A giant antique key beside a row of shut doors under a bright cloudy sky, one door glowing coral

Your AI agent shouldn't have root

Artur SabirovMay 20, 20265 min read

Somewhere in your repo — or your shell history, or a config file you keep meaning to clean up — there is a credential that can do everything. Deploy the app. Read every row in the database. Rotate the secrets. Drop the whole thing on a bad day. And at some point in the last year, you pasted it into a language model and hoped.

Not because you're careless. Because the tools gave you no other move.

The binary

Here is how access works for a coding agent today: it gets your key, or it gets nothing.

There is no dial between those two settings. Claude Code, Cursor, Codex — for any of them to earn their place, they have to deploy, read the database, touch the cache, pull a secret. The services those things live on were built for people with dashboards, so the only key they know how to mint is the human-sized one: everything it can reach, for as long as it lives, and anonymous the moment it's in use. You copy it into an agent's config and tell yourself you'll scope it down later. Then you go looking, and there is nothing to scope it down to.

Root, or nothing

Between all of it and none of it, there is no third setting to pick — so the master key wins by default.

How the key got so big

A single service can usually hand you a smaller key — a read-only token, a deploy-only role, a permission that expires. The trouble is that a founding team's stack is never a single service. It's five to ten of them stitched together: deploy on one, Postgres on another, then cache, DNS, secrets, mail, each with its own idea of what a key is and its own dashboard for minting one.

Scoped access on each service separately doesn't add up to scoped access across the stack. So the path of least resistance is the master key everywhere, or one big key wired to reach all of it. You didn't choose the blast radius. You inherited it, one integration at a time, until the smallest grant you could actually assemble was "everything."

One session, the whole stack

Why this matters isn't hypothetical, and you've read the same postmortems I have. An agent told in plain words to freeze the database, dropping it an hour later. A poisoned repository that quietly points a coding tool's traffic at someone else's server and walks off with the credential before a trust prompt ever appears. A single token that turns out to open every service its owner ever connected, from a machine the owner has never seen.

The thread running through all of them isn't that the models are reckless. It's that the key you had to hand over was the key to everything, so every slip and every compromise arrives at full size. One leaked table would be a bad afternoon. One leaked master key is the company.

What one key reaches

The same session, two grants. Root can touch every part of the stack at once, which is why one leaked key is never a small problem.

You became the IT department

There's a quieter cost that shows up long before any breach. When the only key is the big one, someone has to stand guard over it by hand — and on a founding team, that someone is you.

You rotate the secret after a contractor rolls off. You paste access into a new hire's tools on their first morning, then spend their last one revoking it across ten dashboards and hoping you didn't miss the eleventh. Every agent you add is one more principal touching production, one more thing to grant and ungrant and remember. This is the work WorkOS sells to two-hundred-person companies, arriving at 11pm on the desk of the person who was supposed to be shipping product. Nobody decided you'd take the job. The stack handed it to you along with the master key.

Keys, not root

Access — for every teammate and every agent — should be one thing: granted, scoped, audited, revocable.

Granted by a named person. "Maria granted this," not "a token exists somewhere."
Scoped to what the work needs. The staging deploy, not the production database.
Audited, so you can read back what was done under it, and by whom.
Revocable in a single motion, in a single place — the day someone leaves, or the moment a session starts to smell wrong.

None of that is exotic. It is how keys work everywhere except in a software stack assembled from parts, where the four properties get spread across ten services and quietly lost between them. Put them back in one place and the access log turns boring — a named principal, a narrow scope, a clean expiry. Boring is the goal. An audit line you never have to think about is what custody feels like when it works: the keys to one room, not the whole building.

What we built

This is the whole reason Lessly exists, and today it's what the headline on our home page says out loud: your AI agent shouldn't have root.

Lessly runs a founding team's deploy, database, cache, and secrets from one account. You and your agents connect to it over the same MCP surface, and the access you hand out is scoped rather than all-or-nothing — one place to grant it, one place to read the audit, one place to revoke it. A deploy an agent runs is authorized, attributed, and logged exactly like the same click you'd make yourself. The four properties stop being ten separate chores and become how the platform works.

And to be equally plain about what we're not building. Not another Vercel; infra primitives exist in plenty, and we don't compete on them. Not enterprise IAM, with its SSO and SCIM and SOC 2 — that is WorkOS's job, and we're glad they do it. Not a free tier for weekend projects; per-tenant infrastructure costs real money, and we would rather charge for it honestly than cross-subsidize it quietly.

Where this stands

Lessly is in private-beta development, and this whole argument is a bet that still has to be tested the only way positioning ever is: on calls with real founding teams after we launch. If the headline turns out to be wrong, we'll change it and say so here.

Until then, one claim you'll be able to check the day you're in: revoke a grant, and the agent holding it stops on its next call — not eventually, not after a sync, but there. That single motion is the product. The private-beta waitlist is open.