Navigating implementation complexity: Scaling AI without the friction
Once an organisation has real visibility into its AI usage, a different problem shows up — one that’s easy to underestimate. Scaling AI isn’t hard because the models get bigger or the use cases get more ambitious. It’s hard because AI risk was never really about a model’s inputs and outputs in the first place. That framing made sense when AI meant a single API call and a single response. It doesn’t hold up anymore.
What I’ve come to believe, watching organisations move from pilot to production, is that AI isn’t one system to protect — it’s an ecosystem to secure. That ecosystem doesn’t have one attack surface; it has several, each maturing on its own timeline. Scaling AI means scaling your ability to secure all of them at once, without any one becoming the reason the whole initiative stalls.
The first thing that makes scale genuinely hard is that AI doesn’t stay where you put it. It shows up inside SaaS applications your teams already use, it rides along in browser extensions, it gets installed on developer laptops as a coding assistant, and it gets wired into internal tools nobody centrally tracked. AI is creeping into the enterprise across nearly every digital surface simultaneously — not because anyone is being reckless, but because that’s simply where the productivity gains are, and people will follow them.
This means the perimeter you’re used to thinking about doesn’t really exist anymore. You’re not securing “the AI system.” You’re securing every point where AI capability has quietly embedded itself into how work already gets done.
Every AI system an organisation deploys — model, plugin, dataset, agent framework — was built on top of something else. That dependency chain is often deep, frequently opaque, and rarely fully mapped by the team consuming it. A model fine-tuned on a public dataset, wired into a plugin marketplace, calling out to a third-party API: that’s four separate trust boundaries stacked on top of each other, and a weakness in any one of them becomes a weakness in the whole chain.
Supply chain risk in AI isn’t a future concern — it’s already the present one. Treating a model or an agent framework as a trusted black box because it came from a reputable-sounding source is exactly the assumption that’s proven costly in traditional software, and there’s no reason AI tooling is exempt from the same lesson.
As AI moves from answering questions to taking actions, the risk shifts from “what did it say” to “what was it allowed to do.” Many AI agents are granted permissions far broader than the task actually requires — access to file systems, internal APIs, customer data, or other agents — simply because it’s easier to grant broad access up front than to scope it precisely.
It’s the same excessive-permissions problem security teams have fought for decades with human and service accounts, except now it’s happening at the speed and volume of agent deployment — far faster than any manual access review was built to handle. An agent with more capability than its task requires isn’t a convenience — it’s a latent risk sitting quietly until something goes wrong.
Perhaps the hardest shift to grapple with: a huge volume of the agents now running inside organisations weren’t built by software development teams at all. Low-code, no-code, and “vibe coding” platforms have put agent creation into the hands of teams across the business — operations, marketing, finance — who are genuinely good at their jobs but were never trained to think about injection vulnerabilities, credential handling, or secure data flows.
That’s not a criticism of those teams. It’s a structural governance gap. The traditional software development lifecycle came with checkpoints — code review, security testing, change management — that assumed the builder understood the risks they were introducing. When agent creation moves outside that lifecycle, those checkpoints don’t automatically come with it. Volume and velocity of agent creation is now outpacing the organisation’s ability to even know an agent exists, let alone govern it.
Even a well-built, well-governed agent can misbehave once it’s live — not because it was compromised, but because it misreads intent or reaches for a capability in a way nobody anticipated. Agentic systems interpret ambiguous instructions, chain tools together, and make judgment calls in real time. Sometimes those judgment calls are wrong: a tool gets invoked in a context it wasn’t meant for, an instruction gets over-interpreted, a capability gets used in a way that’s technically permitted but never intended.
This is a fundamentally different failure mode than a traditional software bug, because the system did exactly what it was designed to do — reason and act — and still produced an outcome nobody wanted. You can’t test your way out of this category of risk before deployment; you have to be able to observe and constrain it while the system is running.
None of these five challenges — surface sprawl, supply chain depth, excessive agency, ungoverned agent creation, and runtime misbehavior — is solved by the same control. Each genuinely needs its own defense, built for how that layer actually fails.
But treating them as five separate problems, addressed by five disconnected tools, creates its own risk: gaps at the seams, inconsistent policy, and a security team that’s now managing complexity instead of reducing it. The controls need to work together as a coherent platform, not as a pile of point solutions bolted on as each new risk surfaced.
And critically, all of this has to happen inside the actual flow of work — where teams are already building, deploying, and using AI — rather than as a separate process people have to step outside their job to comply with. Controls that add friction get bypassed. Controls that sit invisibly inside existing workflows are the ones that actually hold up at scale, and they’re also what lets an organisation keep accelerating adoption and innovation rather than trading one for the other.
