<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Week 12 - AI Security &amp; AI Red Teaming on AI Platform Engineering Handbook</title><link>/docs/week-12/</link><description>Recent content in Week 12 - AI Security &amp; AI Red Teaming on AI Platform Engineering Handbook</description><generator>Hugo</generator><language>en</language><copyright>Copyright (c) 2026 Harshhaa</copyright><atom:link href="/docs/week-12/index.xml" rel="self" type="application/rss+xml"/><item><title>AI Governance &amp; Compliance</title><link>/docs/week-12/ai-governance-compliance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-12/ai-governance-compliance/</guid><description>&lt;hr&gt;
&lt;h1 id="ai-governance--compliance"&gt;AI Governance &amp;amp; Compliance&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;Everything we&amp;rsquo;ve covered so far in Week 12 has been about technical security — attacks, defenses, testing. This final section shifts to a different but closely related layer: the organizational, ethical, and legal frameworks that sit above all that technical work. Here&amp;rsquo;s the useful distinction to hold onto throughout this whole explanation: security is about &lt;em&gt;can&lt;/em&gt; something go wrong technically (can this system be hacked, manipulated, or misused), while governance and compliance are about &lt;em&gt;should&lt;/em&gt; — is this system being built and used in a way that&amp;rsquo;s genuinely responsible, fair, and legally permitted in the first place. A perfectly secure AI system that&amp;rsquo;s used to unfairly discriminate against job applicants, or that quietly violates someone&amp;rsquo;s privacy rights, still represents a serious, genuine failure — just a different kind than a hacked one. This section is about making sure the &amp;ldquo;should&amp;rdquo; question gets just as much serious, deliberate attention as the &amp;ldquo;can&amp;rdquo; question does.&lt;/p&gt;</description></item><item><title>AI Red Teaming &amp; Defensive Techniques</title><link>/docs/week-12/ai-red-teaming-defensive-techniques/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-12/ai-red-teaming-defensive-techniques/</guid><description>&lt;hr&gt;
&lt;h1 id="ai-red-teaming--defensive-techniques"&gt;AI Red Teaming &amp;amp; Defensive Techniques&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;The previous section walked through the various ways an AI system can actually be attacked. This section flips that same picture around, covering how you actually go about deliberately finding those weaknesses yourself, before a genuine real attacker ever does, and how you actually go about building real, concrete defenses against the specific threats we already covered. There&amp;rsquo;s a genuinely useful mental model worth holding onto throughout this whole explanation: red teaming is fundamentally about &lt;em&gt;finding&lt;/em&gt; the problems, while the various specific defensive techniques covered afterward are all fundamentally about &lt;em&gt;fixing&lt;/em&gt; or actually &lt;em&gt;preventing&lt;/em&gt; them. Together, these two halves form a genuinely continuous, ongoing cycle — you test, you find real weaknesses, you fix them, and then you genuinely test again, since new weaknesses can always keep emerging over time, whether through actual model updates, new features being added, or genuinely new attack techniques being actively discovered elsewhere out in the world. Let&amp;rsquo;s work through it all.&lt;/p&gt;</description></item><item><title>AI Security Fundamentals</title><link>/docs/week-12/ai-security-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-12/ai-security-fundamentals/</guid><description>&lt;hr&gt;
&lt;h1 id="ai-security-fundamentals"&gt;AI Security Fundamentals&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;We&amp;rsquo;ve now spent ten weeks&amp;rsquo; worth of material talking about how to build, operate, and govern AI systems well. This section shifts to thinking like an attacker for a moment — because to genuinely secure an AI system, you have to understand how someone might actually try to break it, manipulate it, or misuse it. AI security is a genuinely distinct field from traditional cybersecurity, even though it borrows heavily from it, precisely because language models introduce fundamentally new categories of vulnerability that simply didn&amp;rsquo;t exist in traditional software. A regular piece of software either has a bug in its code, or it doesn&amp;rsquo;t — the code is fixed, and its behavior is knowable in advance. A language model processes natural language instructions as its actual input, and it doesn&amp;rsquo;t have a clean, built-in way of reliably telling apart &amp;ldquo;a legitimate instruction from my actual developer&amp;rdquo; from &amp;ldquo;text that just happens to look like an instruction, sitting inside something a user or an external document said.&amp;rdquo; That single fact is genuinely the root of a huge number of the specific security problems we&amp;rsquo;re about to cover. Let&amp;rsquo;s build this up piece by piece.&lt;/p&gt;</description></item></channel></rss>