<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Build. Break. Secure. on devanshu.red</title><link>https://devanshu.red/</link><description>Recent content in Build. Break. Secure. on devanshu.red</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 01 Nov 2026 02:35:00 +0530</lastBuildDate><atom:link href="https://devanshu.red/index.xml" rel="self" type="application/rss+xml"/><item><title>Designing AI Agents That Survive Prompt Injection</title><link>https://devanshu.red/series/ai-red-team/01-designing-agents-that-survive-prompt-injection/</link><pubDate>Sun, 01 Nov 2026 02:35:00 +0530</pubDate><guid>https://devanshu.red/series/ai-red-team/01-designing-agents-that-survive-prompt-injection/</guid><description>&lt;p>Every week someone ships an agent that reads your email, your documents or a web page, and can also send things out on your behalf. That combination is the whole problem. The moment an agent reads something an attacker controls, the attacker gets a vote on what the agent does next.&lt;/p>
&lt;p>We have a name for this now: &lt;a href="https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/" rel="noopener noreferrer external">the lethal trifecta&lt;/a>
. Private data, untrusted input, and a way to send data out. Put all three in one agent and a single poisoned email or web page can turn it against you. Simon Willison coined the phrase, and once you see it you cannot unsee it.&lt;/p></description></item><item><title>Six Layers Between a Container and Your Host</title><link>https://devanshu.red/series/ci-cd/six_layers_to_the_host/</link><pubDate>Sun, 01 Nov 2026 02:16:48 +0530</pubDate><guid>https://devanshu.red/series/ci-cd/six_layers_to_the_host/</guid><description>&lt;p>Most of the container write-ups I run into on engagements stop at &amp;ldquo;it is just a namespaced process,&amp;rdquo; then jump straight to a breakout one-liner. That gap is where people get surprised, because the one-liner only works because one specific layer, out of six, was left open. Before I write the next post in this series on abusing a CI/CD runner, I want the mechanism on the table: what actually stands between a container and the host it runs on, and how to check each layer yourself instead of taking my word for it.&lt;/p></description></item><item><title>EKS Authentication Mechanisms - IRSA vs Pod Identity from an Attacker's Lens</title><link>https://devanshu.red/series/kubernetes/01-eks-irsa-vs-pod-identity/</link><pubDate>Sun, 01 Nov 2026 00:25:07 +0530</pubDate><guid>https://devanshu.red/series/kubernetes/01-eks-irsa-vs-pod-identity/</guid><description>&lt;p>&lt;em>Originally published on &lt;a href="https://medium.com/@devanshu.red/breaking-eks-authentication-mechanisms-deep-dive-irsa-vs-pod-identity-from-an-attackers-lens-52f799190ac0" rel="noopener noreferrer external">Medium&lt;/a>
 in January 2026. Updated November 2026.&lt;/em>&lt;/p>
&lt;p>Imagine conducting a red team assessment for a client and you stumble into their EKS cluster through a misconfigured service. Now, what can you do from here? &lt;br>
This is exactly what got me thinking: most people understand EKS internals and underlying authentication mechanisms from a DevOps perspective, but what do they look like through an attacker’s eyes?
This post is a part of my “Breaking Kubernetes” series, where I will walk through various attack vectors I’ve encountered in real engagements. Today, we’re starting with the fundamentals   for EKS workload Identities - understanding how IRSA and Pod Identity actually work before we start breaking them.&lt;/p></description></item><item><title>Token Theft and Abuse - Compromising IRSA and Pod Identity Authentication</title><link>https://devanshu.red/series/kubernetes/02-eks-abuse-irsa-and-pod-identity/</link><pubDate>Sun, 01 Nov 2026 00:53:24 +0530</pubDate><guid>https://devanshu.red/series/kubernetes/02-eks-abuse-irsa-and-pod-identity/</guid><description>&lt;p>&lt;em>Originally published on &lt;a href="https://medium.com/@devanshu.red/breaking-eks-token-theft-and-abuse-compromising-irsa-and-pod-identity-authentication-31c493592bcb" rel="noopener noreferrer external">Medium&lt;/a>
 in January 2026. Updated November 2026 with corrected defenses and detections.&lt;/em>&lt;/p>
&lt;p>You’ve compromised a pod in an EKS cluster through a command injection vulnerability. The web application gave you a shell inside the container, but the real question is: what can you do from here? Most attackers would celebrate and move on to privilege escalation, but the real treasure is sitting right there in the filesystem: authentication tokens that could give you access to the entire AWS infrastructure.&lt;/p></description></item><item><title>Devanshu</title><link>https://devanshu.red/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://devanshu.red/about/</guid><description>&lt;p>Security Engineer focused on cloud-native and AI security. My work involves red team engagements across AWS and Azure, and building tools to automate offensive testing. This blog is where I write up what I learn: how containers, Kubernetes, and cloud identity get compromised in practice, and the controls and detections that prevent it.
I’m also exploring AI security, especially how to safely run and contain code written by AI agents. Most posts cover both sides, the attack path and the defense, because that’s how I think about security work.&lt;/p></description></item></channel></rss>