Paul Zimmerman
INV Group Chief Communications Officer
15 May 2026
On 14 May 2026, Ed Ireson, Technical Operations Lead at Invuse, attended the AI Security Summit in London, a practitioner-focused event exploring how real AI systems break, how they can be exploited, and how organisations can secure them in production.
For Ed, the value of the event was clear. AI security is moving quickly. Traditional security and compliance disciplines still matter, but AI introduces new behaviours, new attack surfaces and new operational risks.
“It’s a new space,” Ed said. “There’s new things happening all the time. We were discussing things that had happened in just the last month.”
That pace matters. Organisations are already moving from AI experimentation into real workflows, internal tools and agentic systems. But as AI becomes embedded into operations, the challenge is no longer just whether the model works. It is whether the whole system can be trusted, observed and governed.
Red teaming cannot be a one-off exercise
One of the strongest themes from the summit was the need to rethink red teaming.
In traditional security, red teaming can sometimes be treated as a defined event: a focused test, run by specialists, against a known system. But Ed’s takeaway was that this approach is not enough for AI.
“Red teaming is continuous,” he said. “Especially in an AI context, where these AI tools are available to the whole organisation.”
That changes the responsibility model. AI systems are not only used by engineers. They may be used by HR teams, business analysts, service teams, content designers, customer contact teams and operational staff. Those users will all interact with AI systems in different ways.
Ed’s view is that organisations should encourage teams to approach AI tools with a more critical security mindset.
“You should be encouraging your HR teams, your BA teams, to give it bad data or ask irrelevant questions and see how it responds,” he said.
That is an important shift. AI security is not only a technical control. It is also an organisational habit.
Shadow AI is already creating risk
The summit also explored the issue of shadow AI: staff using unauthorised tools, public AI services or self-built workflows outside approved channels.
For Ed, the risk is clear. If people are experimenting without business sign-off, the organisation loses visibility. It may not know what data has been entered, what outputs are being relied upon, or what decisions are being influenced.
“There are workers using unauthorised AI tools, experimenting and building things without business sign-off,” Ed said. “This presents real security risk to organisations.”
This is particularly relevant for public sector organisations. Councils, government departments and NHS bodies handle sensitive data, complex services and high levels of public accountability. If AI usage is happening out of sight, then risk is also happening out of sight.
The answer is not simply to block everything. In many cases, that may push usage further underground. The better route is to create safe, visible and governed ways for people to use AI responsibly.
Governance needs to cover the whole AI system
A key message from the summit was that AI governance cannot stop at the headline agent or chatbot.
Ed noted that organisations may start with a compliance register for agents or workflows. But they also need to understand the smaller components that sit underneath them.
“You might think about having a compliance register for your agents or your flows,” he said, “but also actually thinking about having a register of your skills.”
That is a useful distinction. In an agentic system, risk may sit in the model, the prompt, the tools, the skills, the MCP server, the data source, the permissions layer or the workflow around it.
A named agent may look simple to the business. Underneath, it may be made up of many interacting parts.
This is where governance becomes practical. Organisations need to know what is running, what it can access, what controls apply, what data it uses, and how its behaviour is monitored.
Simple AI workflows can become complex very quickly
One of the most striking examples from the day concerned observability.
Ed described a relatively simple AI workflow with only a small number of LLM calls. But once the possible paths were traced, the system had more than 1,000 potential routes.
That matters because AI systems can behave differently depending on the prompt, the user, the data source, the tool call, the context and the permissions available at the time.
“I think observability is huge,” Ed said.
For public sector organisations, this is crucial. Leaders do not necessarily need to understand every technical detail of the underlying model. But they do need confidence that their organisation can see what the AI system is doing.
As Ed put it, public sector bodies need vendors that can give them “confidence in that operational visibility.”
Secure AI development needs enforceable controls
One of Ed’s most practical technical takeaways was the role of hooks in secure AI coding.
He explained that while an LLM may decide whether to use a skill, tool or MCP server, a hook can be designed to run every time.
“The hook runs on every call. It runs on every prompt,” he said. “So if you need controls that run on every prompt, that’s what you should be using hooks.”
For technical teams, this is an important idea. Secure AI development will increasingly depend on building controls into the development and runtime environment, rather than relying only on guidance or good intent.
That could include controls around code generation, data access, external calls, prompt handling, output validation and logging.
The model itself is part of the risk
Another important lesson from the summit was that AI risk does not only come from malicious attackers.
Ed reflected on a talk that described several attack surfaces for coding agents, including supply chains, skills, MCP tools and the agent itself.
“The fourth attack surface is the agent itself,” Ed said. “The LLM can hallucinate.”
That means organisations need to think about AI systems differently. A system can fail because someone attacks it. But it can also fail because the model produces a plausible but wrong answer, misuses a tool, deletes something it should not delete, or takes an unexpected action.
This is why AI assurance needs to include testing, monitoring, output validation, permissions, human oversight and incident response.
Public sector organisations should start with the data
When asked what advice he would give to a council or government body experimenting with AI but lacking mature governance, Ed’s answer was direct.
“You really need to understand what data is in the system, and what can access that data,” he said.
He gave a simple example. If an AI agent is designed to answer questions from an internal policy knowledge base, does it need access to the internet? If not, why allow it?
This is the kind of practical question every organisation should be asking before AI systems are put into real workflows.
- What data can the system access?
- Where can that data go?
- Can the system call external services?
- Can it write to internal systems?
- Can it act on behalf of users?
- Can its outputs be reviewed?
- Can its behaviour be audited?
These are not abstract governance questions. They are operational security questions.
Governance has to come first
For Ed, the clearest conclusion from the summit was that AI security and governance need to be built into the foundations.
“Security and governance has to be the start of an organisation’s AI process,” he said. “Because you can move so rapidly with AI, the threat models and the risks are changing all the time.”
That is the central lesson for organisations moving from AI pilots to production systems.
AI creates speed. But without the right foundations, that speed can amplify risk.
For INV Group, Invuse and Invotra, this reinforces a core belief: safe AI adoption depends on more than innovation. It depends on visibility, control, assurance and governance designed into the system from the beginning.
As public sector organisations begin to explore agentic AI, automated workflows and AI-assisted services, the question is not simply whether AI can help.
The question is whether it can be deployed safely, securely and responsibly.
And that starts before the first prompt.