Why Sophos Has Become Its Own AI Test Lab

Every security vendor will tell you about the AI in their products. Far fewer will tell you how their own people use AI — which agents run in their engineering pipelines, what data those agents can touch, and who decided that was acceptable. That second conversation, in our view, is as important. When you onboard a vendor, you don't just inherit their software; you inherit their judgment. So here is how Sophos adopts AI internally: how we think about the risks, how we govern them, and where we're still learning.

Why we run at the leading edge

It would be easy for a security company to be the cautious one — to let others make the mistakes and write up the lessons afterwards. We've deliberately taken the opposite position: for Sophos, the greater risk is standing still. Our customers are deploying AI agents in production now. If we want to keep protecting them, we have to understand the risks firsthand — ideally before they encounter them.

We run AI in production because you cannot defend against what you've never operated. The prompt-injection paths, the over-privileged tool calls, the non-human identities that quietly accumulate access — these only become intuitive once you've run agents against real work, watched them fail, and instrumented the failures. It's why we point agentic tooling at our own estate before anyone else's: we've let an autonomous agent framework loose on an internal network to see what it could reach, used frontier models to hunt for vulnerabilities in our own products before adversaries get the same uplift, and rethought what bug bounties look like when AI finds the bugs. Everything we learn improves the detections we ship and shapes where the product roadmap goes next, in order to support our customers.  

This holds for the whole company, but doubly for the security team. If a security team can't work out how to adopt AI safely and quickly, it's hard to see who will. A CISO organisation that bans what it doesn't understand risks understanding very little within a couple of years. And with an AI-accelerated vulnerability flood already arriving, the defenders who've built that understanding will be the ones who cope.

How we think about risk: a compass, not a checklist

Running at the front without judgment is just recklessness. Internally, our risk philosophy fits on a page and is summed up in six words: take smarter risks, deliver faster, earn trust. The core of it is a distinction between good risks and bad ones. Good risks have meaningful upside, a contained blast radius, a reversible path, a named owner, and a hypothesis we'll actually learn from. Bad risks have unbounded harm, no recovery plan, unclear ownership — or they skip human judgment: automated or agentic changes that directly touch customers without sufficient oversight are a bad risk regardless of the upside on offer.

Most decisions don't announce themselves as either. So we map every bet onto a simple compass — two axes: upside (high or low) and downside (contained or unbounded).

Figure 1: Sophos’ risk compass

The reality is that most of today's agentic AI bets start in the top-right quadrant: high upside, unbounded downside. The discipline is to shrink the blast radius until they move left:   read-only before write, internal before customer-facing, one workflow before a fleet. The work is in the de-risking, not the gatekeeping. Around the compass sit five non-negotiables — customer trust, safety, security, privacy, and operational stability — with legal and compliance woven through each. Being uncompromising about those is precisely what lets us be aggressive everywhere else. When you evaluate any vendor's AI posture, this is the structure worth looking for: a clear framework for saying yes, anchored by explicit boundaries for saying no.

The AI Safety Board: governance at the speed of adoption

A framework only matters if decisions actually get made with it. AI use cases were arriving faster than any traditional governance cycle could process, and they rarely fit the shape of a classic vendor assessment or security review. Our answer is the AI Safety Board: a small, cross-functional group of practitioners — security, engineering, product, IT, legal, HR, and customer facing teams   — chaired by me as CISO. It is decision-oriented by design: a thirty-minute monthly meeting, the real work happening asynchronously, and a remit to make fast, practical calls on novel or high-risk AI use — new tools, agentic workflows, emerging risk patterns.

Crucially, the board sits above our vendor-risk and security-review processes rather than replacing them. Those pipelines keep handling the well-understood cases at volume. When something novel or genuinely ambiguous surfaces — an agent with an unusual privilege profile, a use case with no precedent — it gets referred up, and the board's answer flows back down as standing guidance, updated in near-real time. The framing we use internally: if you're unsure how to do something with AI, use existing channels; if you're unsure whether you should, ask the board. Tools and patterns get a deliberately simple categorisation — allow, investigate, tolerate, deny — kept lightweight and revised as we learn.

Where the board spots patterns of similar requests, it writes policy that defines a boundary rather than enumerating tools. Our first standing policy covered local AI models: anything meeting the “data doesn't leave the device” boundary no longer needs a per-tool security review. When that policy went live, we closed out the queue of individual review tickets it superseded. Governance that shrinks the review backlog earns a very different reputation from governance that grows it.

And because we should practice what we preach, the board itself runs AI-natively. A shared AI agent acts as its administrative arm: it summarises discussions, tracks actions and nudges owners, drafts agendas, policy write-ups, and company-wide communications, and proactively surfaces interesting AI-related submissions from the review pipeline alongside relevant external incidents. Every external-facing output is approval-gated — the agent drafts, a human board member approves before anything is published. The senior people spend their time on judgment; the agent absorbs the logistics. It is, deliberately, a live demonstration of the operating model we're asking the rest of the business to follow. If you're a customer wondering how a new AI use case at Sophos gets approved — this is the mechanism, and the speed it runs at.

The hard part: the security patterns are still forming

Here's the part vendors don't usually say out loud: nobody has fully worked out the security patterns for this yet — including us. Engineering teams are further along. Clear development patterns are emerging for building with AI. Security teams have no equivalent playbook yet. How do you security-review an agentic workflow that rewrites itself weekly? What does incident response look like for a compromised agent? How do you monitor a fleet of non-human identities that act rather than merely suggest? Right now those questions are mostly answered with judgment, not patterns — and pretending otherwise helps nobody.

I wrote about one slice of this gap in Operating inside the lethal trifecta: the most useful agent deployments combine private data, untrusted content, and external communication — exactly the combination that makes prompt injection dangerous — so the practical discipline is blast-radius reduction rather than pattern purity. Internally that means treating agentic environments as a first-class security surface — centralised governance of AI platforms, telemetry across agent activity, detections for anomalous agent behaviour — designed in from the start, not bolted on after. We'll keep publishing what works and, just as importantly, what doesn't.

Unfortunately, our attempt to offer some technical risk mitigations also underlined how complex a problem this is. As our CEO Joe Levy wrote recently about the cybersecurity poverty line, of roughly 359 million businesses in the world, fewer than 35,000 employ a CISO. The blast-radius engineering in the lethal trifecta approach is exactly the kind of heavy lifting organisations below the line, without a CISO or equivalent, cannot staff. That reality shapes our product work too: much of the thinking behind Sophos Fusion is about embedding that judgment into the defence system itself, so organisations that can't do the engineering aren't left choosing between banning AI and being exposed to it. But that's a different article. The point here stands on its own: the patterns are emerging — and we'll keep sharing ours as they form.

What this means if you're evaluating us — or anyone

None of this is an argument that Sophos is finished figuring AI out; it's an argument that we're figuring it out deliberately, in the open, ahead of the threat rather than behind it. If you're weighing up any vendor — us included — the AI questions worth asking aren't about model names. Ask who decides when a new AI use case is acceptable, and how long that decision takes. Ask what they won't let AI do, and whether they can name the boundary. Ask what they've learned from an AI experiment that failed. Vendors who've thought this through tend to have clear answers; those that have simply banned AI, or simply unleashed it, often don't.

We've written before about the high cost of low trust, and this piece is part of the same commitment: showing our working, not just our conclusions. Smart risks compound. So does trust — and both are earned the same way: deliberately, transparently, and in public.