Intent Is Infrastructure

In July 1971, Stafford Beer received an unexpected letter from Chile. The sender was Fernando Flores, a 28-year-old engineer working inside Salvador Allende’s government, helping manage a rapid wave of nationalization that had suddenly made the Chilean state responsible for far more industry than it knew how to coordinate. Flores had read Beer’s work in management cybernetics and wrote, in effect: this is no longer theory; we have a live system, a national one, and we need help steering it. Beer understood immediately what this was. A British cybernetician, long full of grand theories about viable systems, feedback, and decentralized control, had been handed the rarest thing a theorist can receive: a brief and improbable chance to try the whole thing for real.¹

The details only make the story stranger. Cybersyn was built under pressure, with almost no time, one contested mainframe, a telex network assembled from dormant machines, software work split between Chile and London, and a mandate to make the thing useful in months, not years. The operations room later became iconic — molded chairs, glowing wall panels, the kind of room people still post today as if the future had once been more stylish than the present — but Beer insisted the room was not the point. The point was to make a complex system legible enough to steer: let signals rise from the edge, preserve autonomy where possible, escalate only when necessary, and build a human-centered control machine rather than a shrine to central command. Cybersyn was interrupted by the 1973 coup before it could fully mature, but the facts alone are enough to keep it alive in the imagination.¹

That old cybernetic instinct feels newly relevant under AI.

For years, security has been obsessed with seeing. See the process. See the network flow. See the vulnerable image. See the exposed service. See the alert. And that work mattered. Modern systems are fast, distributed, and slippery. Without better sensors, there was nothing to steer. But AI is changing the problem. It is making investigations faster, workflows more fluid, interfaces more disposable, and automation more plausible. The stack below us is getting more dynamic, not less. What begins to matter, then, is not only what we can see. It is what we can keep stable while the tools keep changing. Daniel Miessler gets part of this exactly right: the important shift is not just model capability, but the rise of loops that define goals, execute, log, improve, and feed the result back into the system.²

A recent essay from Block pushes in a similar direction from the organizational side. It argues that hierarchy was, historically, an information-routing technology: a way to move context and decisions through an organization under severe human limits on coordination. Their claim is that AI now makes a different substrate possible — a company world model, a customer world model, an intelligence layer, and far less dependence on permanent managerial relay. That is a powerful idea. It is also, to my ear, a little too confident in the dream of central synthesis. The lesson I take is narrower and more interesting: AI is changing the architecture of coordination, yes, but the answer cannot merely be a smarter tower. The deeper problem is what must remain durable while everything underneath becomes fluid.³

Security is one of the first places where this becomes impossible to ignore.

The old stack was built around sensors, signatures, dashboards, policies, tickets, and human interpretation. The new stack is beginning to grow loops. Some systems feed AI investigations back into detection quality. Some build behavioral fingerprints and runtime baselines. Some try to turn plain-English policy into executable rules inside a sandbox. IronCurtain is a useful miniature of this instinct: intent becomes policy, policy becomes runtime mediation, edge cases become auditable feedback.⁴ These are different products with different buyers, but they rhyme. They all suggest the same shift: security is growing a new feedback layer.

What still does not exist cleanly is the layer that asks the harder question:

That layer is not just detection. Not just policy. Not just response. It is reconciliation.

A world model describes what is happening: resources, behaviors, dependencies, outcomes, drift. That is useful. But it is not the same thing as intent. Intent describes what the system is for. Which boundaries matter. What should never quietly become normal. What actions can remain local, what actions should escalate, and what counts as improvement. A world model without intent is a very sophisticated mirror. It can describe the defended system in exquisite detail while still saying nothing about what ought to tighten, what ought to remain forbidden, or what kind of change would actually make the system safer.

That is why security feels like such an important proving ground. Security is not only about knowledge. It is about constraint.

Take a more sophisticated example than “open a developer ticket.” Imagine an internal vulnerability-response capability inside a large company. At the lowest level, one service watches newly deployed images, compares them against approved feeds, and gathers evidence from runtime telemetry. At the next level up, a platform harness decides whether a discovered weakness should trigger tighter sandboxing, reduced egress, new runtime restrictions, or a temporary compliance exception. Above that, there is an organizational control plane: security automation may ratchet tightly when the evidence strongly reduces lateral movement or narrows unnecessary authority, but any action that affects regulated data, uptime guarantees, customer-facing blast radius, or formal compliance evidence must escalate. Above even that sits executive judgment — call it CISO intent, if you like — about acceptable risk, attack resistance, and which classes of behavior may never be silently normalized no matter how convenient they become.

That is one system, not four.

And its power comes from the fact that the layers can map to one another. A local runtime rule is not merely a local rule. It is a projection of a higher-order boundary. A compliance requirement is not merely a checkbox. It is one expression of a broader intent about what kinds of evidence, authority, and exposure the organization is willing to tolerate. The point is not top-down command. The point is traceability across scale.

This is what I mean by saying that intent is infrastructure.

Not prose in a wiki. Not a slogan. Not “the service scans images and opens tickets.”

A hands-on version would look more like this: every meaningful unit in the system — a code path, a service, a harness, a product surface, a compliance control — has a durable intent object attached to it. Maybe it is a spec.md, maybe it is structured policy, maybe it is both. It says what the unit is for, what signals matter, what metrics define health, what behaviors are forbidden, what dependencies are approved, what must escalate, and what counts as a ratchet toward a safer state. That object maps downward into concrete mechanisms: tests, evals, runtime policy, sandbox boundaries, alert thresholds, evidence collection, exception handling. It also maps upward into broader control objectives: attack resistance, operational resilience, audit posture, customer trust.

One form of development, in that world, is to have metrics and spec.md mapped to every meaningful line of code. Another is to have every harness or control point answerable to a higher-order statement of purpose. The point is not bureaucratic perfection. The point is that when the underlying tooling changes — when one policy engine is replaced by another, when eBPF yields to a better runtime substrate, when one vendor disappears, when one model family gives way to the next — the intent layer survives. The mechanisms churn underneath; the constitutional layer remains. That is what makes it infrastructure rather than documentation.

This is also why I think security will become more open.

Open source already shares code, libraries, infrastructure modules, and detection content. But a more mature intent layer could let teams share something harder and more valuable: baseline constraints, non-normalizable behaviors, safe ratchet sequences, exception patterns, compliance mappings, and histories of what tightening actually worked. These would not be universal policies. They would still need to be merged with local topology, identity systems, business workflows, and risk tolerance. But best practice would no longer have to begin as private folklore locked in one vendor’s syntax or one engineer’s head. Intent would become portable in the same way code became portable: not because every environment is identical, but because the durable parts can now travel.

There is, I think, a subtle political point hiding in all this.

The temptation in moments like this is always to imagine a better center: a bigger dashboard, a more comprehensive world model, a more intelligent layer above the org chart. But Beer’s own instincts were more interesting than that. Cybersyn was not supposed to be omniscient command. It was supposed to preserve local autonomy and escalate only when the local system could no longer absorb the disturbance. That feels like the right corrective to some present-day AI managerial fantasies. The answer is not to make every decision legible to a single synthetic sovereign. The answer is to build better constitutional machinery: what can remain local, what must be constrained, what requires escalation, and what must be remembered.

The word that feels right to me here is ratchet.

A good security loop should not simply observe and reset. It should, when the evidence is strong enough, tighten. A recurring audit-only rule becomes a block rule. A broad allowlist becomes a narrower dependency. An exception expires. A shell disappears from an image. An over-privileged capability is split in two. A control that was once vendor-specific gets re-expressed in a more durable intent object and survives the migration. The defended system becomes a little more constrained, a little more legible, and a little harder to misuse.

Not every change improves security, of course. Some only make dashboards quieter. Some only move ambiguity around. Some merely make the organization feel more coordinated while leaving authority just as diffuse and attack surface just as broad. So the real question at the center of this new layer is not whether an alert fired, or whether an anomaly was investigated, or whether the intelligence layer found a clever composition of capabilities. It is simpler and harder than that:

Cybersyn is remembered because the room looked like the future. But the deeper idea was not aesthetic. It was organizational. A group of British cyberneticians and Chilean engineers were given, for a brief moment, the chance to ask what must be made durable so that judgment can survive turbulence.

Under AI, that question returns in a harder form.

World models will improve. Tools will churn. Interfaces will come and go. The scarce thing will not be information. It will be the constitutional layer above the machinery: intent, boundaries, escalation, and memory. In security, that layer may arrive first as a feedback system that ratchets controls tighter over time. Elsewhere, it may look broader. But the underlying problem is the same.

A system can only be steered as well as its purpose can be made durable.