Ai-Agents on Napat's Inverse Blog

Inside the Machine: What a Leaked Agentic Code Tool Reveals About AI Security

Tue, 31 Mar 2026 20:30:00 +0700

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.

The Agent Security Gap

Mon, 30 Mar 2026 10:05:00 +0700

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.

The USB-C Metaphor Hides the Hard Part

Sun, 22 Mar 2026 15:59:00 +0700

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.