Jeremy Powell, Chief Information Security Officer at Sumo Logic: “If you can’t answer ‘Did this get better this week?’ with a number, you don’t have an AI strategy”

With 30 years of expertise spanning cloud, data centres, product development and security, Jeremy Powell has watched the technological industry go through several periods of significant transformation. Today, working as Chief Information Security Officer at Sumo Logic, this lends him the perfect vantage point to watch as AI transforms the industry.

If you take nothing else from this interview, we recommend you follow his three rules (listed in the main interview) on what to look for before buying from a SaaS vendor.

For Jeremy, one of the greatest benefits of having spent three decades in the tech industry is is being able to spot when innovation gets carried away. One example is the industry’s increasing focus on autonomous agents and AI-generated code. “Generate three times the code and you have tripled the review queue and the attack surface, not the throughput,” Jeremy points out in our interview.

And bear in mind that you can hardly call Jeremy an AI-sceptic. Before Sumo Logic, he was Chief Technology Officer at LockThreat, an AI-native governance, risk and compliance platform. He previously served as Chief Information Security Officer at Verint, and has held senior leadership roles – across cloud infrastructure, networking and security – at several enterprises.

With this background, it’s perhaps unsurprising that he’s wary of AI’s security implications. With businesses now giving AI agents credentials of their own, creating new identity-management issues, Jeremy’s warning is understandably blunt: “We spent 15 years cleaning up service account sprawl. We just recreated it, except this one improvises and has access to too many variables.”

Jeremy says the same principle applies when looking at the rapidly expanding market of AI-powered SaaS products. For example, whether the AI can actually take action rather than simply summarise information. “Read-only AI is a summariser, and summarisers are a feature, not a business,” Jeremy argues. But once AI has the ability to act, the company behind it must own the consequences when it gets something wrong.

So, the question remains as to how much AI really is changing the world of software. Which leads us nicely into the start of our interview, Conversations on AI.

Everyone says AI is transforming software. Where is the industry still overestimating its impact, and where is it underestimating it?

The industry is overestimating autonomy and underestimating accountability. Every vendor demo shows an agent closing a ticket end to end. In production, the interesting five percent – the ambiguous, the novel, the adversarial – still lands on a human, and that human now has to reconstruct reasoning they didn’t participate in. We automated the work and left the judgment, which was the expensive part.

The bigger overestimate is code generation. Typing was never the bottleneck. Review, integration, and ownership were. Generate three times the code and you have tripled the review queue and the attack surface, not the throughput.

Where the industry is badly underestimating AI: offence and identity. Tailored social engineering used to cost an attacker time. Now it costs nothing, and the bad grammar we spent a decade training users to spot is gone. Meanwhile every agent you deploy is a new principal with credentials, standing access and no lifecycle.

Cloud Security Alliance research this spring found 92% of large enterprises lack full visibility into their AI identities, and only 16% govern that access effectively. We spent 15 years cleaning up service account sprawl. We just recreated it, except this one improvises and has access to too many variables.

Many SaaS vendors now describe themselves as “AI-powered.” What actually separates companies creating real customer value from those simply adding AI features?

Three questions, and I ask all three as a buyer before I ask them as an operator.

First: what grounds the output? If the answer is “a frontier model,” I’m buying a wrapper, and I can buy that directly for less. If the answer is proprietary telemetry, customer-specific context, and a feedback loop that improves the more the customer uses it, that’s a product.

Second: show me the eval. Real teams have a harness, a regression suite, and a number they’re embarrassed by. Marketing teams have a demo. If a vendor can’t tell me their false positive rate and how it moved last quarter, they haven’t measured it – which means they don’t know.

Third: does it write, or only read? Read-only AI is a summariser, and summarisers are a feature, not a business. The value is in taking action, and taking action means owning the blast radius when you’re wrong. Most “AI-powered” vendors want the pricing power of automation with the liability of a chatbot. The disclaimer at the bottom of the output tells you which one you bought.

What is the biggest misconception enterprise customers still have about adopting AI within business-critical software?

That the risk is the model. The model is the least interesting part of the attack surface. The risk is the plumbing around it: the retrieval layer, the connectors, the tool permissions the agent inherits, and whether any of it emits a log you can actually investigate afterward.

The failure I see most is entitlement collapse. An enterprise spends years building a careful permissions model, then indexes everything into one vector store for retrieval and hands it to an assistant running as a service account. Congratulations — you built a very fast, very polite insider threat. Ask a vendor how retrieval enforces your ACLs at query time and watch the room get quiet.

Second misconception: “we don’t train on your data” is not a control. It’s table stakes, and it tells you nothing about inference-time data flow, retention, subprocessors, or whether an attacker can plant instructions in content your agent reads.

Third: they treat this as a procurement event. One questionnaire, one approval, done. The model underneath you changes on the vendor’s schedule. What you assessed is not what’s running.

Do you see the future as applications becoming collections of intelligent agents, or will conventional interfaces remain central?

Both, and the boundary is predictable once you stop thinking about capability and start thinking about reversibility. Agents win where work is high-volume, low-ambiguity, and undoable. Deterministic interfaces survive wherever an action is irreversible, regulated, or needs a name attached to it.

In my world that line is sharp. Triage, enrichment, correlation, working out which of forty alerts share an indicator – hand it to agents, the sooner the better, because humans are bad at that and always have been. Isolating a production host, revoking an executive’s access, notifying a regulator – keep a person and a button.

The “applications become collections of agents” framing skips the hard part: there is no authorization substrate for this yet. Today we hand agents human credentials and human roles, which is how you build a confused deputy that runs at machine speed and never gets tired.

So my bet is that the interface doesn’t disappear, it changes jobs. It stops being where you do the work and becomes where you review and approve what was done. That’s a harder design problem than the one the industry is currently solving, and almost nobody is working on it.

How do you balance innovation with responsible AI? Where do you draw the line between moving quickly and ensuring customers can trust the outputs?

The tension isn’t speed versus safety. It’s speed versus reversibility. I’ll move fast on anything I can see and undo. I’ll move deliberately on anything that touches production or customer data without a human in the path.

Two things are non-negotiable. Auditability: every AI output shows what it was grounded in, so a human can verify in seconds instead of redoing the work. An unverifiable answer costs more than no answer, because now someone has to disprove it. And a hard line on autonomous action – no standing access to production for agents, ever. Time-bound, scoped, just-in-time, logged.

Then we attack it before we ship it. Prompt injection, exfiltration through tool calls, poisoning the retrieval corpus, coaxing it across a tenant boundary. If the team can break it, it ships with a human in the loop until they can’t.

And we’d rather ship a narrow feature that’s right 95% of the time and honest about its confidence than a broad one that’s right 80% and silent about it. Trust is rate-limited. You get about one confident wrong answer in front of a customer’s board before you’re finished.

If you could give one piece of advice to another SaaS executive planning their AI strategy today, what would it be?

Build the eval harness before you build the feature. If you can’t answer “did this get better this week” with a number, you don’t have an AI strategy. You have a demo with a roadmap attached.

The corollary is that the model is not your moat. You are one procurement cycle from swapping it out, and so is every competitor. What compounds is proprietary data, the feedback loop that captures what users actually did with the output, and the evals that let you ship changes without praying. Invest there and the model becomes an implementation detail – which is exactly what you want it to be.

Second piece, and this is the one people skip: decide now, in writing, what you will never let it do autonomously. Write it down while it’s cheap and abstract. Because that decision gets made either way – at 11pm, two weeks before launch, by whoever is closest to the keyboard and furthest behind schedule. I’ve watched it happen at three companies. Governance written under deadline pressure isn’t governance. It’s a rationalization with a document number.

More interviews

About The Author

Rowan Campbell TechFinitive
Rowan Campbell

Rowan is a writer for TechFinitive focusing on technology companies doing interesting things all around the globe. He is currently studying philosophy at university.

Read more from this author.

We take journalism seriously. To learn more on why you should trust us, head to our editorial guidelines page or meet our team.