Richard Terry-Lloyd
A dense field of small grey app tiles spread across the left of a dark slate field, each one trailing a faint line that converges on a single tall amber control-plane bar standing upright through the middle of the frame. The bar carries five lit gate slots; five approved builds pass through as bright amber nodes and fan out to a wireframe globe on the right, while two dark tiles are held against the bar's left face under a small amber hold mark. A dashed amber audit line with regular tick marks runs the full width beneath everything.
Back to blog

8,000 Companies, and No One Knows What's Live

·Richard Terry-Lloyd
GovernanceSecurityAIPlatformEnterprise

We have 8,000 companies with 10 or more teams building on Netlify right now.

Most of them don't have a relationship with us yet.

These aren't the teams you'd expect

They're not all traditional development teams. They're people across the entire organization — Sales, Marketing, Support, IT, Engineering — all building apps on Netlify.

We can see it happening. They often can't.

We can see how our customers are scaling their sites and growing as their agents run in production.

The interesting part is that many of those companies probably couldn't tell you what's live on their own domain, what AI is being used, or whether that AI has even been approved.

That's the problem.

AI is making it possible for anyone inside a company to build and deploy software. The number of builders is exploding, but the controls haven't caught up.

Mathias and I talk about this all the time.

The answer isn't governance after the fact

It's having a control plane in place at the moment something gets deployed.

The most successful companies are the ones that put governance in place from the beginning, as part of their AI rollout:

  • What's being deployed?
  • Which models and agents are being used?
  • Have they been approved?
  • Who has access?
  • What domain is it running on?
  • Should it be allowed to go live?

These controls need to exist before something reaches production, not after the security team discovers it.

What that looks like in practice

  • Domain controls, so nothing goes public before you say so.
  • Access managed through directory sync with the identity systems your security team already runs.
  • Deploy gates that stop a build before it reaches the web.
  • Visibility into which models and agents are running, and where.
  • Approval that happens at deploy time, not in a quarterly review.
  • An audit trail across everything that gets built and shipped.

None of that asks the builder to become an expert in the thing they came here not to think about. That's the whole point of putting the guardrails in the platform rather than in a policy document.

Why this is a genuinely different problem

As agents make software creation available to more people across the enterprise, this becomes a fundamentally different governance problem.

You can't govern thousands of builders by trying to keep track of every application, agent, and model after it has been deployed.

The scale is already visible in the deploy data. Team sprawl inside a single company is the tell, and it shows up long before anyone above those teams knows it's happening.

Both things at once

You should be able to build fast and safely at the same time.

That's not a tradeoff to be managed. It's a property of where the controls live.