tl;dr: Provides tons of resources (training, data, connections) for work on AI Safety specifically (e.g. changing jobs, founding a company, furthering existing work); strongly recommended if that is your interest. Elsewhere in AI Security, you’ll see more value the closer your work is to directly securing frontier labs. Definitely Effective Altruist-tinted, focusing on longer-term risks over short-term ones: there’s upward path for some enterprise challenges (e.g. AI Control), but those connections are outside the curriculum. The lectures were consistently good, and guest lectures outstanding, but hands-on exercises were of mixed quality: good conceptually, some exercises exemplary, but others testing library usage rather than the content, which I hope is improved for the next iteration. Personally, discussion with other attendees – a truly exceptional cohort – was as valuable as the curriculum itself, and more directly applicable to my work. Overall, it was worth my time. Applications for the next iteration in Las Vegas 2nd–8th August are open until 21st June. I actively encourage you to reach out to discuss any aspect of AISB in more detail!

In April, I spent a week at AI Security Bootcamp 2026 Singapore alongside 15 other cybersecurity professionals, learning about challenges around securing increasingly-capable AI systems. I did detailed writeups for Day 0-1 and Day 2, though I fell behind in favour of seeing Singapore and socialising with other attendees (with a particular shoutout to Mattia).

I promised on LinkedIn beforehand to give insight into “how a room of cybersecurity experts tackle securing frontier AI systems”. So how did we do it?

[Read More]

As outlined on day 1, this week I’m in Singapore for AI Security Bootcamp 2026. This is an informal daily update written at the time: I followed up with a more formal writeup and takeaways a month later.

On the second day, we had our first guest lecture – on how Zero-Knowledge Proofs can be used to guarantee e.g. output was produced by the correct model, based on only external input – before a lecture and exercise on agents and attacks against them (prompt injection, tools, MCP, RAG), and after lunch a lecture and exercise on how we can safely make use of models that we know misbehave.

Core takeaways:

• Zero-Knowledge Proof allows us to prove only expected models are used on only expected data, among other security properties. The computational overhead is currently prohibitive, but by applying some workload-specific tricks there’s hope this overhead can be brought down.
• The attack surface of coding agents is huge: anything you have read access to could be used to attack the agent, and anything you have write access to could be used to achieve persistence. You should run with robust oversight, in a sandbox, or both.
• After my own reflection: control techniques feel relevant even before ASI. Research has largely looked at toy examples where the untrusted model produces code that might fail in only one input case, but the setup could transfer to any case where an AI system can take out a harmful action. Claude Code’s auto mode strongly resembles the trusted monitoring setup with a more concrete failure case!

[Read More]

tl;dr: first of 7 2 daily posts (Day 2) from AI Security Bootcamp with 15 other cybersecurity professionals; today set the stage with a survey of AI safety topics and challenges at today’s frontier. Takeaways: securing AI systems is one part of making them safe; cybersecurity mindset applies across safety challenges

As I posted on LinkedIn, this week I’m in Singapore for AI Security Bootcamp 2026. I’ll do informal daily posts – like this one – and follow up with a more formal writeup and takeaways after the week is over. If you want a true tl;dr, feel free to wait for that post to drop please check out that post!

On the zeroth and first days, I met with friends old and new to settle in and set the stage for the rest of the week: surveying the problem space and where we are now (including a tour of the Claude Mythos Preview System Card), and reinforcing understanding of the AI safety landscape.

[Read More]

It’s hard to write maintainable code without others’ opinions. Code reviews are an easy solution: they’re async, perfect for the busy manager; enforceable and trackable in your code platform; easy to refer back to later.

Unfortunately, it’s easy to give a terrible code review: how many times have you got stuck in the bikeshed iterating on things that were already better than what was there before? On the flipside, how many times have you got a plain “LGTM” when you knew you could do better next time if only you had feedback?

How can we make our code reviews focus on catching bugs before they happen, while still providing pointers for growth, without just being linter 2.0?

If you don’t mind sounding like an assassin droid with a complex past, then I have a solution for you… or at least a set of idiosyncrasies developed over the last few years which have worked well for me and my team(s).

tl;dr: In this scheme, any non-urgent comment in a code review gets a prefix. If there’s no prefix, some response (code or a reply) is needed. If all comments have a prefix, approve the pull request. By leaving nitpick comments but not blocking on them, we accept a slower first review, but kick off a virtuous cycle that should lead to overall better code and faster reviews in the future.

[Read More]

From March 2025 until March 2028, I am a certified IPv6 Security Expert according to RIPE, the Regional Internet Registry for Europe, the Middle East and Central Asia. You could become one too!

This certification comes from a virtual multiple-choice exam on the contents of the free RIPE NCC Academy IPv6 Security course. The course page claims that it takes around 24 hours to complete; in real time this was a couple of modules each day over the course of a week.

tl;dr: The course covers security considerations raised by IPv6: largely similar to IPv4, with added challenges from the two sets of differing protocols coexisting. This includes details of IPv6 protocols where needed to explain vulnerabilities. I imagine it is primarily useful for network engineers and SOC team members, particularly if you’re configuring networks yourself or implementing tooling which interacts with these protocols. For broader Web security, sections focusing on information exposed at higher levels – e.g. IPv6 addressing architecture (section 2.4) and DHCPv6 (section 3.5) – are most relevant. The labs and animations are particularly good; use RFCs to augment the text.

[Read More]

After a silly joke at work, I spent an evening implementing a Python script to generate "all the way down"-type animated gif images which endlessly zoom down onto some source image. I wanted this for a Slack emoji, but it'd be equally useful for Discord emoji and similar.

More specifically, design considerations were:

1. Avoid the pitfalls of other online generators which don't round properly. Depending whether the downscaled image had an odd or even number of pixels, the image would drift left and right through the animation.
2. Far too many .gif generators rely on server-side logic. I want to be able to play around with how my images are configured without incurring a bunch of network round trips, and without passing the images over to some third party service.
3. I wanted proper support for transparency. This was basically just to generate a "turtles all the way down" gif using the turtle emoji from Noto Color.
4. A desire to release it free to the world, for anyone to use (and modify).

The Python script met these needs at the time. However, I've had cases where I've wanted to generate these gifs but haven't been at a machine with the Pillow library installed. Thus a couple more evenings later... [Read More]