It’s Not Magic, It’s Mechanics: Demystifying the OWASP Top 10 for AI
Welcome back to our series, “Behind the Scenes of Immersive One”! The following is a conversation with Sabrina Kayaci, Cybersecurity Engineer for Immersive One, and Rebecca Schimmoeller, Lead Product Marketing Manager. Today, we’re continuing the discussion on our Secure AI capability. “When developers hear ‘AI Security,’ they either start to sweat or eye-roll. It either feels like a black box where the old rules don’t apply, or it feels like inflated marketing hype. The truth is, AI vulnerabilities aren't magic; they are mostly just new manifestations of the classic flaws we’ve been fighting for decades. Once you map the new threats to the old patterns, the mystique fades. You realize it’s not magic to fear or hype to ignore—it’s just an engineering problem to solve.” Rebecca: Awesome frame, Sabrina. No matter where you sit on the spectrum—whether you’re anxious about the risks or skeptical of the buzz—AI security doesn't mean starting from zero. Developers should already have the muscle memory for this. Sabrina: Exactly. We aren't asking them to learn a new language; we're asking them to apply their existing fluency to a new dialect. That’s the core philosophy behind our new OWASP Top 10 for LLMs and GenAI collection. We tackle the problem that AI is often treated as a "new and daunting" field. By framing threats like Supply Chain Vulnerabilities or Excessive Agency as variations of known issues, we accelerate the learning curve. We strip away the "AI mysticism" to reveal the underlying mechanical flaw. Rebecca: I love "stripping away the mysticism." Let’s talk about how that works, starting with the big one everyone is concerned about—Prompt Injection. How do you take that from "scary AI jailbreak" to something a grounded engineer can fix? Sabrina: In the media, Prompt Injection is portrayed as this sentient ghost in the machine. In our lab, we treat it as an Input Validation failure. We show that the system is simply confusing "user input" with "system instructions." When a developer sees it through that lens, the eye-roll stops. It’s no longer hype; it’s just mixed context. And they know how to fix mixed context. We show them how to apply that architectural fix to an LLM. Rebecca: That maps perfectly. But looking at the curriculum, I see we go much deeper than just a standard "Top 10" checklist. Why was it important to go beyond the simple definitions? Sabrina: Because a definition tells you what something is, but it doesn't tell you how it impacts you. In the new OWASP LLM collection, we focus on Core Mechanics and Attack Vectors. We deconstruct threats like Data and Model Poisoning or Supply Chain vulnerabilities to show you exactly how they infiltrate a system. It’s the difference between knowing what an engine looks like and knowing how to take it apart. You need to understand the mechanics of the vulnerability to understand the potential impact—otherwise, you're just guessing at the fix. Rebecca: It sounds like we're upgrading their threat modeling software, not just their syntax. Sabrina: Yes, 100%. Look at Excessive Agency. That sounds like a sci-fi plot about a robot takeover. But when you do the lab, you realize it’s just "Broken Access Control" on steroids. It’s about what happens when you give an automated component too much permission to act on your behalf. Once a developer maps "Excessive Agency" to "Least Privilege," they stop worrying about the robot and start locking down the permissions. Rebecca: Is the goal to get them through all ten modules to earn a Badge? Sabrina: The OWASP Top 10 for LLMs Badge is the end state. It proves you have moved past the "sweat or eye-roll" reactive phase. To your manager, it signals you have a proactive, structured understanding of the AI risk landscape and can speak the language of secure AI. There’s no hype in that. Only value-add to you and your team. Final Thought Our OWASP Top 10 for LLMs collection is the antidote to AI security angst. For the developer, it demystifies the threat landscape, proving that their existing security instincts are the key to solving new problems. For the organization, it ensures that your AI strategy is built on a bedrock of engineering reality, rather than a shaky foundation of fear. [Access Collection]Architecting at Speed: Mastering Secure Development with OpenAI Codex
Welcome back to our series, “Behind the Scenes of Immersive One”! The following is a conversation with BenMcCarthy, Lead Cybersecurity Engineer for Immersive One, and RebeccaSchimmoeller, Lead Product Marketing Manager. Today, we’re continuing the discussion on our Secure AI capability. There is a misconception that security is the enemy of development speed. But with AI, the opposite is true. If you don't have security engineered into your AI workflow, you can't actually go fast—because you’re constantly stopping to fix 'trash code' or patch vulnerabilities. The developers who win in this era aren't just the ones coding faster; they are the ones architecting systems that are secure by design, even at AI speeds.” Rebecca: That’s a crucial distinction, Ben. We often hear that AI is a "firehose" of productivity, but without control, that firehose just creates a mess. It seems like the role of the developer is shifting from "writing lines" to managing this high-velocity output. How does the new Building with AI: Codex CLI collection help them make that shift? Ben: By giving them the controls they need to harness that speed safely. If you let OpenAI’s Codex run without guardrails or understanding, you get velocity, sure—but you also get risk. We designed this collection to empower developers to become their own Security Architects for their workflows. We are leveraging the Azure AI Foundry capability to give learners real, secure access to these models. The goal isn't to teach you how to hit "Tab" to autocomplete; it's to teach you how to rigorously evaluate, guide, and constrain what the AI produces using the command line tool like Codex so you can ship code that is both fast and bulletproof. Rebecca: So it’s about elevating the human’s role to "Architect." Let’s talk specifics given what the collection covers—how did you instill that mindset? Ben: We start by ensuring developers know the power of what you can do with Codex. How to get the best out of your models in this CLI tool. We go over effective prompt engineering, tool usage, and how AI can help with "Greenfield" projects (net-new builds) and "Brownfield" projects (legacy codebases). This is a critical skill for a lead engineer. AI is great at generating new code (greenfield), but it can be dangerous when it doesn't understand the hidden dependencies of a ten-year-old application (brownfield). We teach engineers how to spot those context gaps, key stuff that the AI might miss. Rebecca: I saw "specification-driven development" was a big part of your roadmap, too. How does that fit into the "speed" theme? Ben: This is the ultimate accelerator. Instead of writing the code line-by-line, you write the "spec"—the blueprint—and let Codex handle the implementation details. It’s not about doing less work; it’s about doing higher-leverage work. You define the logic and security constraints, and the AI handles the boilerplate. It shifts the developer’s brain from "how do I type this function?" to "what should this system actually do?" Rebecca: That sounds like a powerful approach, Ben. But what about the security risks? If developers are offloading implementation to Codex, how do they avoid leaking data or introducing bugs? Ben: That’s non-negotiable. In the Guardrails lab, we show learners how to build a safety net. We teach practical methods for stripping PII (Personally Identifiable Information) and using hooks to sanitize inputs before they reach the model. It gives developers the confidence to use these tools freely, knowing they have already engineered the safety mechanisms to protect their org. Rebecca: I saw a lab in the collection called "Tools and MCP" (Model Context Protocol). Is that where you get into advanced workflows? Ben: Exactly. This is where we give developers the keys to become a force multiplier. We show users how to connect Codex to other tools. This is the ideal definition of ROI for developers. You’re automating the tedious "check your work" phase, allowing you to ship secure code faster without burning out on manual review. Rebecca: It feels like that approach accepts today’s AI era realities for what they are and finds the strategic advantages… pushing developers towards productivity and security gains with real mastery. And just like the Claude collection, users have access to a Demonstrate Lab, to prove that mastery, am I right? Ben: Absolutely. The Demonstrate Lab challenges users to build a solution that’s efficient, functional, and secure. It proves that you aren't just an "AI user"—you are an AI Engineer who understands the capabilities the collection covers. Final Thought Our Building with AI: Codex collection is about upgrading the developer’s toolkit. For the organization, it ensures AI adoption is secure and scalable. For the engineer, it removes the drudgery of boilerplate, freeing you to focus on the creative, architectural challenges that drive real value. Ready to upgrade your workflow? [Access Collection]Beyond the Chat Window: How to Securely Vibe Code with Anthropic’s Claude
Welcome back to our series, “Behind the Scenes of Immersive One”! The following is a conversation with RobertKlentzeris, Application Security Content Engineer for Immersive One, and RebeccaSchimmoeller, Lead Product Marketing Manager. Today, we’re deep diving into one facet of our Secure AI capability. “We are seeing a shift from ‘chatting with AI’ to ‘inviting AI into the terminal.’ With the release of tools like Claude Code, developers aren't just copying and pasting snippets from a browser anymore. They are letting an agent live directly in their CLI, giving it permission to read file specs, run commands, and architect entire features. It’s a massive leap in capability—but also in trust.” Rebecca: That is the big shift we’re hearing about, Rob. The market is obsessed with the idea of "vibe coding" right now—just describing what you want and letting the AI handle the implementation details. But for a security leader, the idea of an AI agent having direct access to the CLI (Command Line Interface) sounds terrifying. It feels less like a helper and more like handing a stranger your SSH keys. Rob: That is exactly what makes Claude Code different from your standard autocomplete tools. You aren't just getting code suggestions; you are interacting with an agent that has tooling capabilities—like using MCP (Model Context Protocol) or running slash commands. If you don't know what you're doing, you might accidentally let the agent produce insecure code or mishandle PII in a way that’s harder to spot than a simple copy-paste error. This new collection is about bridging that gap: how do we embrace the speed of vibe coding without sacrificing the security of our platform? Rebecca: So it’s about safe integration. Let’s get into the weeds—what does the "safe" version of this look like in the actual Immersive One labs you created? Rob: We start by defining common patterns used in AI coding agents such as manual prompts and how you can write them so Claude generates secure code. We then go a little deeper and explore how you can let your agents start coding securely with more autonomy and less intervention while staying secure with spec-driven development. From there, we move to the components of Claude Code and show how to leverage these advanced features, such as custom slash commands and skills that can enhance the security of both large legacy and greenfield projects. Rebecca: I noticed your roadmap included a focus on "Guardrails" and "Claude Agents." Is this where we stop "trash code" from hitting production? Rob: Exactly. This is unique to the agentic workflow. In the Claude Agents lab, we teach users how to set up a "Reviewer Agent" that audits the code generated by the first agent. We also have a dedicated lab on Guardrails, focusing on stripping PII (Personally Identifiable Information) before Claude ever sees the data. It’s about ensuring that even if the AI is "vibing," the security protocols remain rigid. Rebecca: That sounds incredible for the security team, but what about the developer? If I’m used to just doing my thing, head down to deliver on time, won’t specification-driven development cramp my style? Rob: Fun fact: It actually makes you faster. Think of the 'spec' as the prompt that saves you ten revisions. At Immersive, we focus heavily on ROI and removing pain for users. In this case, we show developers how to use slash commands and hooks to automate the boring stuff. When you learn to use these tools properly, you stop wrestling with the AI and start conducting it. And because these labs are hands-on with real Claude Code access in a secure sandbox, you can experiment with these powerful agents without worrying about breaking your own local environment. Your manager will love that too. Rebecca: Ha! You’re right. It sounds like we’re giving users a safe place to crash-test the car before they drive it. And I see you wrap it all up with a "Demonstrate" lab? Rob: We do. We want to prove competence. The Demonstrate Lab is a capstone where you have to combine everything—usage, security, and productivity. You have to prove you know how to use Claude Code to build something functional and secure. It validates that you aren't just generating code; you're engineering with it. Final Thought Our Building with AI: Claude Code collection isn't just another coding tutorial. It is a blueprint for the agentic future of development. For you the developer, it turns Claude from a vibe code buddy into a fully integrated, secure pair programmer. For your organization, it transforms a potential security risk into a governed, high-speed workflow. Want to get started? [Access Collection]
CVE-2022-26134 (Confluence) – OGNL Injection
For Question 6. Look at the first exploit attempt by this attacker. What command did they run? I am wondering about why when sharing the commands found in the logs, it still outputs wrong. even if typing in "X-Cmd-Response" as the command as well as the entire string found. Wondering if they are exepecting a different format/snippet of the code, or the GET requests instead?CVE-2022-30190 (Follina) ms-msdt Scheme Abuse – Offensive Question 11
Hey guys, wondering if when trying to upload the payload for "Question 11: In a browser, visit http://<TARGET_IP>:8080, upload the payload.docx file, then press Submit and Execute" if this error is supposed to be generated. After choosing the file after clicking browse sometimes this work. After executing nothing seems to happen though. even after 30 seconds of waiting.
Vibe coding your way to a ZAP MCP server
If you haven’t heard already, Model Context Protocol (MCP) is a new, standardised way that LLMs and AI agents can communicate with external tools. Lots of people in the AI community have been calling it a “USB-C for AI” because you only need one connector for many tools. Today, however, I’m not going to go deep into the weeds about MCP particulars or what a typed JSON-RPC envelope is. Instead, I’m taking you on an adventure I embarked on a few weeks ago. It involved me talking to ZAP in plain English, going to get a cup of coffee, and coming back to a report on a vulnerable web application. But before I embarked on my quest, I needed some equipment: An LLM: I went with Claude Sonnet 4, from Anthropic’s family of foundational models and the creator of MCP. A way to interact with an LLM that can also use MCP servers: Conveniently, Claude has a wonderful desktop app that lets you do this easily. Some MCP servers: Most importantly, the Filesystem MCP server for the ultimate budget-friendly Claude Code imitation. An SDK to write my own ZAP MCP server, to avoid re-inventing the MCP wheel. The Python MCP SDK did nicely. With these tools in hand, it was time to see how far I could take this idea, based purely on vibe coding. Andrej Kaparthy, co-founder of OpenAI (the creators of ChatGPT) and coiner of the term, explains: “There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”. Vibing responsibly While it’s tempting to be allured by the simplicity of telling an LLM to “code me a ZAP MCP server” and have it produce lines of code, it’s generally in your long-term interests to have some understanding of what you’re trying to achieve. Then, you can ask the AI to either expand on that understanding or formulate a plan before it attempts to execute. Don’t just take it from me; this is Anthropic’s first recommended workflow for using Agentic AI. With responsible vibing in mind, I crafted a fairly simple exploratory prompt. I want to create an MCP server for the open-source proxy tool ZAP. I know it already has a comprehensive Python SDK for interacting with it in an automated fashion. How could I leverage the existing SDK to create a ZAP MCP server easily? Putting the code into vibe coding I enabled Claude to read and write files using the Filesystem MCP to create the ZAP MCP server project. In the long run, this saved a lot of time copying and pasting code back and forth between VSCode and Claude Desktop. To do this, I just had to write a small bit of JSON to configure the Filesystem MCP so it knew what directories it could access. Once I’d set that, I restarted Claude Desktop for it to take effect. The next prompt was as simple as telling Claude where it should create the Python project, which version to use, and what configuration file to use for dependencies: Use the fileserver MCP to create the necessary project and code files for this ZAP MCP project in the directory ~/Development/mcp/zap-mcp which you have access to. The project should use Python 3.12 and dependencies set up with a pyproject.toml. And just like that, the AI is using one MCP to write another. Vibe check I love a YOLO code execution as much as anyone, but I decided to take a look at the project code it created, since I was running this directly on my personal computer. The main file is 1200 lines of code! But why should I care if I don’t have to write or maintain any of it myself? # Initialize MCP server self.server = Server(“zap-mcp-server”) I’m more interested in where the MCP stuff is actually happening. Here, the code initializes an MCP server, which makes sense, since I was trying to build one. On line 4, you can see a decorator @self.server.call_tool() is used to handle when the function is called by an MCP client, such as Claude Desktop. Interestingly, it chose to skip the higher-level @server.tool() function that handles all the boilerplate. But again, why should I care if I’m not writing it? The only other particularly interesting part is that the actual code to perform an action in ZAP is about three lines long. That’s because it’s leveraging the wonderful ZAP SDK, just like I planned in the first prompt. Then there’s another decorator on line 4 of this code snippet. Again, the code used the lower-level decorator function list_tools() because it used call_tool() to explicitly list what tools were available from the ZAP MCP server to the MCP client. Ultimately, this gave me more control over the input data – which was useful when interfacing with another SDK that was expecting certain types and structures like the ZAP one I was working with. I quickly checked the code, and then I was almost ready to take this MCP server for a spin! There was just one last bit of JSON configuration to do. I had to specify how to run the server, and from what directory. After one last restart of Claude Desktop, I was ready to make ZAP get to work, through the magic of plain English and MCP servers. Right…? WRONG! Turns out the vibes weren’t checked well enough, and they went from being immaculate to immensely painful. A fair few errors popped up before I could successfully get this to even run one ZAP command. So I manually fixed this code like a responsible developer kept feeding the errors into Claude until it fixed them. Which eventually gave me the ability to get the MCP tool working! Vibe code victory! Key takeaways I’ll leave you with a few lessons I took away from this project: Vibe coding is more than just a meme. It has genuine uses, especially for prototyping. That doesn’t mean it’s capable of autonomously creating projects from start to finish that are ready for enterprise deployment (yet). “Context engineering” is just as important as a good prompt. Use tools such as Claude’s Project Knowledge to improve an LLM's domain knowledge. MCP can be an incredibly powerful tool, but it doesn’t come without risks. You’re potentially giving information to parties that don’t have the same data privacy policies as the LLM you’re using. You’re authorizing actions on your behalf that you may not be aware of. MCPs aren’t particularly different or difficult to build than to a normal client server architecture. If you have a tool with an API, you’ll be surprised at how quickly you can turn it into an MCP server. That’s it! Thanks for coming on this adventure with me. I hope you get inspired to start writing and using your own MCP servers.
