Agentic Infrastructure

← Back to Writing

The part of the agentic wave nobody wants to own

The agentic AI conversation in 2026 is loud, and most of it points at the same place: code. Every model launch is a coding demo. The market for agents that write, review, and ship software is crowded and getting more so. That is the easy frontier, because a coding agent's mistakes mostly land in a pull request a human still reviews before anything runs.

Infrastructure is the frontier with teeth. An agent that can operate real systems can restart the wrong service, push the wrong config, rotate the wrong credential, or open the wrong door. And the honest fact underneath all of it is that you cannot fully trust what the agent will decide to do, because agents act on natural language and that language can arrive hidden inside the very content they are asked to process. Prompt injection is not a solved problem, and the current consensus is that it will not be. So any agent useful enough to read your world can, in principle, be talked into misusing whatever it is allowed to touch.

That is the problem I set out to solve. Not "can an agent run infrastructure," the answer to that is obviously yes, but "can an agent run infrastructure such that a compromised agent still cannot cause harm." That constraint changes everything about how the system is built.

What the market is actually doing, honestly

It is worth being straight about the landscape, because I am not claiming to have found an untouched field. Two conversations are happening in 2026, and they are happening apart from each other.

One is agentic SRE and self-healing operations: agents that detect an incident, diagnose it, and remediate it. There is a real vendor market here, analyst reports, market maps, the whole apparatus. What most of that work waves past is the access question. It assumes the agent already holds the credentials to act, and focuses on the reasoning that decides what to do.

The other is non-human identity and privileged access management: governing the exploding population of agent identities, service accounts, and workloads. Analysts have named this directly, one industry body calls it the "non-human identity governance vacuum," and vendors are launching runtime authorization products that govern an agent's actions after it authenticates. What most of that work waves past is the operations question. It sells identity governance as a product to buy, not as an operating system for agents actually doing work.

The gap I find interesting is the seam between them. Almost nobody is showing both halves solved together, as one coherent architecture, by a builder who actually ran it rather than a vendor selling it. The industry agrees the problem is real and unsolved. Demonstrated, working answers are the scarce thing, not think pieces. This is one.

The core idea: decide at use-time, keep nothing standing

Every weak version of agent access fails the same way. Authorization gets decided once, baked into a token, a role, a group membership, or a long-lived secret, and after that it cannot be revoked on your timeline. A credential granted last week is still good the instant it is stolen, and stays good until someone notices.

The whole system is built on the opposite principle. The authorization to do something privileged is decided at the moment of the risky action, not in advance, and it requires a fresh, strong, human factor bound to that exact action. Nothing privileged sits waiting to be stolen, because nothing privileged is standing. One rule follows from that and governs the entire design: no standing, usable, privileged credential exists anywhere an agent, or the broker acting for it, can reach.

The custom broker: one narrow door, not raw access

The agents never hold shell access, cloud admin credentials, or a domain account they can just use. Every privileged action, from restarting a container to running an infrastructure-as-code deployment to reading a protected configuration, goes through a single broker.

The broker's job is narrow on purpose. It authenticates the calling agent's identity token, checks the requested action against a tight allowlist of granted capabilities, rate-limits, and logs everything. There is no general "run anything." Each capability is one named, scoped verb. The privileged work itself executes as an unprivileged, scoped service account, not as the agent and not as an administrator. If the broker is the only path to privilege, then the broker is the only thing that has to be hardened, watched, and reasoned about, which is the same logic that puts every public service behind one hardened entry point instead of twenty.

I built the broker rather than buying a platform for a specific reason: the novel part is the approval binding described below, and I wanted that to be mine and auditable rather than a black box. The parts that are not novel, secret storage and credential rotation, I did not hand-roll. Those are a solved problem, and I used a solved tool for them.

Verified ID and the two-key system

Here is the mechanism that makes "decide at use-time" real. A privileged release requires two keys turned together, and they are deliberately unequal.

The first key is mine. When an agent requests something privileged, the request is bound to one exact action, and releasing it requires a fresh approval that I present from a hardware-backed credential using Microsoft Entra Verified ID. The approval is not a session and not a general grant. It is cryptographically tied, through a single-use value, to that specific action: this agent, this verb, this target, right now. A presentation for one request cannot be replayed against another.

The second key is the agent's. The agent signs its request with a non-exportable key held in hardware, so the request cannot be forged or replayed by something impersonating the agent, and the signing key cannot be stolen off the host even if the host is fully compromised. The most an attacker on that host can do is ask the key to sign while the host is live, which is exactly the case the human approval is there to catch.

The reason the two keys are unequal is the most important idea in the whole design, so I want to be precise about it. A human approval carries an inherence factor, proof that a specific living person is really present, through a biometric check. A non-human identity can never have that. There is no thing an agent is in the biometric sense. The closest a workload can hold is attestation, cryptographic proof that the request came from genuine, unmodified code on a genuine machine. That is worth having, but it proves the code is authentic, not that the authentic code is asking for something legitimate. A correctly attested, prompt-injected agent will produce a perfectly valid signature over an attacker's request.

So I stopped trying to make the machine's key as strong as mine, because that is chasing a property that cannot exist. The two keys are asymmetric by design. The agent's key provides independence, non-exportability, and binding to the exact action. My key provides the one factor no compromise of the agent can reproduce. The security comes from the asymmetry, not from pretending a machine can carry a human's presence.

The rotation engine: solved problems get solved tools

The privileged credentials themselves are not left standing and static. The account model is tiered, and the two most dangerous accounts are disabled at rest, enabled and rotated only inside an approved, time-boxed, monitored window, then disabled and rotated again when the window closes. Outside that window the account cannot authenticate at all, so it is not merely secret, it is inert, and it is not a target for credential theft or lateral movement because there is nothing there to attack.

The engine that performs that rotation and checkout is HashiCorp Vault, running self-hosted on dedicated hardware kept off the main compute cluster so it holds its own physical failure and compromise domain. Its directory secrets engine natively rotates, leases, checks out, and audits the account passwords, which means the sensitive rotation logic is a mature, audited tool rather than a script I wrote and have to defend. It auto-unseals against a cloud key vault so a power blip does not leave it sealed and the rotation dead, and it snapshots to the same verified backup chain as everything else. The lesson I keep relearning is worth stating plainly: build the part that is genuinely new, and use a proven tool for the part that is not. The approval binding is new. Secret rotation is not.

Two planes, one model: on-premises and the cloud tenant

The reason this is infrastructure and not a demo is that the same authorization model governs two very different planes with one coherent shape.

On the on-premises plane, the privileged action is a credential release or a configuration change on real servers, network gear, and storage, gated by the broker. On the cloud plane, the same shape governs read and write to the management and directory APIs of a Microsoft 365 and Azure tenant. The agents hold governed, directory-native identities under Microsoft's emerging agent-identity model, gated by certificate and policy for standing reads, with write access split into narrow, scoped grants routed through the same use-time approval instead of standing administrative roles. One authorization model, two planes: decide at use-time, keep nothing standing, bind to the exact action, whether the action touches a domain controller in a rack or a Conditional Access policy in the cloud.

Getting the cloud plane right required abandoning my first instinct, which is a decision worth recording honestly. I started by governing the agents the way you would govern a privileged human: eligible role assignments, groups, just-in-time elevation through the platform's native privileged-access tooling. Tested against a live tenant, that pattern was structurally wrong for a non-human identity. Agents cannot join the groups the pattern depends on, and the human elevation tooling does not surface them. Agents are shaped like applications, not like users, and the runtime gate for an application is a certificate and a policy, not a person's step-up. I threw out the entire human-shaped scaffolding the moment the evidence said it was wrong, and the corrected, application-shaped model went live cleanly.

What it is actually for

None of this is security for its own sake. The point of giving agents governed, real access is that they can then do genuinely useful infrastructure work that would otherwise sit on a human's plate.

• Automate deployments. Every service ships from a git repository through an infrastructure-as-code pipeline. An agent can run that pipeline through the broker, so a deployment is a governed, logged, reversible action rather than someone hand-editing a server at midnight.
• Prevent configuration drift. Because git is the single source of truth and direct undeclared changes are banned, an agent can continuously compare what is declared against what is actually running and surface or correct the difference. Drift becomes something the system notices, not something you discover during an outage.
• Aid troubleshooting. An always-on agent with standing read access can triage across the whole estate, correlate logs and state, form a first diagnosis, and hand a human a real starting point instead of a blank incident. Read is low-risk, so it is always available. Anything that would change state escalates through the approval gate.
• Manage complex systems across both planes. The same agents reason over on-premises infrastructure and the cloud tenant together, which is where the real leverage is, because most incidents and most changes cross that boundary and a human normally has to context-switch between two worlds to handle them.

The tiering is what makes this safe to actually run. Read is standing and always-on because its blast radius is low. Scoped operations are granted per named task. Full administrative power is disabled at rest and only ever exists inside an approved, watched window. Capability scales with proven trust, and the most privileged credentials are isolated rather than shared.

Assume the compromise, and instrument the effect

Because prompt injection cannot be reliably prevented, prevention is only half the design. The other half assumes it failed. Trying to detect the malicious instruction itself is a losing game, because it lives in the model's reasoning and never lands in a log. The durable signal is the effect, expressed as a correlation rather than a signature.

The release requires two authorizations, so a privileged action that happened without a matching approval is, by definition, out of band. That single correlation, a privileged identity acting with no corresponding human approval in the window, is the highest-fidelity compromise signal in the system, and it is safe to wire to an aggressive automated response precisely because it is a correlation and not a guess. Around it sits the rest of a real detection program: the native directory and cloud-platform threat detections that catch attacks which never make the privileged account itself act, the credential store's access logs shipped somewhere the agent host cannot edit them, and a scheduled attestation that deliberately attempts a forbidden action and confirms it is refused, because controls decay silently and a control that fails open is worse than none.

Decisions, unedited

Architecture is a series of calls made under constraint. I keep a decision log so the reasoning survives the decision. A few from this build.

Why publish this

Because the good part was never a specific vault or a specific hostname. It is the posture, and postures outlast products. Authorize at use-time so a stolen grant is worthless. Keep the privileged identity inert until an approved, watched window. Make the two keys asymmetric instead of pretending a machine can carry a human's presence. Build the novel part and buy the solved part. And design from the assumption that the agent will eventually be compromised, so the architecture, not the agent's good behavior, is what contains it.

The industry named the non-human identity governance vacuum in 2026 without showing many working ways out of it, and it is building autonomous infrastructure agents in a separate conversation that mostly assumes the access problem away. This is what it looks like when one person solves both halves together and keeps the decision log. That is the kind of problem worth getting ahead of, and it is exactly the kind of work I want to be doing.