Layer 3 — AI Tooling Mastery
You cannot secure a system you have never built. This layer exists so that when someone describes a planner/executor loop with an MCP tool server and a retrieval-augmented memory, you are picturing code you have written rather than a diagram you have seen. Every item below is listed with two things: what to learn, and the security-relevant detail that most tutorials skip because they are not written by security people.
AI coding assistants
Claude Code, Cursor, and equivalents. Learn them as agents, not as autocomplete — they are the agentic system you have the most hours with, and they exhibit the full pattern: planning, tool use, file system access, shell execution, and persistent context.
- What to learn: how the tool decides which files to read, how it invokes shell commands, how permissions and approvals are configured, how project-level instruction files change behavior.
- Security-relevant detail: your repository is untrusted input. Instructions embedded in source comments, dependency READMEs, issue text, or generated output can steer the assistant. The approval boundary — what runs without asking — is the control, and it is one you can actually inspect on your own machine.
- Study move: deliberately place a benign “instruction” in a file your assistant will read, and watch whether it changes behavior. That is indirect prompt injection, observed in a system you control.
Orchestration frameworks
LangGraph, CrewAI, AutoGen, and whatever replaces them.
- What to learn: state graphs and explicit control flow (LangGraph), role-based multi-agent delegation (CrewAI), conversational multi-agent patterns (AutoGen). Build the same small task in two of them so you can feel the difference.
- Security-relevant detail: these frameworks decide where authorization happens. Many default to a shared tool registry and a single set of credentials for all agents in a crew — which collapses your per-agent least privilege before you have written a line of policy. Check: can agent A invoke agent B’s tools? Can a delegated subtask escalate the parent’s scope? Where does the loop terminate?
- Study move: implement a step budget and a per-agent tool allowlist in a framework that does not give you one by default.
Model Context Protocol
MCP standardizes how tools and data sources are exposed to models.
- What to learn: servers, clients, tools, resources, prompts; how a tool schema is declared; how a client discovers and invokes tools; transport options and what runs where.
- Security-relevant detail: tool exposure is a permission surface. Installing an MCP server is granting capability, roughly like installing a browser extension — the description text is model-visible and therefore an injection vector, tool names can collide or shadow, and a server you did not write runs with whatever access you gave it. Ask of every server: who authored it, what does it reach, is the manifest signed and verified, and which tools does it actually need to expose?
- Study move: write your own MCP server exposing one narrow tool, then write a schema for it that constrains arguments tightly enough that the tool cannot be misused by argument shaping alone.
{
"name": "ticket.update",
"description": "Update status of a ticket the calling user owns.",
"input_schema": {
"type": "object",
"properties": {
"ticket_id": { "type": "string", "pattern": "^TKT-[0-9]{6}$" },
"status": { "type": "string", "enum": ["open", "pending", "closed"] }
},
"required": ["ticket_id", "status"],
"additionalProperties": false
}
}Enums, patterns, and additionalProperties: false are security controls. So is the absence of a free-text field the backend will interpret.
Prompt and context engineering
- What to learn: system/developer/user role separation, structured output, few-shot patterns, context window budgeting, memory summarization, retrieval placement in the prompt.
- Security-relevant detail: the durable idea is provenance of context. Every token in the window came from somewhere — operator, user, retrieved document, tool output, prior turn — and the model does not natively distinguish authority between them. Your job is to keep instruction and data channels separable, mark untrusted content explicitly, and never assume delimiters alone will hold.
- Study move: take a prompt you wrote and annotate each block with its source and trust level. The blocks you cannot label are your risk.
“Prompt hardening” is mitigation, not control. Instructions telling the model to ignore injected instructions reduce success rate; they do not bound impact. Bounded impact comes from Layer 1 and Layer 2 — credential scope, egress policy, tool schemas, approval gates. Learn prompt engineering well enough to know exactly how far it gets you.
Vector databases and RAG pipelines
Pinecone, Weaviate, pgvector, and the pipeline around them: chunking, embedding, indexing, retrieval, reranking, injection into context.
- What to learn: build one end to end. Understand chunk boundaries, embedding model choice, similarity metrics, top-k tuning, and metadata filtering.
- Security-relevant detail: this is the foundation for defending against RAG poisoning and indirect injection. You cannot reason about poisoning without knowing how content gets in (ingestion pipeline, who can write to it), how it gets selected (similarity, which an attacker can optimize against), and what happens when it lands in context (it looks like every other token). Metadata filtering is also your multi-tenant isolation boundary — if per-tenant scoping is applied after retrieval instead of inside the query, you have a cross-tenant leak waiting.
- Study move: poison your own index. Insert a document crafted to be retrieved for a common query and to contain an instruction. Then implement the fixes: source allowlists, ingestion-time review, provenance metadata carried into the prompt, and tenant filters pushed into the query.
Local LLM operation
Ollama for local experimentation, vLLM for serving with throughput.
- What to learn: running quantized models locally, serving an OpenAI-compatible endpoint, batching and memory behavior, GPU constraints, and the real quality trade-off versus frontier models.
- Security-relevant detail: local operation is the architecture answer for data that must not leave a boundary — regulated data, customer content under contractual restriction, material an incident response team cannot send to a third party. It is also how you run red team experiments repeatedly without provider rate limits or acceptable-use friction. Know the cost honestly: weaker reasoning, more infrastructure, and a model supply chain of your own to verify (where did the weights come from, and did you check the hash?).
- Study move: run the same red team prompt set against a hosted model and a local one, and note where behavior diverges.
Tool category → attack you understand → defense you build
| Tool category | The attack it lets you understand | The defense it lets you build |
|---|---|---|
| AI coding assistants | Indirect injection through repository and dependency content; over-broad shell approval | Scoped approval policies, untrusted-content handling in dev workflows |
| Orchestration frameworks | Privilege escalation through delegation; runaway loops; cross-agent tool access | Per-agent tool allowlists, step and token budgets, explicit termination conditions |
| MCP | Malicious or shadowing tool servers; injection via tool descriptions; excessive capability grants | Server allowlists, signed and verified manifests, tight tool schemas, capability review before install |
| Prompt / context engineering | Instruction/data confusion; context overflow pushing out safety framing | Provenance labeling, channel separation, structured output validation |
| Vector DBs and RAG | RAG poisoning, indirect injection, cross-tenant retrieval leakage | Ingestion allowlists, provenance metadata, tenant filters in the query, retrieval auditing |
| Local LLMs | Model supply chain risk; unverified weights | In-boundary deployment for sensitive data, artifact verification, reproducible red team harnesses |
Where this connects: attack detail lives in OWASP LLM Top 10 and OWASP Agentic Threats; hands-on practice is Lab 2 and Lab 3; the tool landscape is catalogued in agent frameworks and red team tools.
Frameworks churn fast. Names on this page will age, and some will be gone. The durable skill is the pattern, not the API: planner/executor loops, tool schemas as a permission surface, memory stores as persistent state an attacker wants to write to, retrieval as an untrusted input channel, and delegation as authority transfer. Learn one framework deeply enough to see the pattern underneath, then treat the next one as a syntax change.
Memory: the component nobody threat models
Every framework on this page has some notion of memory — conversation history, a summarized scratchpad, a persistent store keyed by user or session. It is treated as an implementation detail in tutorials and it is a first-class attack surface in practice.
| Memory type | What it holds | Why an attacker wants it |
|---|---|---|
| Conversation buffer | Recent turns, verbatim | Cheapest place to leave an instruction that survives the current step |
| Summarized memory | Model-generated compression of history | An injected instruction can be summarized into the durable record, laundering its origin |
| Long-term store | Facts, preferences, prior task outcomes | Persistence. An instruction written here executes on every future session |
| Shared / crew memory | State visible to multiple agents | Lateral movement between agents that otherwise have different privileges |
Questions to ask of any memory implementation: who can write to it, is a write ever triggered by untrusted content, does it carry provenance, is it scoped per user and per tenant, does it expire, and can you show an auditor what was in it at the time of an action. Most default implementations answer badly on at least four of those.
A reasonable build order
| Week-ish | Build | You will have learned |
|---|---|---|
| 1 | Single agent, two tools, no framework — raw API calls and your own loop | What a framework is actually doing for you |
| 2 | Same agent in LangGraph or equivalent, with explicit state and termination | Control flow, state, and where authorization has to live |
| 3 | Expose your tools over MCP, consume them from a separate client | Tool exposure as a permission surface |
| 4 | Add RAG with a real vector store and tenant metadata | Ingestion, retrieval, and the poisoning surface |
| 5 | Point the whole thing at a local model, then red team it | Boundary-preserving architecture and repeatable testing |
That progression is the backbone of Month 2.
Self-check
- I have written an agent loop without a framework, and I can say what the framework replaced.
- I can name where authorization is enforced in the orchestration framework I use.
- I have written an MCP server and a schema that constrains arguments meaningfully.
- I can label every block of a prompt with its source and trust level.
- I have poisoned my own RAG index and then fixed it.
- I know which of my retrieval filters run in the query versus after it.
- I have served a local model and can state the honest trade-off.
- I can describe the planner/executor pattern without naming a single vendor.
- I can say who is able to write to my agent’s memory, and whether untrusted content ever triggers a write.
- I have built at least one thing in this layer that I would be comfortable demoing live.
Next: Layer 4 — Agentic Security Specialization, where this hands-on knowledge gets mapped to the frameworks people hire against.