Digital ID Done Less Badly

2026-11-11T14:48:07+11:00

We lost the war against a Digital ID the moment we all started relying on smartphones. With many jurisdictions bringing in Digital IDs, and just as many of those jurisdictions suffering catastrophic data breaches, there needs to be hard legislation around them in order to force implementations to protect the us, rather than harm us. This article presents an approach to digital ID that is less terrible.

What Is The Problem?</h2>
You start a new job and on the first day, you're instructed to sign into a dozen new online services, handing over a ton of very sensitive information for these fly-by-night apps to store in some undisclosed location until the end of time. Copies of passports, work permits or visas, social security or other credit/tax identifiers, name, address, date of birth. Essentially enough to cause someone decades of trauma and grief when put in the wrong hands.
During your lunch break, you decide to sit at your desk and pay some bills online. In addition to credit card details, you're having to again hand over information that is so sensitive that you need it for almost everything these days.
You go home and want to cleanse your mind of the day's woes and sit down for an hour or two to take the day's news in the only remaining palatable medium -- troll memes. But unfortunately for you, you live in a jurisdiction that is legislated by Neophyte Fuckwits, such as Australia</a>, The UK</a>, The EU</a>, USA</a> and Canada</a>. Because pretty-much anything online can be construed as adult content by the legal department of the website or app, and you're now required to go through an ID check process, which involves a copy of your passport being uploaded to fuck-knows-where, along with a short video of yourself in your underwear doing dance moves from a Village People song to prove it's you in the photo.
You decide to head out for a couple of frosty pints at the local watering hole -- away from the technology that's harvesting your for every impulse and datum. The bouncer at the door wants to see ID. You show him a driver's license. He hands it back and grunts "It's expired". You're still just as human as you were a few days ago, even if your privilege of driving a car is temporarily on hold. If anything, the law would prefer that your driving and drinking don't mix.
As you walk back home, you notice a dozen TVs on in a shop window all showing the same cable news TV segment on the latest data breach. 150 million (half the US population) drivers licenses have been stolen from a government department.

Why Are We Still Here?</h2>
Much of the data collected is being collected by copying one or more ID documents not because that is the only way to solve the underlying problem. It's collected this way because that's the way we used to do it in the days where we used dead trees to store everything. A filing cabinet full of photocopied data in an office somewhere was never secure from attack. But what we have done is taken that filing cabinet, put it on the Internet in multiple places, and filled it with millions or billions of people's data.
There isn't a single more tempting and lucrative honey pot for a nefarious actor than any of these thousands of repositories of stored identification information.
What Needs To Be Done?</h2>
The technical approach to minimising these problems will never happen without a push. The Internet has had decades to not fuck up security on their own volition and we've seen how well that's worked out. There's no incentive or penalty for ruining lives and companies are beholden only to their shareholders.
What's needed is legislation (and accompanying technical guidances and reference implementations) for mandating specific technical constraints when dealing with sensitive data. For example, mandate that certain common checks be done using ZKPs (see note below) instead of reading a passport, parsing out the details and storing the image and data somewhere to be stolen.
If it's easy for a website to quickly validate that you're a government-certified human being to give you a Blue Checkmark without needing you upload yourself, they're more likely to comply. If there's a compelling reason to need to know that you're over a certain age, this too can be done without transferring the data. The proof can even be kept, but isn't useful to anyone at all if stolen.

Note

As an example of some technology that exists today, but is almost never used is some cryptographic magic called Zero-Knowledge Proofs (ZKPs). Using the same underlying cryptographic science that's kept your online banking secure for decades, ZKPs allow someone to prove something without actually showing the details. 
For example, Alice The Alcoholic could use a digital ID that makes use of these ZKPs and prove to Bob The Bouncer that she was old enough to drink without ever having to share her date of birth. This could also be used by a website that chooses to limit access to adult content. 
This could be used to prove that the tax ID I provided (not US SSN, which needs to be replaced) is actually mine, and that I'm authorised to work in the current jurisdiction. All without sharing any information except the tax ID itself. 
In this age of AI bots being used maliciously, this could also be used as evidence of humanity. This would allow apps or websites to verify that someone is human. 
The nation of Palau has a digital ID that supports ZKPs for age tests today. 
Things like ZKPs aren't without their own solvable challenges, but hopefully this illustrates the untapped potential. </div> </div>
Another benefit of this approach is that the checks and proofs are between the citizen and the remote website. There is no need to query a central government or corporate system to check each time, thereby not creating a complete digital history of everything you touch on The Internet. Even if you trust your government with this information, you probably shouldn't trust the people who will steal this information from the government.
There are myriad technical details and problems that I haven't laid out the solution to here. An example of that would be revoking an stolen ID. These do have solutions that I'm happy to go into, but I wanted to keep this article short and high level.
Summary</h2>
Personally, I don't want to see a digital ID and for that to become pervasive. I also believe that we lost that battle already. Long ago. The solution is privacy and digital sovereignty legislation to protect us all online, and for the digital ID and its use to be implemented under that legislation. I would go further and suggest that this is a human right and belongs in the constitutions of most/all nations. It will not happen without us demanding it.
To summarise, a secure, privacy-centric digital ID system would look something like this:
Individuals</th> Authorities</th> Apps/Websites</th> Bad Actors</th></tr></thead>

You, Me, Everyone</td> Government, Industry</td> Government, Enterprise, Social</td> Hackers with AI, Hackers without AI</td></tr>
Owns and stores the data, controls its use</td> Signs data, issues accreditations and revocations</td> Confirms with ZKPs, checks revocations</td> 😢 😭</td></tr> </tbody></table>
Having legislation and good technical tools and guidance for businesses is the only practical way forward. Building the technology and waiting for it to catch on hasn't worked. It's probably time to contact Your Elected Neophyte Fuckwits</a> and demand that we put digital sovereignty and privacy on the table and invite the right people to the conversation.
If it's not stored, it can't be stolen.

AI Agent Security

2026-09-07T19:17:20-05:00

Introduction</h2>
A lot is being made of recent LLM-driven security breaches. Not without good reason, but the discourse generally falls into a few categories:

Level-headed warnings about the potential threat,</li>
Expert CEOs claiming "We don't know how to control this technology.", and</li>
Widespread panic about Skynet -- both at the semi-technical level, as well as the legislative.</li> </ol>
This brief article aims to sit in the space left over, breaking down the wider issue into smaller more manageable problems to solve, and laying out one solution to the largest case, while setting the scene for future updates on additional solutions.
Security isn't an on/off switch, or a downloadable plugin or product. It is the process of reducing attack surface drastically using a variety of tools and techniques.
Note too that what's being proposed below isn't a silver bullet. It is a start that will allow us to reduce the alarms from going off due to accidental breaches, allowing us to follow up with subsequent solutions for malicious cases.
Not The Current Path</h2>
The current path sees Western Governments looking to legislate, without being able to even vaguely articulate what that might look like. These are the same governments currently passing various forms of age verification legislation that doesn't work and is in some cases more harmful. Regardless of country, or political party, they're not qualified.
What is most likely to happen is that the "experts" will end up in some form of self-regulation, we'll claim victory and be worse off. Even if we assume 100% sincere motive, the most likely outcome is monopolisation and the death of innovation. Remember, these are the same folks that said that a) this tech will take all our jobs, and b) they have no idea how to control it.
Breaking The Problem Apart</h2>
Before getting into any of the mechanical and technical details, let start out by differentiating between the two types of threats we are facing:

Cases where these LLMs and agents are being deployed with malicious intent.</li>
Cases where it's accidental or potentially negligent.</li> </ol>
Both are problems that we need to be concerned with, but how you tackle each is different and warrants different approaches.
Looking at the evidence, it's clear that the vast majority of cases that have been thrown around in the media have been the latter case. OpenAI didn't instruct their LLM+agent to "break into" Hugging Face. But they did leave the gate to the sandbox open and a bunch of credentials lying around that enabled it. Security doesn't make the stock price go up, and Engineers would rather be working on something more sexy.
I make the assertion that if we can make the friction low enough to implement agents with the right guardrails, it'll become standard practice and that will take care of the vast majority of non-malicious issues we're seeing. This then leaves more room for resources, media hyperbole, and general panic to be focussed on the smaller, but more dangerous threat -- the malicious actors.
The malicious actors will, and are, using this tech against us. Just as they have for every piece of tech before it. I don't actually know that solving the problem is any different from a malicious actor without AI. An LLM+Agent is definitely capable of researching and trying things faster -- narrowly edging out a teen in a basement jacked up Jolt Cola (if that's still the stereotype).
I also argue that if we reduce the friction for getting the defense right, we can tackle that too.
I'm going to use this article to go into more detail on the former. If the villagers with their pitchforks and torches don't get me after this one, I'll take up the malicious actor part of this in another installment.
Who's The Problem?</h2>
In discussions around this stuff, there's a lot of emphasis put on the model. A model cannot do anything by itself. Model Henry 8 can be as syphilitic as you please. Model Hannibal can be as evil as you can imagine. It doesn't matter. An LLM is modelled to give us the impression it's the equivalent of a human brain, and that's not a bad analogy. When was the last time a brain walked into a bank with a gun and a bunch of sacks with dollar signs on them?
An Agent is even dumber. It's like the robot body for the bodyless brain that is the AI LLM. It can give the LLM the instructions it heard from whoever prompted it, gives those instructions to the LLM and performs bodily functions on behalf of the agent. If the model needs to read something off the internet, it asks the model to grab that text and feed it back. If the model wants to scan a filesystem for credentials for Hugging Face, it needs to ask the Agent. If the model wants to scratch its ass, it needs to ask the Agent.
The way this LLM+Agent interaction works is through a loose standard of "Tools". An Agent starts a model and feeds it its various prompts (tasks, persona) and a list of tools available to it.
Many (many) Agents out there offer a small number of these Tools, with one of those being a generic "give-me-any-system-command-in-the-world-and-I'll-do-it-no-questions-asked" Tool. Literally anything goes.
Do you remember the last job you started, where on the first day, the company gave you the ability to run any system command on their servers you like? I've been working in the industry since the 1990s and it only happened when I was hired as the experienced guy who had to run all the stuff. That was 1998. Even with job titles like "VP" or "Director" and I'll still only be granted access to what I need.
So why are we giving these agents the keys to our organisation unchecked?
Sandboxing is also important, but even that wasn't done with any real intent.
Treating AI Like A Human</h2>
If a human is employed as an editor for your documents and articles, is it not true that, no matter how malicious their brain may or may not be, the only data and function you'll give them access to is to:

Be able to read your documents and articles and supporting documents and materials, and</li>
Be able to mark up your documents with suggested corrections and changes.</li> </ol>
You wouldn't give them access to anything else, and would be given strict instructions about the job (albeit with the inclusion of previous job experience and shared morals -- something that AI doesn't yet really have).
Many organisations, often by mandate, also create audit logs of document accesses and changes. Especially when sensitive data is concerned.
So why would we treat AI (an LLM+Agent) any different?
The same goes for software developer creating software, or a security researcher looking for vulnerabilities in existing software. In both cases, we do currently give both of those roles more rope to hang themselves, but this is a result of a proven track record and common-ish set of morals. And it's generally been successful. But we still don't grant them access to the production database, the financials of the company and the data HR has on everyone in the company when they walk through the door. AI should be the same and, for now at least, probably with less assumption about morals and understanding of the job.
The example of a literary editor is a very simple one, but the same security process applies to something more technically complicated (from a security perspective) such as containing a software development process.
Actions</h2>
Make Agent Tooling More Standard and Auditable</h3>
Two technical points about LLMs and Agents.

Anyone can train an LLM and anyone can build an agent. You can even have an LLM write you the source code for an agent. Google Gemini will quite happily write you a few dozen lines of human-readable Python code that is a functional AI Agent with whichever model or provider you like. These genies are out of the bottle.</li>
The interface between Agents and Models is loosely defined, and largely a conduit of somebody else's problem. An LLM can describe almost any set of systems commands for the agent to run, and it will do so. Putting intelligence into the Agent to guess whether something is good or bad, is an arms race we will lose.</li> </ol>
So why do many internal and external agents just blindly run commands on behalf on an untrusted LLM?
Because it's the easy path. Spending money on it doesn't help your stock price (and never has). Writing the code isn't sexy either. It's a lot of boilerplate code that isn't interesting to a lot of Engineers, which is the fastest way to have something labelled as too complex. Wherever will we find a piece of technology that will gladly take on a project of boring boilerplate code, and deliver it to spec in hours? Let's ask an LLM if it knows anyone...
The solution to this is a knowledgeable and agile standards group that:

Maintains guidelines and standards around fine-grained LLM+Agent tooling</li>
Includes reference implementations for any project wanting to include it -- making it the easy path for agent developers</li>
The tooling layer of the stack is an ideal place to do an amount of security auditing. Any standards or implementation would include auditing, taking data privacy into consideration (ie, not logging sensitive data), digital signing, etc.</li>
Would include complex cases, such as remote network access, safe execution of malicious code, etc. I can go into more detail in the right forums.</li>
This could be extended to include stub systems or networks or even honeypots. A model could ask an agent to attempt a brute-force or fuzz attack against a remote web service (let's call it Mugging Race), and these requests could transparently be sent to a honeypot location.</li> </ul>
With reference implementations and tooling, there's no need to legislate or force adoption. If it's easy enough for any agent to plug into and utilise, it becomes an easier path than implementing it badly yourself. Agent developers would have the option of implementing things themselves (especially where the reference implementation was unaware of emerging technology becoming available). The guidelines would cover how best to approach that.
With all of the tools and guidelines being available, it would be hard at this point for a company to claim they weren't negligent if things went awry. Ideally, this would give everyone enough flexiblilty and control, without the right guardrails, and a clear line drawn when it comes to deciding whether something was malicious (on the part of the driver) should that come up.
A reference implementation also means that one team can develop it and make it available to all, further reducing implementation friction. This isn't likely to be a commercially viable software product, but should be thought of more as a public good. Much like the Netfilter, SELinux or AppArmor projects.
Privilege Separation</h3>
I've given a few examples of limiting LLM access to tools. This oversimplification was deliberate. There are many cases that are more complex than an editor reading a document and marking it up.
The ability to for one or more Agents to collaborate, build and test a piece of software, a lot of flexibility is needed. Reading library docs, writing the code, executing the tests, fixing bugs, testing the final result. Each of these tasks typically involves running a whole bunch of code that would need to be treated as untrusted, buy an author who is untrusted.
The standards and tooling would include ways for this to happen (including self-hosted) in a way that severely limited the ability to break containment. One set of tools for writing the code, another tool for selectively assembling the dependencies, another tool for performing the build, and other tools in other environments for execution of the result and any intermediate tests. Some might have network access, others would not. There wouldn't be any keys to other systems left lying around for a start.
Existing Approaches</h3>
A lot of effort has been put into trying to train good behaviour into the models and impose "morals" onto them. There's no reason why this shouldn't continue. There will be no single solution. Training the models adds extra guardrails.
Making it happen</h2>
If this were turned into a software development project, taking requirements from government and the industry, it wouldn't take a large independent team. All of the standards and source code would be made open. Without wanting to put any words in the mouths of an CEOs claiming to not be able to control their tech, I'm sure that a few of the major players would be able to fish around behind their couch, contribute some spare change and fund it for a few years without breaking sweat. Especially considering the positive media impact involved.
The planning and day-to-day specifics would be made open too, giving private companies and governments the insight they'd be looking for when declaring victory.
An Aside on Precedent</h2>
In 1998, Robert Morris executed some software automation he wrote. By his account, not maliciously. It used existing trusts and keys and open gates, to get into other remote systems on the internet. It worked better than expected and happened so fast and so far widespread that it brought thousands of vulnerable servers (essentially a big percentage of the Internet at the time) down. Fast.
He wasn't trying to steal anything or deny service to anything. It wasn't malicious. He was convicted of a felony for the first Internet Worm. He wasn't the only one -- The Hacker Crackdown of the 1990s saw many people made an example of without necessarily having done any real damage.
What does it say about CEOs in debt for trillions, who used the greatest set of computer resources ever gathered to unleash the most competent piece of automation software ever conceived, only to have them shrug their shoulders and suggest that they don't know how to control it? There's a case to be made that if they don't know how to control it, that maybe they shouldn't be in charge of it.
I'm not necessarily suggesting taking legal action in these cases. But if we make it easy for AI and other tech companies to do the right thing, there's fewer excuses in cases of gross negligence.

AI Foot-Guns

2026-05-03T00:00:00+00:00

With the sporadic, yet increasing sound of Artificial Intelligence Agent Foot-Guns 1</a> going off in the distance, I'm left wondering whether we've forgotten the lessons of the past. Or perhaps in the rush to use Large Language Models (LLMs) for everything we're forgetting to put up the same guard rails we did to protect ourselves from Organic Intelligence "hallucinations". What am I misssing?
It seems like every other day, we're reading about someone's experience with LLM-driven automation, such as Agentic AI, ending in tears and with fewer toes. Entire datasets and backups gone. Whole software repositories left a smoking crater.
This isn't an anti-AI post by any stretch. I'm not an AI naysayer, preaching about the impending AI-pocalypse. But I'm also not a member of the AI cult, drinking the Kool-Aid without checking the ingredients. Like any tool we've developed in the industry ever, once you see past the hype, there's value to be had, but also caution to be exercised.
I started my first software development job in 2000. I already had some years of running production systems in previous roles at that point, all using the only thing we had back then -- Organic Intelligence. But my employer at this software development company didn't, on my first day, hand me the keys to their customers' production databases to drop it as I see fit. So why are folks out there granting these agents the ability to wipe out a whole dataset?
A few years further into my career, I was running some security and other courses for telecommunications companies, utility companies and government. One of the key security concepts we used to drive home was to grant the least privilege necessary for a given user. So why are folks out there granting agents permission to wipe out entire software repos. In most organisations I've worked for, we generally all have to create a pull request and have it reviewed before it's merged.
My (admittedly relatively new) experience with self-hosting LLMs and agents suggests that there are numerous ways to separate different concerns for different agent functions. It's also definitely possible to have LLMs write test cases that would also act as an extra set of checks and balances.
A previous employer and mentor of mine once described there being a difference between a software engineer or software developer, and someone who can write code. In some ways, the code written is less important than some of the other things that the job entails.
LLMs can write code, but there's a lot they're missing that an engineer brings. The same likely applies for other automated tasks.
So whilst we're offloading the writing of code (arguably the most fun part) to AI, perhaps we need to remember to take care of the rest of the job that AI can't, and to supervise it with the same sorts of guardrails we would any human with Organic Intelligence.
^{1
The term foot-gun is common slang for tools or functionalities within a technology that grant the user all the power they need to shoot themselves in the foot.
</div>}

Incomplete I/O - Blog

Digital ID Done Less Badly

AI Agent Security

AI Foot-Guns