Ai-Agents

Most agent tutorials show you the happy path. They give you a chat UI, a tool, and a one-shot demo. Then you try to build something real, and the demo collapses under a single missing concept: how state actually flows, how to test a non-deterministic system, what to do when a tool takes ten minutes instead of ten milliseconds, or how two agents from different teams find each other in production. The 5-Day AI Agents course on Kaggle is the closest thing I have found to a structured curriculum that covers the full life-cycle of an agent system, not just the demo. Ten codelabs, five whitepapers, and a single coherent framework that ties it all together. I worked through every codelab end-to-end. This post is the tutorial I wish I had read first: what each lab is actually trying to teach, the actual code from the codelabs, how to think through the exercises, and the parts of the material that translate cleanly into a real production system. The patterns in the course are not tied to one framework. The same ideas show up in LangGraph, CrewAI, AutoGen, and any custom agent runtime. I am using the course’s framework vocabulary here, but the lessons are not. ...

In March 2026, someone extracted the complete source code of Claude Code from an npm package and published it to GitHub. No modifications. No commentary. Excluding generated code, lock files, and test fixtures — roughly 512,000 lines of TypeScript, dumped into a repository with a single commit. How this happened is itself a security lesson. Anthropic published version 2.1.88 of their npm package with a production source map file — cli.js.map, weighing in at 59.8 MB — that contained the original TypeScript source, comments and all. A misconfigured .npmignore or a build pipeline that skipped artifact scanning, depending on who you ask. The file was there for anyone to extract. Security researcher Chaofan Shou was the first to notice. ...

Why adversarial prompt engineering is not the problem — and what actually is In early 2023, a group of researchers demonstrated something that made security people uncomfortable and product people dismissive. They showed that a language model could be instructed to do things its creators never intended, not by the person using it, but by content it was asked to process. The paper was called “Not what you’ve signed up for.” The attack was called indirect prompt injection. Three years later, the industry still has not fully absorbed the lesson. The fixation on prompt injection If you follow AI security discourse, you would think prompt injection is the central problem. It dominates conference talks. It tops the OWASP list. It generates endless proof-of-concept videos. And it should get attention. It is a real vulnerability. But the fixation on prompt injection obscures a more important truth: prompt injection is a symptom, not the disease. ...

Threat Modeling MCP in the Real World People like to describe MCP as “USB-C for AI.” It’s a good line. It explains why people care. USB-C made hardware interoperability easier. MCP makes tool interoperability easier. Build once, connect everywhere, move faster. The problem with good metaphors is that they are usually true in one way and dangerously false in another. USB-C looks like a cable problem. MCP looks like a protocol problem. But the hard part isn’t the connector. The hard part is delegation. When an AI client connects to tools through MCP, it is not just moving data. It is moving authority: who can read what, who can trigger what, and under which identity. That shift is what many threat models miss. They evaluate MCP like an integration layer, when they should evaluate it like an authorization fabric. Why this matters now Standards compress engineering cost. They also compress attacker learning curves. Before MCP, every integration had custom quirks. That was messy for developers and inconvenient for attackers. With standardization, we gain velocity and lose diversity. A weakness in common implementation patterns becomes reusable across many environments. This doesn’t mean MCP is unsafe. It means MCP is now important enough to threat model as first-class infrastructure. The teams that do this early will avoid the coming cycle: rapid adoption, soft defaults, then expensive retrofitting under incident pressure. ...