How We Give AI Agents Access Without Losing Control

The frightening part of agentic AI is not what an AI agent might write. It is what it can reach. Give an autonomous agent a shell and a set of credentials and it can deploy to production, move money or sign up for a new service at three in the morning with no one watching. So the first question an AI-native company has to answer is not "how clever are the agents?" but "what, exactly, is each one allowed to touch?" Our answer is least-privilege, enforced by two layers we never let collapse into one: a live probe that reports what is actually authenticated right now, and a written entitlement matrix that says what a seat should be allowed at all. The failure that taught us to separate them was not an agent reaching too far. It was an agent that could not see what it already held.

The session spent working around access it already had

On 28 June 2026 one of our senior AI seats spent a whole working session engineering its way around access it held the entire time. It walked a human through a cloud dashboard to fetch a credential that was already sitting in its local environment, and it designed a roundabout database path while holding direct database access the whole way. Nothing was missing. The access was simply undiscoverable — environment-specific, unadvertised, and therefore invisible to the very agent that owned it. That is a particular kind of waste: not a breach, but hours burned because an agent could not see its own hands.

Two questions, never conflated

The fix began with a distinction we now treat as load-bearing. There are two different questions here, and answering one as if it were the other is how agent access goes wrong.

The first is: what is authenticated right now? That is a property of the environment, not the agent. A desktop, a web sandbox and a container each expose a different surface, and a credential usable on one is absent on another. The only honest answer comes from checking, live. So we built a probe. Every agent, the moment it connects to its seat, is shown a one-line report of its real surface — git, deploy, database, message bus, each marked present or absent, with the identity behind it but never the secret itself. An agent sees what it can actually do before it does anything.

In practice the three environments rarely agree with each other. A desktop session usually carries a full git identity and deploy credentials because it runs under a human's own login, but no direct database connection, since that path stays behind a service role key nobody hands to a laptop. A web sandbox spun up for a single conversation might have neither — it can read files and call approved tools, and nothing else, because there is no persistent identity behind it to hold anything more. A container built to run one script often looks like the desktop's opposite: full database access scoped to that script's job, and no git or deploy at all, because git and deploy are not what the script needs. None of these shapes is wrong. The mistake is assuming any one of them describes the others, which is exactly what the confused session on 28 June did — it reasoned from what a different environment usually holds instead of checking what this one actually held.

The second question is: what should this seat be allowed to touch at all? That is policy, and it lives in a written entitlement matrix, seat by service. Most seats get read-only data and nothing more. A few can deploy. Fewer still can apply a database migration. The matrix is deliberately a proposed baseline that reflects current reality rather than a decree, because an entitlement no human ever revisits is a liability, not a control.

The matrix itself is organised by tier rather than by individual seat, because writing a bespoke policy for every seat does not scale and a bespoke policy is exactly the kind of thing nobody revisits. A content seat that drafts and edits articles sits in the same read-and-propose tier as a research seat that pulls public data, whatever their day-to-day work looks like, because the risk profile — reading data, producing drafts, touching nothing live — is the same. A seat that ships code sits in a narrower tier that adds git and deploy but still stops short of touching money or production configuration directly. The handful of seats that can apply a database migration or approve a release sit in the narrowest tier of all, and that tier is reviewed the most often, because the cost of a stale entitlement rises with what the entitlement allows. Tiering by risk rather than by role keeps the matrix short enough that a human will actually read it end to end, which is the whole point of writing it down.

Why we refuse to just write down what each agent holds

The tempting shortcut is to give every agent a file that declares its own access — this seat has the database, this seat can deploy. We refuse to, for the same reason we distrust any state we assert instead of check. A declared capability drifts from reality the moment the environment changes, and a drifted declaration is worse than none, because it hands an agent false confidence. We saw this happen in miniature: a seat's onboarding notes said it held deploy access, written back when that seat's environment was first provisioned. The environment was later rebuilt without deploy credentials, because the seat's job had changed and it no longer needed them, but nobody went back and edited the notes. For months the notes were quietly wrong, and the only reason it never caused damage is that nothing ever tried to act on them — the seat kept checking the probe instead of trusting what it had been told about itself. That is luck, not design, and it is why the probe has to be the only place an agent looks. So the source of truth for what is live is always the probe, and the written policy carries only what ought to be permitted. When the two disagree, the probe wins — reality is not up for debate. This is the same discipline that runs through how we built our agent operating infrastructure and how the company coordinates its agents: assert real state, never declare it.

The gates that hold whatever an agent is entitled to

Least-privilege on its own is not enough, because holding a credential is not the same as permission to use it for the acts that carry real-world weight. So a second rule sits on top of the matrix and overrides it: some actions are human-gated regardless of what any seat holds. Shipping to production, spending through the payment processor, signing up for a new external service, editing a protected file — none of these happen on an agent's own authority, however much its environment grants. An agent can hold the deploy credential and still not be allowed to deploy alone. The credential is capacity; the gate is judgement, and judgement is the one thing we deliberately did not automate. Concretely, a small set of actions get treated this way regardless of which seat is asking: pushing code to the branch that serves production, moving real money through the payment processor, signing up for a new paid external service, and editing a handful of files that control how every other agent behaves. Each of those has a human or a designated approving seat standing between the request and the action — not as a rubber stamp, but as an actual point where the request can be refused. The line is deliberately short. A long list of gated actions is really a confession that the entitlement matrix underneath is too generous; the fix for that is tightening the matrix, not adding another gate on top of it. It is the same brake described in how the company improves itself: cheap capacity is only safe when it cannot ship its own worst decisions.

The honest limits

This does not make an AI agent safe to hand the keys to. Least-privilege shrinks the blast radius; it does not remove it. A read-only agent can still surface something it should not have read. A probe reports what is live but cannot judge whether it ought to be. A human gate is only as good as the human reading it. We have had a gated request approved without much scrutiny because it looked routine and the human reviewing it was moving fast — nothing went wrong that time, but the gate did not do any real work either, because a gate that is rubber-stamped provides the appearance of control without the substance of it. That is the honest failure mode of the whole model: not the agent breaking out of its box, but the human standing at the gate treating the gate as a formality. We keep our low-risk credentials — a message-bus token whose worst case is a bit of spam — well away from the ones that touch money or production, precisely because we assume something will eventually leak. The two-layer model does not promise nothing goes wrong. It promises that when it does, the damage is bounded and traceable to a seat, an environment and a moment.

The part almost no one builds

The lesson underneath all of this is dull and durable. Most teams reaching for agentic AI ask how much they can let their agents do. The more useful question is how clearly their agents can see what they are already allowed to do, because the expensive failures we have hit were not agents overreaching — they were agents blind to their own reach. Give an agent a true picture of its hands and a hard line it cannot cross alone, and you get the upside of autonomy without betting the company on it. That is not a clever trick. It is just refusing to confuse what an agent could do with what it should, and checking, every single time, rather than taking either on faith.

---

More in this series

• The Self-Coordinating AI Company
• The Self-Improving AI Company
• The Self-Aware AI Company
• How We Built Our AI Agent Operating Infrastructure