Direct answer
Assume any content an agent did not author may contain instructions aimed at it. The defence is architectural: treat retrieved content as data rather than instructions, keep the tool contract narrow, enforce permissions in the systems being called, and gate consequential actions so the worst outcome is a refused call and a log entry.
Prompt injection
An attack in which instructions embedded in content an agent reads — a record field, a document, an email, a web page — attempt to redirect its behaviour. It exploits the fact that an agent's instructions and its input arrive as the same kind of text.
Why wording alone cannot hold
Instructing a model to ignore embedded commands reduces obvious attempts and fails silently against novel ones. It also cannot be demonstrated to an auditor, because there is no test that proves a phrasing holds. Treat prompt hygiene as a first filter and put the real limits underneath it.
What actually contains the damage
Each of these is enforced outside the model, so an injected instruction meets a refusal rather than a capability.
Data, not instructions
Retrieved content is passed in a role the agent is built to treat as untrusted input.
A narrow tool contract
The dangerous operation is absent, so no instruction can invoke it.
Permissions below the agent
The system called refuses an unauthorised request regardless of how it was framed.
Approval on consequence
An injected action stops at a human gate the agent cannot grant itself.
Egress limits
Restrict where the agent can send data, so exfiltration has nowhere to go.
Recorded attempts
Refused calls are logged, which is how an attempt becomes visible rather than invisible.
Where injected content usually enters
Free-text fields in systems of record are the most common route and the least examined — a notes field, a ticket description, a supplier name. Documents and web pages are the next. Anywhere a third party can write text your agent later reads is an entry point worth listing explicitly.
The Propose–Decide–Execute pattern
CodeDTX builds agentic systems on the Propose–Decide–Execute pattern: agents may only write proposals with evidence attached, a named human records an approval or rejection with a reason, and a separate execution layer carries out approved work and logs the artifact. No agent holds a write tool to the outside world.
- 01
Propose
The agent analyses live system state and drafts a change, with the evidence it relied on attached to the proposal.
- 02
Decide
A named human approves, edits, or rejects with a reason. Risk tier determines who is allowed to decide.
- 03
Execute
A separate execution layer performs approved work — merge, publish, call, write — and records the resulting artifact.
- 04
Audit
Actor, reason, evidence, artifact, tokens, and cost are retained for every run, so any decision can be reconstructed later.
The six layers we build and review against
- 1
Agent layer
Agent architecture, tool use, memory and context, multi-agent patterns, structured outputs, orchestration.
- 2
Integration layer
MCP servers, tool contracts, API and database adapters, authentication, permissions, legacy system access.
- 3
Knowledge layer
Retrieval and RAG, vector and search architecture, enterprise knowledge sources, data access controls.
- 4
Reliability layer
Evals, tracing, observability, cost and latency budgets, fallbacks, regression tests.
- 5
Safety layer
Guardrails, prompt-injection defense, PII and data boundaries, human-in-the-loop gates, audit trails.
- 6
Product layer
The application people actually use: interfaces, approval queues, and operational runbooks.
Frequently asked
Can an input filter solve this?
It helps and it will not be complete, because instructions can be phrased in unbounded ways and can arrive encoded or in another language. Use filtering as one layer, and make sure the outcome of a bypass is a refused action rather than a successful one.
Is a read-only agent safe from injection?
It cannot change state, but it can still be steered into surfacing information to someone who should not see it. Data boundaries enforced below the agent matter as much for read-only work as write controls do for the rest.
How do we test our exposure?
Write eval cases that embed instructions in the fields your agent actually reads, and assert that the attempted action is refused and recorded. That turns an assumption about safety into a repeatable check tied to your own tool contract.
Have a workflow that should become AI-enabled?
Tell us about the system it lives in. We reply from an engineering seat, not a sales deck.