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.

AI is everywhere, not just where you deployed it

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.

The supply chain is longer than it looks

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.

Excessive agency is a design choice, not an accident

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.

Governing agents built outside the software development process

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.

Runtime misbehaviour nobody tested for

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.

Each layer needs its own control — but they can't work alone

None of these five challenges — surface sprawl, supply chain depth, excessive agency, ungoverned agent creation, and runtime misbehaviour — 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.

Key takeaways

Cyber Resilience Programme activities

techUK brings together key players across the cyber security sector to promote leading-edge UK capabilities, build networks and grow the sector. techUK members have the opportunity to network, share ideas and collaborate, enabling the industry as a whole to address common challenges and opportunities together. Visit the programme page here.

Upcoming events

Latest news and insights

Learn more and get involved

Cyber Resilience updates

Sign-up to get the latest updates and opportunities from our Cyber Resilience programme.

Meet the team

Jill Broom

Head of Cyber Resilience, techUK

Jill leads the techUK Cyber Resilience programme, having originally joined techUK in October 2020 as a Programme Manager for the Cyber and Central Government programmes. She is responsible for managing techUK's work across the cyber security ecosystem, bringing industry together with key stakeholders across the public and private sectors. Jill also provides the industry secretariat for the Cyber Growth Partnership, the industry and government conduit for supporting the growth of the sector. A key focus of her work is to strengthen the public–private partnership across cyber to support further development of UK cyber security and resilience policy.

Before joining techUK, Jill worked as a Senior Caseworker for an MP, advocating for local communities, businesses and individuals, so she is particularly committed to techUK’s vision of harnessing the power of technology to improve people’s lives. Jill is also an experienced editorial professional and has delivered copyediting and writing services for public-body and SME clients as well as publishers.

Email:: [email protected]
Website:: www.techuk.org/
LinkedIn:: https://www.linkedin.com/in/jill-broom-19aa824

Read lessmore

Annie Collings

Senior Programme Manager, Cyber Resilience, techUK

Annie is the Programme Manager for Cyber Resilience at techUK. She first joined as the Programme Manager for Cyber Security and Central Government in September 2023.

In her role, Annie supports the Cyber Security SME Forum, engaging regularly with key government and industry stakeholders to advance the growth and development of SMEs in the cyber sector. Annie also coordinates events, engages with policy makers and represents techUK at a number of cyber security events.

Before joining techUK, Annie was an Account Manager at a specialist healthcare agency, where she provided public affairs support to a wide range of medical technology clients. She also gained experience as an intern in both an MP’s constituency office and with the Association of Independent Professionals and the Self-Employed. Annie holds a degree in International Relations from Nottingham Trent University.

Email:: [email protected]
Twitter:: anniecollings24
LinkedIn:: https://www.linkedin.com/in/annie-collings-270150158/

Read lessmore

Olivia Staples

Junior Programme Manager - Cyber Resilience, techUK

Olivia Staples joined techUK in May 2025 as a Junior Programme Manager in the Cyber Resilience team.

She supports the programs mission to promote cyber resilience by engaging key commercial and government stakeholders to shape the cyber resilience policy towards increased security and industry growth. Olivia assists in member engagement, event facilitation and communications support.

Before joining techUK, Olivia gained experience in research, advocacy, and strategic communications across several international organisations. At the Munich Security Conference, she supported stakeholder engagement and contributed to strategic communications. She also worked closely with local and national government stakeholders in Spain and Italy, where she was involved in policy monitoring and advocacy for both public and private sector clients.

Olivia holds an MSc in Political Science (Comparative Politics and Conflict Studies) from the London School of Economics (LSE) and a BA in Spanish and Latin American Studies from University College London (UCL).

Outside of tech, Olivia enjoys volunteering with local charities and learning Norwegian.

Email:: [email protected]

Read lessmore

Navigating implementation complexity: scaling AI without the friction

AI is everywhere, not just where you deployed it

The supply chain is longer than it looks

Excessive agency is a design choice, not an accident

Governing agents built outside the software development process

Runtime misbehaviour nobody tested for

Each layer needs its own control — but they can't work alone

Key takeaways