LLM Security: What Breaks When Your Models Start Talking to Everything Else

An LLM on its own is close to harmless.

It reads text and produces text. Manipulate it and you get manipulated text. That is a content problem: real, worth addressing, but bounded.

Almost nobody runs an LLM on its own.

The moment the risk changes

The risk profile changes the moment a model is connected to something.

Give it retrieval and it can read your internal documents. Give it tools and it can call your APIs. Give it an agent framework and it can chain those calls without asking between steps. Give it credentials and it inherits whatever those credentials can reach.

At that point you no longer have a text generator. You have a system that takes instructions from untrusted input and acts on your infrastructure.

That sentence is worth sitting with, because it describes a category of software that security teams have spent thirty years learning to be extremely careful with, and it has been deployed across enterprises in about eighteen months.

An LLM with tools is a system that takes instructions from untrusted input and acts on your infrastructure. We used to call that a vulnerability.

Why prompt injection is the symptom, not the disease

Prompt injection gets the attention because it is easy to demonstrate. Hide an instruction in a document, the model reads it, the model obeys it.

But the demonstration is only alarming because of what comes next. An injected instruction is harmless if the model can only reply. It becomes serious when the model can call something: retrieve a file, hit an API, trigger a workflow, message a system.

Which means the real exposure is not the injection. It is the blast radius: what the model is connected to, and what it is permitted to do once instructed.

Fixing this at the prompt layer is fighting the symptom. You cannot filter your way to safety against an adversary who can rephrase indefinitely, and the model has no reliable way to distinguish an instruction from its operator from an instruction embedded in the data it was asked to read. That ambiguity is inherent to how these systems work.

The three failures that actually cause incidents

Over-scoped credentials. The model's service identity can reach far more than its job requires, because scoping it precisely was harder than granting broad access during development. An instruction that reaches the model inherits all of it.

Unbounded tool access. The agent can call any tool in its registry, in any order, any number of times. There is no policy constraining which combinations are legitimate.

Unverified machine-to-machine calls. The model's orchestration layer talks to internal services with a shared secret and no per-connection identity check. Anything that obtains that secret becomes the model.

None of these are model problems. All three are infrastructure and identity problems, and all three are exploitable without touching the model at all.

Why autonomous attackers are drawn here

This surface suits an automated adversary exceptionally well.

An autonomous attacker enumerates rather than reasons. It probes every endpoint, tries every credential scope, and pursues whatever responds. Over-scoped service accounts and unauthenticated internal calls are exactly what that behaviour finds.

And the timing is decisive. Enterprise response is measured in hours; an autonomous attack completes in seconds. An alert about anomalous model behaviour that lands in a queue is a record of something that already finished.

What actually contains it

Every one of the three failures above expresses itself as a connection. The model calls a tool. The orchestrator calls a service. The retrieval layer calls a store. That is where containment is possible.

A cybersecurity gateway sits at that point: every connection passes through it, nothing moves between systems without doing so. From there it:

Governs machine identity. The model's runtime, its orchestrator and every tool it calls prove identity per connection, rather than sharing a long-lived secret nobody has rotated.

Enforces policy on what may talk to what. "This agent may query this store and call these two APIs, and nothing else" becomes enforced rather than documented. Blast radius stops being a function of what the credential happens to allow.

Blocks autonomous attacks in seconds. Detect, block, write the rule that keeps it blocked: no queue.

Encrypts every connection, including quantum-safe. Which matters here more than most places, because the traffic between a model and its retrieval layer is a continuous stream of your most sensitive internal material.

Records evidence as a by-product of every decision, which is what demonstrating control over AI systems to a regulator actually requires.

At Conux, five agents run that loop: one detects, one blocks and writes the rule, one hardens the surface, one logs the evidence, one orchestrates the rest. Detect. Block. Adapt. Prove.

The long tail nobody prices in

There is a second reason encryption belongs in an LLM security conversation.

The traffic flowing between your models and your data is exactly the material that stays sensitive for years: proprietary knowledge, customer records, internal deliberations, source material. Nation-state actors are collecting encrypted enterprise traffic today specifically because it will be readable later. Harvest now. Decrypt later. Exploit forever.

CNSA 2.0 mandates post-quantum cryptography from 2027. Canada, the EU, the UK and the UAE follow. Retrofitting quantum-safe encryption across every AI pipeline is a programme; applying it at a gateway all of them already traverse is a deployment.

Nothing gets ripped out. Existing cloud, identity, applications and models stay. Weeks, not a rebuild.

A containment checklist

Containment is a design property, not a product feature. These are the checks that determine whether a compromised or manipulated model is a contained event or a significant incident.

Can the model's identity be verified per connection? If the orchestration layer authenticates to internal services with a shared secret, then anything that obtains that secret becomes the model. Per-connection identity verification is the difference between an attacker needing to compromise the runtime and an attacker needing to find a config file.

Is the tool registry an allow-list? Agents frequently have access to every tool registered in the framework, because that was the default. Constrain it explicitly: this agent, these tools, in these circumstances.

Are credential scopes narrower than the model's job? Retrieval and orchestration layers accumulate permissions. The test is not "does it work" but "what else does this credential open". Assume anything reachable will be reached.

Is there a boundary between retrieval and action? Many incidents follow the same shape: content is retrieved from an untrusted source, it contains an instruction, and the model acts on it. Separating "may read" from "may act" (and requiring different authorisation for the second) collapses a large share of that risk.

Are outbound calls constrained by destination? An agent able to call arbitrary external endpoints can exfiltrate whatever it can read. Destination policy is often the simplest high-value control available.

Is model-to-data traffic encrypted, including against future decryption? This traffic carries concentrated proprietary material with a long sensitivity life, which makes it a priority target for harvest-now-decrypt-later collection.

Is every decision recorded where it was made? If evidence has to be assembled afterwards from several systems, it will be incomplete when it matters.

The pattern across all seven is that none are model controls. They are controls on connections, which is why they can be implemented consistently at one point rather than negotiated separately with every team that ships an AI feature.

The bottom line

The dangerous property of a production LLM is not what it might say. It is what it can reach.

Connect a model to tools, data and credentials and you have built a system that takes instructions from untrusted input and acts on your infrastructure. No amount of prompt filtering changes that shape, because the model cannot reliably tell an operator's instruction from one hidden in the data it was asked to read.

Containment therefore has to constrain action, not input: per-connection identity, explicit allow-lists, narrow credential scope, and a hard boundary between reading and acting. All of which are properties of connections, enforceable at one point.