Why Your Org Isn’t Ready for AI (And Why the “Mature” Ones Are the Scariest)

A registry admin’s account got compromised. A malicious package with an embedded RAT made it into a popular npm library. This is a real risk and it happens, and the engineering org I’m thinking of responded the way a mature org should: they forced everyone onto their internal Artifactory instance and cut off direct access to the public registry. Correct call. I’d have made it too.

Then someone on the security team blocked the entire npmjs.org domain. Not the registry endpoint. The whole site. Developers couldn’t reach the registry, and they also couldn’t read the documentation. Every package README, every API reference, every migration guide, gone behind a firewall rule.

Leadership said access would be restored the following Monday. I have the thread. The date was in April.

It’s July. It’s still blocked. The developers stopped complaining weeks ago. They didn’t escalate it into a resolution. They just gave up and started copy-pasting docs from their phones. Nobody fixed it. The person who owned “I’ll get this resolved Monday” never closed the loop, and the org absorbed a permanent degradation of its own developers’ ability to do their jobs as though it were weather.

I want to sit in that for a second before I tell you why it matters, because the reflex is to assume this is some backwater shop that never made it to the cloud.

It’s the opposite. This is one of the more mature engineering organizations I’ve worked inside. Real cloud footprint. Real CI/CD. A funded, active security function. By every artifact you’d point at to prove an org has done its transformation, this org is ahead of most of the F500.

And it can’t keep its developers’ access to documentation working for three months.

The tell isn’t the org that’s behind

Here’s the thing the industry keeps getting wrong about “AI readiness.” Everyone pictures the unready org as the one that’s obviously behind: still on-prem, still ticketing for VMs, no pipeline, no cloud. Those orgs know they’re not ready. They’ll tell you. Their own engineers roll their eyes about it.

The dangerous orgs are the ones that look ready. They have the accounts, the guardrails, the security review process, the org chart with the right titles on it. They can point at all of it and say “we’ve done the transformation, we’re ready for what’s next.” And then they can’t unblock a URL in a quarter.

I’ve started calling this maturity theater: an organization has accumulated all the artifacts of transformation without the capability they were supposed to produce. The capability was never “we have cloud accounts.” The capability was “we can make a technical decision, communicate it across teams, and hold it.” The accounts are evidence you spent the money. They are not evidence you can execute.

Let me give you two more from the same org, because one story is an anecdote and three is a pattern.

Exhibit B: they don’t understand the cloud they transformed onto

I needed an OAuth application approved so an internal tool could integrate with the org’s Confluence and Jira. Routine. I opened a ticket. It got routed to security, as these things do. Security asked about the architecture, and I explained it: documents get pulled into an S3 bucket, then embedded and indexed for retrieval. Standard stuff.

Security denied the request. The stated reason: “we don’t like to allow teams to use S3 buckets.”

Read that again. This is an organization that runs on AWS. S3 is one of the most fundamental, most battle-tested, most ubiquitous services in the entire cloud they supposedly transformed onto. And the security function governing that cloud both (a) treats S3 as an exotic risk to be denied by default, and (b) missed that the request wasn’t even asking to provision a bucket. It was asking to approve an OAuth app. They denied a request they didn’t understand, on the basis of a service they didn’t understand, inside a cloud they’d already adopted.

The point isn’t that they made one wrong call. Everyone makes wrong calls. The point is who was making it. The people staffed to govern this org’s move into the AI era can’t reason about the primitives of the cloud era they’re allegedly already through.

Exhibit C: the governance broke the governance

Same org, earlier. The security team decided to roll out Service Control Policies, the AWS mechanism for setting hard guardrails across accounts. Good instinct. SCPs are exactly the kind of control you want in place before you let AI anywhere near your environment.

They rolled them out org-wide with no communication and no coordination. The SCPs broke account functionality across teams. They also broke Control Tower itself, the very service AWS provides to manage multi-account governance. The guardrail rollout was executed so poorly it damaged the tool that exists to execute guardrail rollouts.

The resolution? They moved the affected accounts into unmanaged OUs, organizational units with zero SCPs applied. The fix for “we broke governance” was to remove governance entirely. Take a breath and appreciate the full arc: an org tries to add controls, breaks itself doing it, and resolves the breakage by deleting the controls. That’s not a security practice. That’s the appearance of a security practice, thrashing.

Now put AI on top of that

Here’s why I’m not just venting about a client.

Every one of these stories is survivable on its own. Blocked npm docs are annoying, not catastrophic. A wrongly denied OAuth app gets escalated eventually. Botched SCPs get rolled back. None of these took anyone down.

But this is the org that is right now being told to adopt AI. Mandate the tooling, measure the seat counts, point the agents at the codebase, ship faster. The same leadership that couldn’t restore documentation access in a quarter, the same security function that denies S3 by reflex and breaks Control Tower with its own guardrails: that’s the org now standing up autonomous code generation on top of the exact environment that produced these three stories.

I’ve written before about why the pull request is the guardrail: why AI agents deleting production isn’t an AI problem, it’s a pipeline-and-permissions problem the industry already solved and forgot. And I’ve written about the missing middle between banning AI and mandating it with no governance. Both of those are about the mechanism. This is about something upstream of the mechanism.

You can hand an org every guardrail in the DevSecOps playbook, and it will not matter if the org cannot make a decision, communicate it, and hold it. The npm outage is proof of the failure mode in miniature: a decision was made, half-communicated, never held, and quietly worked around until everyone forgot it was broken. Apply that exact organizational reflex to agentic code generation and you don’t get a blocked docs site. You get incidents that arrive faster than the org’s demonstrated ability to respond to anything.

AI doesn’t create the readiness gap. It’s a forcing function that converts a gap you were surviving into a gap that surfaces as an outage. The npm story stretched out over three months because the blast radius of blocked documentation is small and slow. The blast radius of autonomous agents inside an environment governed by the same people who denied S3 is neither.

The readiness test nobody runs

So here’s the diagnostic, and it has nothing to do with your architecture diagram.

Go find the last meaningful cross-team decision your security or platform org made. Not the last one they announced. The last one they actually made. Is it still holding today? Or did it quietly get worked around, rolled back, or forgotten because nobody owned it past the announcement?

That’s the whole test. Go back to the npm story: the decision to restore access was made. It was announced, with a date attached. And then nobody carried it past the announcement, so it simply didn’t happen. The deadline was the org’s own, the fix was trivial, and the only thing the situation required was follow-through. An organization that can’t make that decision stick is not ready for a technology whose entire value proposition is doing things faster than a human would. The maturity that matters isn’t in your account structure. It’s in whether the organization can make a decision and keep it made. Most can’t. They’ve been getting away with it because the old failure modes were slow enough to absorb.

The ones pointing at their cloud accounts as proof they’re ready are the ones I’d worry about most. They’ve mistaken the receipt for the meal. And AI is about to present the check.

Related reading

• Your Pull Request Is the Guardrail — why AI agents deleting production is a pipeline-and-permissions problem the industry already solved.
• Two Extremes, One Missing Middle — the space between banning AI and mandating it with no governance.
• 5 Signs Your AI Initiative Is Going Nowhere — how AI programs fail quietly instead of loudly.