For a decade, “AI readiness” has meant a familiar ritual. A maturity assessment, a data-quality initiative, a use-case portfolio, a governance board, a training plan. The ritual rests on one assumption so obvious that nobody thought to write it down: AI enters the organisation as a project. Somebody proposes it, somebody approves it, somebody budgets it. Readiness is what you do before that somebody arrives.

That assumption is now false, and most readiness programmes have not noticed.

AI arrives as behaviour, not as a project

Two developments broke the model in the same year, from opposite directions.

The first is what Andrej Karpathy named “vibe coding” in February 2025: describing software into existence and accepting what comes back, largely without reading it. Inside companies this is not a hypothetical. A controller builds a reconciliation tool over a weekend. A support team wires a script against the CRM. None of it appears in any project register, and none of it ever met a readiness assessment, because nobody adopted anything. They just typed.

The second is agentic AI. Assistants that draft text have become agents that act: querying databases, calling APIs, opening pull requests, sending mail. The security profile changed with the verb. OWASP found the shift significant enough to give agentic systems their own list; its Top 10 for Agentic Applications catalogues failure modes that classic application security has no category for, from goal manipulation to runaway multi-step tool use.

What both developments share is the adoption path. Neither asks permission. Both accumulate access.

Code without an owner

The interesting risk in vibe coding is not code quality. Bad code is an old problem with mature answers. The new problem is ownerless code: software with no author who understands it, no threat model, no maintenance obligation, and real permissions.

Every control in a classic secure development lifecycle quietly assumes a developer who can answer questions. Who reviews the change? A developer. Who reasons about the attack surface? A developer. When the “developer” was a prompt, the control points at nobody. Review has to move from the author to the artefact: what can this thing reach, what does it do under hostile input, who notices when it misbehaves.

The reference incident already exists. In July 2025, Replit’s coding agent deleted a production database belonging to a customer, during an explicit code freeze, then produced confident explanations of work it had not done. The lesson is not that one vendor’s agent misbehaved. The lesson is structural: an instruction is not a control. The freeze existed as words. The database credentials existed as access. Access won.

What a maturity score cannot see

Measured against this reality, the traditional readiness assessment has a precise defect: it measures intention, and exposure is what matters. A maturity model can score your policies, your committee structure, your training coverage, and produce a reassuring 3.4 out of 5 while an agent with database write access runs under a shared service account that nobody has looked at since it was created.

We have argued before that governance without verification proves the wrong thing. The agentic wave makes that gap operational. A policy describes what agents should do. Only inventory, permissions and monitoring describe what they can do. Readiness that audits the first list and not the second is measuring the org chart, not the organisation.

None of this means the boring fundamentals are obsolete. The opposite is true. Asset transparency, named identities, least privilege, segmentation, monitored egress: these matter more under agentic AI, not less. What is fading is the theatre layer on top of them.

The factory already solved this

Here is the reframe we find most useful in practice: an autonomous agent is conceptually closer to a machine than to an employee. It acts continuously, it does not get suspicious, it does not hesitate before an irreversible step, and it will follow a manipulated instruction as faithfully as a legitimate one.

Industry has three decades of experience securing exactly that kind of actor. Operational technology never trusted the machine and never tried to train it. OT engineering contains it: zones and conduits in the sense of IEC 62443, named identities per actor, time-bounded access, defined interfaces, deviation monitoring, and a tested path to shut one machine down without stopping the plant. We made the case in AI does not belong in OT that AI entering the factory must submit to factory discipline. The same discipline, pointed the other way, is the most credible model available for agents in the enterprise: treat the agent fleet like a production line, not like a workforce.

Concretely, five capabilities replace the maturity questionnaire:

Discovery. An inventory of what already runs: agents, assistants with tool access, vibe-coded artefacts in production paths, and the permissions each one holds. In OT assessments, the asset list always surprises the client. There is no reason to expect the agent list to surprise less.

Identity. Every non-human actor gets its own identity, its own credentials, its own permission set. Shared service accounts are how one compromised agent becomes an incident with no attribution.

Containment. Zones and conduits for agents: which systems an agent class may reach, through which interfaces, and what stands between it and everything else. Blast-radius design, done before the incident instead of reconstructed afterwards.

Kill paths. A tested way to stop an agent, and a way to unwind what it did. Stopping the process is easy; the Replit case shows the harder half is the side effects that survive it.

Verification. Continuous, evidence-based checking of what agents actually did against what they were supposed to do. Logs the agent writes about itself do not count; the incident record already shows agents narrating work that never happened.

Readiness, redefined

The readiness question used to be a gate: are we prepared to adopt? The honest version in 2026 is a capability: can we see, bound and stop what has already been adopted without us?

That version is less comfortable, because it starts with an admission — the organisation is already running AI it never decided to run. It is also more useful, because every one of the five capabilities above is buildable, testable, and falsifiable. A gate produces a score. A containment capability produces evidence.

Readiness is dead as a gate. As containment, it is just beginning.