<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Policy as Code on BlueSquadron — Security engineering for AI systems</title><link>https://bluesquadron.dev/tags/policy-as-code/</link><description>Recent content in Policy as Code on BlueSquadron — Security engineering for AI systems</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><managingEditor>florent.batard@gmail.com (Florent Batard)</managingEditor><webMaster>florent.batard@gmail.com (Florent Batard)</webMaster><lastBuildDate>Tue, 13 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://bluesquadron.dev/tags/policy-as-code/index.xml" rel="self" type="application/rss+xml"/><item><title>Writing Security Invariants Got Easy. Keeping Them True Didn't.</title><link>https://bluesquadron.dev/posts/writing-security-invariants-got-easy-keeping-them-true-didnt/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/posts/writing-security-invariants-got-easy-keeping-them-true-didnt/</guid><description>In 2022, the first candidate on Alex Smolen&amp;rsquo;s list of security invariants was &amp;lsquo;all software services use single sign-on&amp;rsquo;. Four years on, a model can write that check in seconds. What it takes to keep it true — an engine, a seed of three files, and an honest place for exceptions — is the part worth designing.</description></item></channel></rss>