Securing the agentic org

Three parts of agents everywhere: running the SDLC, improving the org, reacting to production. And through all of it, the question every CTO asks me first: what stops one of them from destroying production — or being talked into it?

Two distinct failure modes hide in that sentence. An agent can make a mistake — wrong command, wrong environment, wrong assumption. And an agent can be captured — manipulated by text it read into doing something its operator never intended. The security literature treats these separately; I don't, because the same architecture answers both.

You don't secure an agentic org by making agents trustworthy. You secure it by making the blast radius small enough that a bad decision is survivable. That is a necessary foundation, not a complete threat model — it bounds the damage; it doesn't detect the attempt, and you still owe yourself logging, review and the ordinary controls underneath.

Environments are the permission system

First principle: one strong principal agent, and staging is a free-fire zone. On staging, our agents do whatever they want — create environments, run migrations, tear things down, deploy every branch. Not because we're brave: because the environment is the permission.

"Free fire" is doing a lot of work in that sentence, so here are its conditions. Staging carries synthetic data, never a copy of production's. Its credentials unlock staging and nothing else. Its infrastructure is disposable, and the worst outcome is rebuilding it from the pipeline — which we can do, because we've tested it. "One strong principal agent" is about orchestration authority, not data-plane reach: it can drive the whole SDLC in that environment, and it still cannot read a production secret, because none exist where it runs.

The honest gap in our own version: staging and production still share most of their third-party SaaS credentials — the Twilio, the OpenAI, the monitoring keys. Until that's split, our environment boundary bounds secret storage, not credential blast radius. If you audit one thing after reading this, audit that.

That last clause is the actual control. If your staging environment is precious — hand-configured, unrepeatable, "please don't touch the settings" — then you don't have a staging environment. You have a second production, and your agents have nowhere to be fast.

Part 1's rule applies here with teeth: guardrails live in code, not prose. We learned that agents (like humans) will eventually skip any instruction written in a document. The rules that hold are the ones enforced at the tool layer — the denied command, the pipeline that refuses, the credential that simply doesn't exist in that environment.

Production: reading is not writing

Production access is one ladder, and humans and agents stand on the same one. Three tiers, named for what they may do to production:

• Developer — nothing. Local, staging and demo only. This is where the principal agent lives, and where 95% of all work happens.
• Production — read and deploy, never write. Reading production is a diagnosis superpower: the whole reaction ladder from Part 3 runs on read access — logs, metrics, traces. An agent that can read production stops guessing. But reads are not free: logs and traces leak secrets and personal data all the time, so what you actually want is purpose-scoped, redacted, logged reads — this agent, this incident, these streams, with customer identifiers masked and every query attributable afterwards. And deploying is not writing: shipping means pushing a tag that runs a reviewed, automated pipeline — every merge gate travels with it. A human pushes that tag; that hasn't changed since Part 1.
• Root — write, which is to say break-glass. Here's the part that surprises people: on a normal day, nobody writes to production by hand. Not agents — and not humans either. Infrastructure changes reach production through CI, from code, after review. A human ad-hoc write to production is already an exceptional event. So we named the tier accordingly.

The asymmetry between read and write is the whole design. Make scoped reads easy to get and your agents diagnose like senior engineers. Guard writes absolutely and your worst day stays recoverable.

Break-glass is an agent, a human, and MFA

The honest scenario: something must change in production now, and I'm away from the keyboard. The old-world answer is the worst session of your year — a laptop on hotel wifi, a VPN, raw production credentials, and adrenaline. The most dangerous work, done under the worst conditions, with the least review.

Our answer is a break-glass agent — and I'll be precise about what exists, because "we have break-glass" is the kind of claim that should come with a date. The tier is real and enforced today: writing to production requires the root tier, which is MFA-gated, deliberately rare, and alarmed on use. The agent-prepares-it half is partially built and still hardening. The design: the agent prepares the exact mutation — the command, the target, the expected effect, the rollback — and a human approves from a phone, with the grant scoped to that single action, logged, and expiring.

Notice what this inverts. The agent — calm, thorough, incapable of adrenaline — does the careful part. The human does the two-second part that carries the authority: yes, do that one thing. One human action on top of a thousand automated ones, exactly the ratio from Part 1 — and in an emergency, that ratio is the difference between an audit trail and an apology.

Your ticket tracker is an attack surface

Now the capture problem. In 2025, Simon Willison named the pattern that underlies nearly every real-world agent breach since: the lethal trifecta. An agent with access to private data, exposure to untrusted content, and the ability to communicate externally is an exfiltration pipeline waiting for instructions. No exploit code required — the attack is a paragraph of text the agent reads.

Where does untrusted content live in an engineering org? Everywhere: web pages your agents research, READMEs in dependencies, error messages that echo user input. But the one nobody audits is the one this series has been celebrating since Part 1: your ticket tracker. Our agents read Linear tickets and act on them. Which means anyone who can get text into a ticket can talk to our agents. A customer pastes a "bug report" that contains instructions; support forwards it into Linear; an agent dutifully picks it up. Your intake form just became a shell prompt.

Prompt injection is unsolved — OWASP's Top 10 for Agentic Applications now maps it across most of the list — goal hijacking, tool misuse, privilege abuse, context poisoning and cascading failures are all downstream of the same problem — so the defences that work are the ones that don't require solving it:

1. Strip a leg of the trifecta from every agent. The agent that reads raw bug-report text runs sandboxed: no secrets, no production data, no ability to send anything anywhere. The agent that holds production reads never chews raw untrusted text — it gets structured, validated fields. Removing a leg is the minimum control, not a finished architecture: two legs can still hurt you, and "external communication" hides in more places than you think — a PR body, a webhook, a DNS lookup.
2. Authority follows the requester, not the text. Part 3's rule is really a security boundary: Marton's ticket can schedule sprint work because it's Marton's; an unknown reporter's ticket can trigger a sandboxed reproduction and nothing else. The words in the ticket carry zero authority — the identity on it carries all of it.
3. Separate reading from acting. Part 2's capture pipeline was built this way before I knew the vocabulary: the model writes an entry, and a deterministic script — which cannot be persuaded of anything — posts it. The model never holds the credential.
4. Blast radius, again. A captured staging agent can hurt staging. That sentence is most of our threat model.
5. Human gates on the irreversible. The two gates from Part 1 were designed for competence; they turn out to be the injection defence too. An attacker who captures an agent still can't push the tag.

Cloud agents or device agents?

Where should agents run? The 2026 answer is unfashionable: for most orgs today, agents on your own device introduce the least that is new.

A device agent inherits controls you already run: disk encryption, an SSO session that expires, short-lived credentials minted by your login, the VPN, the fleet policy. Nothing new has to be provisioned, which is a genuine advantage — but be clear about what it is. It is less new infrastructure to get wrong, not less risk. A laptop does not grant an agent a safe identity: it lends the agent yours, and "I am sitting here" is presence, not authentication — nothing re-checks it between the moment you unlock the machine and the moment the agent acts. And the endpoint blast radius is enormous: every repository you can clone, every browser session you are signed into, your messaging apps, your local credentials and your personal files sit in reach of the same process. Device-first buys you a smaller identity problem and hands you a bigger endpoint one.

A cloud agent is not a new laptop — it's a new employee. It needs its own identity, its own scoped credentials, its own audit trail, its own offboarding when you kill it. Most orgs cannot mint that safely yet, and bolting agent access onto a shared service account is how you get an unauditable superuser that never sleeps. Which is the real trade: device agents trade cloud identity risk for endpoint blast radius. Pick knowingly.

And yet: everything moves to the cloud eventually. Part 3's always-on reaction wants agents that outlive a closed laptop lid. Our interim rule draws the line by kind of work — deterministic automation (checks, detectors, pipelines) already lives in CI and the cloud; judgment — anything with an LLM in the loop — runs on a device, near a human. That line moves the day we can give a cloud agent an identity on the same three-tier ladder — scoped credentials, real audit, break-glass approvals — and not one day sooner. It's a maturity curve, not a religion.

The Monday audit

Five questions to ask your org this week:

1. Who can get text in front of your agents — tickets, docs, form submissions — and does any authority attach to the requester rather than the text?
2. Which of your agents holds two or more legs of the trifecta in a single session?
3. Do staging credentials unlock any production service? (Third-party SaaS keys are the classic silent leak.)
4. Can you rebuild staging from a pipeline — provably, because you've done it?
5. Does break-glass exist as a designed path — scoped, logged, MFA'd — or is the plan "find the founder's password manager"?

You don't need agents you can trust. You need an architecture where the question is survivable when the answer is no.

That's the series. Agents run the SDLC; the org improves itself; it reacts while you sleep; and the whole thing is arranged so that the two moments that matter still pass through human hands. The job left over is the one the title promised — deciding what's worth building, and holding the gates.

Part 5: Make everyone a developer — the payoff of all four parts: when the gates judge the work instead of the worker, who gets to build becomes a choice. Or start at the hub: The Agentic CTO.