Prompt injection sounds like a problem for chatbots. In operations it is a problem for production. An AI that investigates your systems reads a lot of text written by other people: alert payloads, log lines, ticket comments, commit messages, web pages and email. Any of it can contain instructions aimed at the AI. If the AI acts on them, the attacker never needed your credentials. The AI already had them.
This piece is about limiting what an injected AI can do, because stopping injection completely is not on offer. It is the reasoning behind zero-trust AI operations, an open specification: assume the AI will be steered one day, and make sure that day is boring.
What is prompt injection, in operations terms?
The OWASP Top 10 for LLM applications defines it as user prompts that alter the model’s behaviour in unintended ways. It separates two kinds. In its words, direct injection is a prompt that “directly alters the behavior of the model”. Indirect injection happens “when an LLM accepts input from external sources, such as websites or files.”
Operations AI lives on indirect input. Some examples of where injected text can come from:
- an alert or log line that includes attacker-controlled data, such as a user agent or a hostname;
- a ticket or chat message from someone outside the team;
- a README, commit message or config comment in a repository it reads;
- a web page it reads while researching an error;
- notes or memory the AI saved from an earlier run.
You cannot sanitise all of that without making the AI useless. So the design question becomes: when the AI is steered, what can it do?
Can you prevent prompt injection?
Not fully, and the people who study it say so. OWASP writes that “it is unclear if there are fool-proof methods of prevention for prompt injection.” Its recommended defences are a mix: constrain and validate the model’s output, filter inputs and outputs, separate untrusted content, restrict the model’s privileges to the minimum, and require human approval for high-risk actions.
The first three reduce how often injection works. The last two decide what happens when it does. For infrastructure, those last two carry the weight.
What can an injected AI actually do?
That depends almost entirely on your access design. Compare an AI that holds credentials with one that does not.
| If the injected AI tries to… | With credentials and write access | Without keys or approval rights, code sandboxed |
|---|---|---|
| Change a system | It can, directly | It can only propose; a person decides |
| Use a token it finds in a file | It can | There is no token in its reach |
| Send data out from code it writes | It can | The code has no network |
| Approve its own change | Possibly, if approval is a convention | The approve action refuses it |
| Read data inside its scope | It can | It still can |
| Mislead the person reviewing | It can | It still can |
Two rows stay the same on both sides, and that is the honest part. Reads still return data to the model, so scope what each connection can read and watch where the AI can send it. And a steered AI can still write a convincing explanation for a bad change. The approval gate makes sure a person sees the change before it runs. It does not make sure the person catches it.
What should a reviewer look for?
A proposal from an AI that may have been steered tends to show it somewhere. Read every proposal with these questions in mind.
- Does the change match the evidence? The proposal should cite what it read. A change that the evidence does not explain is a warning sign.
- Is the scope bigger than the problem? A disk-space alert does not need a firewall change.
- Does it touch identity, access or secrets? Treat changes to accounts, groups, keys and authentication as high risk every time.
- Does anything point outward? New outbound connections, webhooks, forwarding rules and mail recipients deserve a second look.
- Is the content exact? Approve the actual change, not a summary of it.
How to enforce human approval for AI changes covers how to make sure the reviewer’s decision is the one that counts.
What about tools the AI reaches through MCP?
The same rule applies to every tool an AI can call: the tool should enforce what the AI may do, not the AI’s instructions. If an MCP server hands the model a tool that writes, the server needs its own approval path. MCP security for operations teams goes into that.
How GAEZLA does it
GAEZLA is built for the column on the right. The AI never holds a credential; integration credentials stay inside GAEZLA. Code the AI writes runs in a sandbox with no network. Every change the AI asks for is drafted as a proposal that an operator approves, and nothing in GAEZLA can approve. The proposal is fingerprinted at approval and checked again at execution.
We also reduce how often injection works. Recalled memory is scrubbed of secrets and treated as data, never as instructions. Mail from the AI only reaches recipients you allow. Tool results are masked for secret-named fields, bearer tokens and API keys before the model sees them. Unattended routines cannot change your systems or propose a change; the one thing they may send is mail, to recipients you allow, under the routine’s own approval.
None of this makes the AI immune to prompt injection. It is mitigation, not immunity, and reads still return data to the model within the operator’s scope. What it changes is the outcome: a steered AI can propose something wrong, and an operator decides.