AI and LLM security: the risks that actually matter right now

AI security is a genuinely developing area of practice — the field doesn’t have the same decades of accumulated consensus that application or network security does. That’s worth saying upfront, because it cuts both ways: some AI security discussion overstates exotic risk, while some companies underrate the real, already-understood failure modes because “it’s just a chat feature.”

Prompt injection

If a model reads untrusted input — a user’s message, a document, content from a website — and that input can influence the model’s behavior in ways the developer didn’t intend, that’s prompt injection. It’s conceptually similar to older injection vulnerabilities, but harder to fully prevent because the “input” is natural language, not a structured query with clean boundaries. The practical mitigation is less about eliminating it entirely and more about limiting what a manipulated model can actually do.

Excessive agency and tool permissions

Increasingly, models aren’t just generating text — they’re calling functions, querying databases, taking actions. Every tool or API a model has access to is worth asking: if this model were fully manipulated by an attacker through crafted input, what’s the worst it could do with the permissions it currently has? That question, applied honestly, frequently reveals broader access than intended.

Data leakage through outputs

Models trained or fine-tuned on sensitive data, or given retrieval access to sensitive documents, can potentially surface that data in a response to a user who shouldn’t see it — sometimes directly, sometimes through careful prompting designed to extract it. This is a data governance question as much as a model question: what data does the model have access to, and does every user of the system have a legitimate reason to indirectly access all of it.

The system around the model, not just the model

Much of the real exposure isn’t in the model itself but in the application built around it: how inputs reach the model, what the model is allowed to do with its outputs, what access and credentials it operates with. A security review of an AI feature has to treat it as a full system, not a black box that either “is” or “isn’t” secure on its own.

Staying grounded

This is a fast-moving area, and confident-sounding claims about AI risk should be treated with some skepticism — including this article’s. The goal is to reason from currently well-documented failure modes, not to speculate about hypothetical future ones as though they were settled fact.

AI security reviews focus on exactly these failure modes, usually alongside the API security review of however the model is actually exposed.