Integrity by Design in the AI Tool Call Age
Or how anyone can apply AI safety techniques
I recently had the pleasure of being hosted at South Hampshire College Group to speak about AI safety. I wanted to make the process available on my Substack, so attached is my talk about how certain modern AI Safety techniques work.
I believe a lot of AI needs to be adopted in ways that work, looking past the hype cycles, so this talk was all about how we can design processes in better ways.
In my main role, I work in the civil nuclear space, building human-in-the-loop AI for decommissioning and industrial process optimisation. I care about AI adoption, which is why I think so much of the conversation can become dangerously sloppy!
Here’s a short overview of what I covered:
AI Has Left The Chat Window
Most people still think of AI and think a ChatGPT chat window. You type a question, you get an answer.
But really, that’s ignoring the entire history of AI applications. This was 2022, and we’ve moved on seriously since then. Since late 2024, with the rise of MCP, skills, tools like google studio - AI began to call tools:
Querying databases, reading emails, running API requests. In 2026 we’ve seen the rise of the autonomous agents like OpenClaw. Reading files, writing code, managing desktop applications with minimal human oversight.
Each one of these steps gives AI more capability and larger attack surfaces.
But the adoption is real, and unlikely to dissipate. Claude Code went from research preview to $1 billion in income within six months. Cowork triggered a $285 billion dollar selloff because of a simple 200 lines of markdown.
It’s easy to catch FOMO. Competitors, suppliers, coworkers are adopting these tools rapidly. The question has began moving from “Should we use AI?” to “How quickly can we adopt and adapt?”
That isn’t the whole story.
In practice, Scale AI Remote Labor Index has tested 240 freelance projects worth over $140k. Of the project included, only around 3.75% have been automated to a professional standard.
Let’s not move the goalposts too far, that is genuinely impressive for end-to-end project automation. But it shows the current level of hype cycle that’s pushing a ton of businesses towards bad options:
Either invest in unproven automation, giving AI broad access to business systems without boundaries
Or ignore it entirely, while competition moves ahead.
There’s a smarter option, using what’s proven, adding guardrails, skipping the hype train.
A quick foray into how AI works: Memento
There’s a critical thing most people get wrong about LLMs. While we’ve had the rise of recursive self improvement, most of the core architecture behind LLMs still hasn’t changed.
They work similarly to Leonard in Memento, if you haven’t seen the movie, it’s all about a man who has to re-learn every day via notes and polaroids. In a way, this is still how LLMs work. They have a permanent anterograde amnesia.
The model that you use when you open up Gemini or ChatGPT is essentially stateless. It doesn’t learn from conversations, it relies entirely on rebuilding an entire conversation based on the notes you’ve fed it.
This is where problems like context rot begin to arrive. While model context windows have been rising significantly over the past few years, most models still contain a significant performance U-curve in the form of context rot.
This will only get worse with the rise of agentic systems with more noise. Claude Code Opus has a million-token context window. The more you feed it, the less reliably it’ll follow your rules.
Currently, this is a baked in potential security flaw.
Insecurity within LLMS
OWASP still has prompt injection as the top potential vulnerability within LLMs. And while Anthropic and other AI companies have been performing a lot of work in reducing classical prompt injection (Anthropic has gone down to a 1.4% for successful browser prompt injection from 10.8% for previous Opus) - a probabilistic LLM is always going to have a cat and mouse game of fixing prompt injection.
You can fix SQL injection because we can properly parametrise inputs. With LLMs, instructions, data and outputs from tool calls are all the same, as a property of the architecture. Every document, email and API response is a potential attack vector.
We’ve seen it recently against Claude in January 2026, a poisoned tool library tricked a desktop agent into sending private data through a whitelisted API domain.
OpenClaw & System Exfiltration
OpenClaw is a brilliant tool, while also being a cautionary tale worth telling. Within a week of release, 1842 control panels were found online via Shodan, created by agents. 62% of these were unauthenticated. 35,000 email addressed got leaked through a misconfigured database.
A lot of these figures are due to over-optimism, letting the model run with zero context hygiene, with untrusted access and no reduced privilege controls. The lack of tool vetting meant hundreds of malicious skills could turn up in the plug-in registry.
A lot of these issues are not fundamental adoption issues, they’re FOMO triggered by a lack of operational hygiene. I won’t go too in-depth (you can invite me for a talk for that). But the traditional methods of RAG citation management apply slightly less importantly. Here’s a perfect example from Google, summarising my skillset:
Really, there’s three core things that are important and easily achievable today, even as you slide into the tool adoption era of AI:
Actually Audit Your Tools: Every plugin/skill/tool/MCP server is a third party. Read source, if you wouldn't trust clicking a random .exe/bash script that runs those same commands, you probably shouldn’t trust an agent to do it.
Agents don’t need your secrets: Private keys and credentials should never exist inside an agent’s context. An agent can call tools without seeing your entire API key exposed. Use secret managers and workflows. LLMs just need to have the ability to call your tools, not to see your full API suite.
Verify claims: Don’t trust agent output. Factual claims need deterministic checks outside of the model. You can use a source verifier like GPTZero, or just check manually.
Those are three things that are simple to integrate, and may save you a large scare, don’t need budget, massive size, or much else for that matter.