EXIN / Resources / AI Security Is Not a New Framework. It’s an Extension of the One You Already Have.

AI Security Is Not a New Framework. It’s an Extension of the One You Already Have.

There’s a quiet myth taking hold in security circles: that AI needs its own security discipline, built from scratch, with its own governing body, its own certifications, and its own way of thinking about risk. It doesn’t.

AI security is not a parallel universe. It’s your existing security program, stretched to cover a new input surface, a new set of suppliers, and a new class of assets. If your organization already understands confidentiality, integrity, and availability, you already have the foundation. What’s missing isn’t a new mental model. It’s an update to the one you’re running.

The Core Idea: Same Discipline, New Surface Area

Traditional application security assumes a fairly stable boundary. Inputs are structured. Behavior is deterministic. A given input produces a predictable output, and when it doesn’t, that’s a bug you can trace and fix.

AI systems break that assumption in one specific way: the model itself becomes a new attack surface. Prompts are inputs an attacker can manipulate. Training data is a supply chain most teams have never had to vet before. Model outputs can be influenced in ways that don’t leave the kind of forensic trail a traditional exploit does.

None of this replaces what you know. It sits on top of it. A prompt injection attack is still, fundamentally, an input validation problem — just one where the “input” is natural language and the “validation” logic is a probabilistic model instead of a parser. Data poisoning is a supply chain integrity problem, the same category as a compromised open-source dependency, just with training pipelines instead of package registries. Model theft is an asset protection problem, the same category as IP theft, just with weights and architectures instead of source code.

Security teams that treat these as entirely novel threats end up reinventing frameworks that already exist in a slightly different shape. Security teams that recognize the pattern move faster, because they’re extending muscle memory instead of building new muscle from nothing.

Check this out : G.U.A.R.D.: Five Steps to Organize AI Security in Your Organization

What Actually Changes

To be clear, “extension” doesn’t mean “nothing changes.” Three things genuinely are new, and they deserve direct attention:

New input attack surface

Natural language prompts are a channel that didn’t exist in traditional application threat models. Attackers can attempt to manipulate model behavior through crafted inputs, jailbreaks, or indirect injection via documents and data the model ingests. This requires new detection and monitoring approaches, even though the underlying risk category — untrusted input reaching a decision-making system — is familiar.

New suppliers

Foundation model providers, fine-tuning services, and data annotation vendors are now part of your supply chain, often with far less transparency than a traditional software vendor. Vetting them requires asking questions most procurement checklists don’t yet include: How was the model trained? On what data? What’s the provenance chain? This is third-party risk management, applied to a category of vendor most organizations haven’t formally assessed before.

New assets to protect

Model weights, training datasets, and fine-tuning configurations are now assets with real value and real exposure, sitting alongside your existing crown jewels — source code, customer data, credentials. They need to be inventoried, classified, and protected using the same rigor you’d apply to anything else on that list, which means most organizations need to explicitly add them to an asset inventory that currently doesn’t account for them at all.

Each of these is genuinely new territory. None of them requires abandoning the discipline you already have.

Why This Framing Matters

The distinction between “new discipline” and “extended discipline” isn’t academic. It changes how organizations staff, budget, and build capability.

If AI security is treated as an entirely separate function, organizations end up building parallel teams, parallel tooling, and parallel governance — expensive, slow, and prone to gaps at the seams where the two programs don’t quite talk to each other.

If AI security is treated as an extension, the existing security organization absorbs it the way it absorbed cloud security a decade ago: not by starting over, but by identifying what’s genuinely new, mapping it onto existing risk categories, and building targeted capability where the gaps are real.

This is also why sourcing matters. Security teams don’t need another vendor whitepaper asserting what AI security should look like. They need a structured, community-vetted reference that maps these risks the way the security field already maps risk elsewhere.

A Source Worth Anchoring To

This is where the OWASP AI Exchange is worth knowing, especially if you already trust OWASP’s work in application security. It’s a free, open, community-maintained resource that catalogs AI-specific threats and controls using language and structure that will feel immediately familiar to anyone who’s worked with the OWASP Top 10 or similar frameworks. It’s not vendor-driven, and it’s actively maintained by practitioners working through exactly the extension problem described above.

If you do one thing after reading this, read that. It’s free, it’s thorough, and it’s the closest thing the field currently has to a shared reference point.

Where This Leaves Security Teams

The organizations that will handle this transition well are the ones that resist the urge to treat AI security as a green field. The frameworks, the risk categories, the instinct for where attackers look first — all of that transfers. What’s needed is deliberate extension: new detection capability for a new input channel, new vetting processes for a new supplier category, new inventory and protection for a new asset class.

That’s a smaller, more tractable problem than “build an entirely new discipline from scratch.” It’s also a more honest one.

If your team is working through this extension problem in practice, EXIN’s AI Security Professional (AISP) certification is being built around exactly this framing.

Start with the OWASP AI Exchange →
|
Sign up for AISP updates →

Related articles