How We Give AI Agents Access Without Losing Control
The scary part of agentic AI is handing an autonomous agent the keys to production. The failure we hit wasn't missing access — it was undiscoverable access, and the fix was two layers, not one.
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 our AI CIO spent an entire session working around access it held the whole time. It walked the CEO through the Vercel dashboard to fetch a credential that was already sitting in its local environment, and it designed a roundabout HTTPS path to the database while holding direct psql credentials the entire session. 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 a session burned because an agent could not see its own hands. The same seat then built the fix — a live access probe, so no agent has to guess again.
Two questions, never conflated
The fix rests on a distinction we now treat as load-bearing: what is authenticated right now, and what should this seat be allowed to use. Answering one as if it were the other is how agent access goes wrong.
The first is environment, not policy. A desktop session, a web sandbox and a fleet 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 — access-probe.sh, reachable as cw access or dev access — and wired its one-line summary into the moment every agent connects to its seat: git, Vercel, Railway, GitHub and the database, each marked present or absent, with the identity behind it but never the secret. An agent sees what it can actually do before it does anything.
In practice the three environments do not carry the shape people assume. A desktop session, running under a human's own login with .env.local present, typically carries git, Vercel, raw database access and the message bus all at once — the opposite of the "read-only laptop" instinct, because the credentials on a developer's machine are the most complete set in the company, not the most restricted. A web sandbox spun up for a single conversation sits at the other end: no raw psql, no git push, no deploy — but it still keeps a read-only database path through an HTTPS-bound query tool and the message bus, because a sandbox with zero data access could not do useful work at all. A fleet container's shape depends on the job it was built to run and is deliberately not assumed to match either of the other two — it gets probed, not inferred. None of these shapes is wrong. The mistake is assuming any one of them describes the others, which is exactly what our CIO's session did on 28 June — it reasoned from what a different environment usually holds instead of checking what this one actually held.
The second question — what a seat should be allowed to touch at all — is policy, and it lives in a written entitlement matrix owned jointly by the CTO (tooling and enforcement) and the CCO (entitlement policy). The CEO ratifies changes that touch personal data, payments or production.
The matrix, seat by seat
The matrix is not a tier system dressed up as governance. It is a plain table: seats down one side, services across the other, and a mark in each cell — read-only, write, deploy, or nothing at all. Every seat gets read-only data access by default, because reading is how any seat, human or AI, forms an accurate view before it acts. From there the grants narrow fast. Vercel deploy sits with the CTO and, for the release path specifically, the COO. Railway deploy sits with the CTO alone. Database migrations may be authored by any builder seat, but applying one to the live database is a separate, later act that happens at release — the same person who writes the SQL is deliberately not the one who ships it, a split in time rather than a split in trust. Stripe is read-only even for the CFO, whose whole job is money — the seat that watches spend most closely still cannot move it, because moving money is not a role you earn by proximity, it is a decision that stays with a human. Nothing here is dramatic. That is the point: a matrix built to be read end to end in five minutes is one a human will actually revisit, and one nobody can point to and say they never knew what it granted.
The matrix carries a status line that says what it is: a proposed baseline reflecting current reality, not yet formally ratified. That is not an oversight we are quietly hoping nobody notices — it is the honest state of a live document, and the ratification log that will record each future change currently has no entries, because no PII, Stripe or production grant has moved since the matrix was written. We would rather publish the true state of an unfinished governance process than round it up to "done" for the sake of a tidier sentence.
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. The policy document says this explicitly, in the same words we use everywhere else in the company for the same failure mode: assert real state, don't declare it. 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. It is the same discipline that runs through how we built our agent operating infrastructure, how the company coordinates its agents, and why we stopped letting an agent's own account of a decision stand in for the decision itself in how we stopped AI agents inventing the CEO's decisions.
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 handful of files that control how every other agent behaves — 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.
That list of gated acts is not frozen, and watching it change is the clearest evidence the model works as designed rather than as a slogan. On 10 August 2026 the CEO ratified moving the production-release gate itself: pushing the release now needs approval from the AI Co-founder, acting in its own authority, rather than the CEO personally signing off on every release. What did not move in the same change is the one gate that sits above every seat regardless of title — spending real money through the payment processor stays a human-only stop. That is the shape a live entitlement boundary should have: it narrows or widens with evidence and ratification, but the acts that can do the most damage to trust or capital are the last to move, and only ever move by a named, dated, cited decision — never by drift. A long list of gated actions would really be a confession that the matrix underneath is too generous; the fix for that is tightening the matrix, not stacking on another gate.
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 — a routine-looking request can clear a gate too quickly precisely because it looks routine, and a rubber-stamped gate 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-blast-radius credentials — a message-bus token whose worst case is spam on an internal channel — 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 failure we hit was not an agent overreaching — it was an agent blind to its 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, checking every time rather than taking either on faith, and being honest in public that the governance is still a proposed baseline, not a finished one.
More in this series
Frequently asked questions
How do you safely give an AI agent access to production?
You do not give it production on its own authority. Access is least-privilege — a written entitlement matrix sets what each agent may touch — and the acts that carry real weight, like a production deploy or a payment, stay human-gated regardless of what the agent holds. The credential is capacity; a human is still the judgement.
What is the difference between what an agent can access and what it is allowed to?
One is environment, one is policy. What is authenticated right now depends on where the agent runs, and a live probe reports it. What a seat should be allowed at all is set by a written matrix. Conflating the two is how agent access goes wrong, so we answer them separately and let the probe win when they disagree.
Why not just record each agent's access in a config file?
Because a declared capability drifts from reality the moment the environment changes, and a stale declaration gives an agent false confidence. We check live state with a probe rather than asserting it, so an agent always sees its real surface, not a description of it.
Does least-privilege make AI agents safe?
No. It shrinks the blast radius; it does not remove it. A read-only agent can still surface something it should not, and a human gate is only as good as the human reading it. The point is bounded, traceable damage — not a promise that nothing goes wrong.