AI Security¶
Software security usually begins with a stable intuition: if code and data are properly separated, the main attack classes become easier to bound. In LLM systems that intuition is no longer sufficient because the engine itself consumes instructions and data through the same medium: natural language.
That changes the risk surface structurally. A document retrieved by RAG, an observation written by another agent, a tool result or a note stored in memory can stop behaving like passive data and become an operational instruction if the system does not separate privileges, context and execution correctly.
This series does not reduce AI security to a catalogue of new scary examples. The goal is more precise: understand where the risk actually comes from, which part belongs to architecture and which part belongs to controls, and why many mitigations that sound reasonable buy time without closing the underlying path.
From external text to a real-world effect
Security changes when a sentence stops being just text and can cross retrieval, decision, authorization and execution.
Contents¶
1. An instruction hidden in a document can change what the system does¶
- What breaks when an LLM processes the control plane and the data plane through the same channel.
- Why indirect injection in RAG and agents is more severe than the isolated-chat case.
- Which defenses materially change the architecture.
2. Asking the model to ignore its limits¶
- How attacks force a model outside intended restrictions.
- The difference between an anecdotal bypass and a transferable jailbreak family.
- The role classifiers, streaming guards and rapid response can play.
3. Keeping a dangerous signal inside the system¶
- What happens when the system learns, remembers or retrieves content it should not treat as trusted.
- Poisoned RAG stores, agent working memory and persistent backdoors.
- Why removing dangerous knowledge is harder than it appears.
4. Testing the whole path before the incident¶
- What security evaluation means for agentic systems rather than isolated prompts.
- What must be tested across pipelines with tools, memory and multiple steps.
- Why a convincing screenshot is not enough to measure a complete causal chain.
5. Limiting what the system can read, change and execute¶
- Which defensive architecture makes sense in real systems.
- Where guardrails help and where they do not.
- How to combine policy, sandboxing, human review and telemetry without making the product unusable.
Related series: Reasoning Models · AI Agents