Prompt and Context Design for Claude Security Agents

You can wire up flawless MCP servers, scoped credentials, and a bulletproof gate, and still end up with a Claude security agent that gives sloppy, unsafe, or expensive answers. The reason is almost always the same: poor context design. What you put in front of the model — and just as importantly, what you withhold — determines whether it reasons like a careful analyst or a distracted one. For security and compliance work, getting this right is not a polish step; it is a control.

This post is about the deliberate craft of deciding what goes into context. Not the architecture, not the plumbing — the information design. I will argue for a specific stance: in security agents, context should be lean, intentional, and structured, and the instinct to "give the model everything just in case" is actively harmful.

Why context design is a security decision

Every token you put in front of a security agent is a small risk and a small cost. Risk, because sensitive data in context can surface in outputs, logs, or downstream calls where you did not intend it. Cost, because bloated context inflates spend and latency. And subtly, accuracy, because a model swamped in irrelevant detail reasons worse than one given a tight, relevant briefing. These three pressures all point the same way: include less, but include it deliberately.

The reframe that helps is to stop thinking of context as a container you fill and start thinking of it as a briefing you write for a sharp analyst who has limited time. You would not hand that analyst your entire findings database; you would hand them the case, the relevant policy, and the few facts that bear on the decision. The same judgment applies to the model. Good context design is the practice of writing that briefing well, every time, automatically.

The four buckets: what actually belongs in context

I find it useful to sort everything that could go into context into four buckets. First, stable procedure — how your team triages, what evidence a control needs, your escalation rules. This belongs in skills, loaded only when relevant, not pasted into every prompt. Second, the case at hand — the specific finding, the asset, the control being evaluated. This belongs in context, summarized and typed. Third, boundaries — what the agent may and may not do, stated in the system prompt so the model's behavior aligns with the gates. Fourth, everything else, which belongs nowhere near the prompt and should be fetched on demand if a specific case needs it.

flowchart TD
  A["Candidate information"] --> B{"What kind?"}
  B -->|Stable procedure| C["Put in a skill, load on match"]
  B -->|This specific case| D["Summarize & type into context"]
  B -->|Boundaries & rules| E["State in system prompt"]
  B -->|Bulk / sensitive detail| F["Leave out, fetch on demand"]
  C --> G["Lean, intentional context"]
  D --> G
  E --> G
  F --> G

The discipline is to route every candidate piece of information through this decision before it reaches the model. Most teams default everything into bucket two and drown the model. The skill of context design is moving stable knowledge to bucket one, rules to bucket three, and bulk to bucket four, so that bucket two stays small and sharp. That routing, done consistently, is what produces a fast, accurate, defensible agent.

What to deliberately leave out

The leave-out list is where security agents earn their keep. Do not put raw credentials, full secret values, or unredacted PII in context — the model does not need them to reason, and their presence is a leak waiting to happen. Do not paste entire findings databases or asset inventories; return summaries with identifiers and let the agent fetch specifics. Do not inline your whole policy library; load the relevant excerpt via a skill when the task calls for it.

There is a subtler omission too: leave out stale or speculative context. If a finding was remediated yesterday, do not carry yesterday's raw state forward as if it were current; fetch the live state. Models will happily reason over whatever you give them, including outdated facts, and a confident answer built on stale data is worse than no answer in a security context. The rule of thumb: if a piece of information is not needed to make the current decision correctly, leaving it out makes the agent better, not worse.

Structuring what stays: summaries, IDs, and references

Once you have decided what belongs in context, how you shape it matters. Prefer structured summaries over raw payloads: a finding as a few labeled fields, not a wall of vendor JSON. Always include stable identifiers so the agent can fetch more detail and so its output is traceable back to the source. Include audit references where they exist, so the model can cite them in its summaries and close the loop between narrative and log.

This structure does double duty. It makes the model's reasoning cleaner, because labeled, typed facts are easier to reason over than prose blobs. And it makes the model's output more useful to the humans downstream, because an answer that says "finding F-1042 on asset web-prod-3, audit ref A-88" can be verified, whereas "a critical issue on a production server" cannot. In compliance work, traceable output is the whole point, and you get it largely for free by structuring context well.

Designing the system prompt as a boundary statement

The system prompt deserves special care because it sets the agent's stance. For a security agent, write it as an honest statement of boundaries and intent: the role, the tools available, the rule that destructive actions require approval, the instruction to refuse and explain rather than improvise outside its tools, and the expectation that it cite finding ids and audit references. Keep it tight — a system prompt that rambles dilutes its own authority.

The key principle is alignment: the prompt should describe the real constraints the architecture enforces, not aspirational ones. If the prompt claims the agent cannot delete findings, there should genuinely be no delete tool. When the stated boundaries and the enforced gates match, the model settles into calm, predictable behavior within bounds. When they diverge — the prompt forbids something the tools actually allow, or permits something the gate blocks — you get an agent that either oversteps or keeps proposing rejected actions. Write the prompt to tell the truth about the system.

Iterating with evals, not vibes

Context design is not a one-shot decision; it is something you tune. The right way to tune it is with evals — a held-out set of real security tasks with known good outcomes — rather than by gut feel after a few demos. When accuracy drops, the eval tells you whether you withheld a fact the model genuinely needed, and you can add that one fact deliberately rather than reflexively widening the context dump.

This closes the loop on the whole discipline. You start lean, measure, and add back only what the evidence says you must. That is the opposite of the common pattern of starting bloated and never daring to trim. For a security agent, a tight context proven by evals is both cheaper and safer, and you can show your reasoning to a reviewer. Context design, done with evals, becomes an auditable engineering practice rather than an art.

Frequently asked questions

Should policy documents go in the prompt or a skill?

In a skill, loaded when the task matches, not pasted into every prompt. Skills keep your policy versioned and reviewable while loading only the relevant excerpt when needed, which keeps context lean. Inlining the whole policy library bloats every request and makes your compliance rules invisible to review.

How do I stop sensitive data from leaking into outputs?

The most reliable defense is to never put it in context in the first place. Return summaries and identifiers from your tools, redact at the MCP server boundary, and let the agent fetch specific detail only when a case requires it. What the model never sees, it cannot leak; context minimization is a data-protection control, not just a cost lever.

Is a longer context always more accurate?

No — often the opposite. A model given a tight, relevant briefing reasons more sharply than one swamped in noise, and irrelevant detail can actively mislead it. Bigger context windows let you include more, but the discipline is to include only what the current decision needs. Measure accuracy with evals rather than assuming more context helps.

How do I keep the system prompt aligned with the real controls?

Treat the prompt as documentation of the architecture and test that alignment. If the prompt says destructive actions need approval, assert in your test suite that the gate actually enforces it; if it says the agent has no delete tool, confirm none exists. When prompt claims and enforced gates match, behavior is predictable; when they drift, you get oversteps or repeated rejections.

Bringing agentic AI to your phone lines

CallSphere applies this same context discipline to voice and chat — agents that carry just the right context into every call, act through audited tools, and handle calls and messages 24/7 without leaking what they shouldn't. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.