Prompt and Context Design for Claude Threat Detection

There's a tempting fallacy in agent design: that more context means better decisions. In threat detection it's often the opposite. An agent that's handed a thousand surrounding log lines, the full threat-intel dump, and every asset record will reason worse than one given a tight, curated slice — it loses the signal in the noise and burns budget doing it. The hardest and most valuable skill in building a Claude Code security agent is context discipline: deciding precisely what to put in front of the model, what to withhold, and why. This post is about that discipline.

Context engineering is the practice of deliberately choosing which information a model sees at each step of a task, so that what's present is relevant and what's irrelevant is excluded. For a security agent, good context engineering is the difference between a sharp verdict and a confused one.

Start with the smallest seed that defines the question

The investigation should begin with almost nothing — just the seed that frames what to decide. For an impossible-travel alert, that's the user, the two locations, the timestamps, and a case ID. Not the raw auth logs, not the user's entire history, not the org's threat-intel feed. Everything beyond the seed should arrive only because the agent asked for it through a tool. This inversion — pull, don't push — is the core move. It keeps the model's working context small and, crucially, it makes the agent's information-gathering auditable, because every fact in the final context got there by an explicit, logged tool call.

When you push context in by default, you lose both properties: the model wades through irrelevance, and you can't tell which of the thousand lines actually drove the verdict. Pull-based context turns the transcript into a clean record of reasoning.

What belongs in the system prompt

The system prompt should hold the things that are true for every investigation of this type and rarely change: the agent's role, the procedure to follow, the decision criteria, the verdict schema, and the budget. These are stable. They define how the agent thinks, not what it thinks about. Put the impossible-travel decision criteria here — is the travel physically possible, is the second location in the user's pattern, do the IPs have reputation — because they apply to every instance of this alert.

What does not belong in the system prompt is anything instance-specific or anything sensitive. No credentials, ever. No raw data that the agent should fetch fresh per case. Keeping the system prompt to stable procedure means you can cache it across investigations and version it independently, and it means a single edit to the criteria improves every future case at once.

flowchart TD
  A["Seed only enters context"] --> B["System prompt: role, criteria, schema"]
  B --> C{"Need more facts?"}
  C -->|Yes| D["Pull one targeted tool result"]
  D --> E["Summarize result into compact fact"]
  E --> C
  C -->|No| F["Reason over curated facts only"]
  F --> G["Emit verdict + cited evidence"]
  G --> H["Persist digest, drop raw transcript"]

Summarize tool results before they accumulate

A subtle context killer is letting raw tool output pile up. A single query_logins call might return hundreds of records. Dumping all of them into context for the rest of the investigation drowns later reasoning. Instead, have the agent — or a lightweight summarization step — distill each tool result into the compact fact that matters: "user has 47 logins in the last 90 days, all from two cities, none matching the alert's location." That one sentence carries the decision-relevant signal; the raw records can be referenced by ID but don't need to live in context.

This is where a cheaper model in the loop earns its place. Using a fast model like Haiku to compress verbose tool output, while the orchestrating agent runs on a stronger model for judgment, keeps context lean and cost sane. The strong model reasons over a handful of distilled facts rather than a wall of logs.

What to deliberately leave out

Three things should almost never enter the model's context. First, secrets and credentials — they belong at the transport layer, invisible to the model. Second, irrelevant breadth — the full intel feed when you only need one IP's reputation; fetch the specific lookup instead. Third, prior verdicts in raw form — when continuing an open case, load a compact case digest, not the entire previous transcript. Withholding is an active design choice, and the things you leave out protect both accuracy and your audit posture.

There's also a security reason to withhold: anything in context can, in principle, influence the model. If an attacker can get hostile text into a log line and you blindly push that log into context, you've opened a prompt-injection surface. Pulling only specific, typed facts through schema-validated tools shrinks that surface dramatically, because raw attacker-controlled strings never become free-form context.

Design context for replay, not just for now

Because the agent only ever reasons over a curated set of pulled facts, you can persist exactly that set with the verdict and replay it later against an improved prompt. This is impossible if context is a sprawling, ad-hoc dump. Treat the curated context as the durable artifact of an investigation: small, explicit, and reproducible. When you tune your decision criteria next quarter, you can rerun every historical case over its original facts and measure whether verdicts improved — the payoff of disciplined context is a platform you can actually evaluate.

Frequently asked questions

Won't withholding context cause the agent to miss things?

Only if the agent can't fetch what it needs. The model is pulling, not guessing — when a decision requires more data, it calls a tool. Withholding by default plus pull-on-demand gives you both lean context and completeness, without drowning judgment in noise.

How does context design affect prompt-injection risk?

Significantly. Raw attacker-controlled text in context is an injection surface. By pulling only typed, schema-validated facts through tools and summarizing them, you keep hostile free-form strings out of the model's working context and shrink the attack surface.

Why summarize tool output instead of keeping it all?

Because raw output buries the signal and inflates cost. Distilling each result to its decision-relevant fact keeps later reasoning sharp, and using a fast model to do the compression keeps the strong model focused on judgment over a clean, small set of facts.

Bringing agentic AI to your phone lines

CallSphere applies the same context discipline — pull only what's relevant, summarize aggressively, withhold the rest — to voice and chat agents that stay sharp across long conversations and book work 24/7. Hear it for yourself 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.