Prompt and Context Design for LLM Code Security

Two security agents built on the same model can produce wildly different results, and the difference is almost never the model — it is what each agent puts in the context window and what it leaves out. Context design is the highest-leverage and most underrated part of building a Claude agent that secures source code. Feed it the wrong things and it hallucinates vulnerabilities in safe code; feed it too much and it loses the thread; leave out a single config fact and it misjudges whether an input is escaped. This post is about getting that selection right — the affirmative choices and, just as important, the deliberate omissions.

Start from the question the model must answer

Every piece of context should earn its place by helping answer one question: can untrusted input reach a dangerous operation here, and is that exploitable? Work backward from that. The model needs the sink (the dangerous operation), the path from a trust boundary to that sink, the behavior of anything that transforms the value along the way, and the framework rules that govern whether the value is neutralized. Everything else — unrelated functions, formatting, comments about business logic — is noise that dilutes attention and inflates cost.

This sounds obvious, but the default behavior of most homegrown agents is to dump whole files because that is easy. A file is the wrong granularity. The right granularity is the slice: the specific code on the data path, assembled deliberately. Designing context means building that slice, not pasting a file and hoping.

Label the context so the model knows each piece's role

An assembled slice is far more useful when each part is tagged with the role it plays. Mark the sink as the sink, the caller chain as the path to the trust boundary, helper definitions as transforms, and configuration as the rules. A model reasons more sharply over [TRUST BOUNDARY: HTTP handler] followed by [SINK: raw SQL execution] than over the same code presented as an undifferentiated wall. The labels are cheap and they pay for themselves in precision.

flowchart TD
  A["Candidate sink"] --> B["Include: sink + caller path"]
  B --> C["Include: transforms on the value"]
  C --> D["Include: framework escaping rules"]
  D --> E{"Enough to decide?"}
  E -->|No| F["Retrieve missing definition"]
  F --> C
  E -->|Yes| G["Exclude: unrelated code & noise"]
  G --> H["Reason & verify"]

Notice the loop in the middle: context design is iterative, not one-shot. The agent assembles what it can, checks whether that is sufficient to decide, and retrieves a specific missing definition if not. The exclusion step at the end is just as intentional as the inclusions — once the model has enough, you stop adding, because more context past the decision point only adds cost and distraction.

Put framework facts in context, not in the model's memory

The most common source of both false positives and false negatives is stale assumptions about the framework. Does this ORM parameterize queries by default? Does this template engine auto-escape HTML? Does this router decode the path before or after the handler sees it? If the model answers from its training memory, it will sometimes be right and sometimes be confidently, dangerously wrong. So put the relevant framework behavior into the retrieved slice explicitly — the ORM's query method signature, the template config, the middleware order. Grounding these facts in the actual code removes a whole category of errors that no amount of clever prompting fixes.

This is also how you keep the agent correct across upgrades. When a dependency changes its escaping defaults, the agent stays accurate automatically because it reads the current configuration rather than recalling an old default. The general principle: anything that can drift belongs in context, not in the prompt and not in the model's head.

The negative space: what to deliberately leave out

Good context design is as much about omission as inclusion. Leave out code that is not on the data path — it cannot change the answer and it costs attention. Leave out generated files, vendored dependencies, and lockfiles unless a specific question touches them. Leave out long license headers and dead branches. And critically, leave out instructions that turn the model into a checklist scanner; the more you enumerate vulnerability classes to hunt for, the more the model pattern-matches and the more false positives you get. The model already knows the vulnerability classes; what it needs from context is the specific evidence to decide this case.

There is one subtle inclusion that is easy to forget: the trust assumptions of the system. Tell the model which inputs are externally controlled and which are not, because reachability from a trust boundary is the hinge of every judgment. A value that looks dangerous is harmless if it can only come from a trusted internal source, and the model cannot infer that from code alone — it needs the boundary marked.

Designing context for the verification step

Context design does not end at the reasoning step; the verification step needs its own. When the agent attempts a reproduction, give it exactly what it needs to write a faithful proof — the entry-point signature, the expected input format, the shape of a valid request — and nothing that would let it reach outside the sandbox. A well-scoped verification context produces proofs that actually exercise the real path instead of a simplified stand-in that proves nothing. The discipline is identical to the reasoning step: include what answers the question, exclude everything that does not, and ground anything that could drift.

Frequently asked questions

How much code should go in the context window?

Only the code on the data path needed to answer whether untrusted input can reach a dangerous operation — the sink, the caller chain to a trust boundary, transforms on the value, and the governing framework config. Whole files are the wrong granularity; assemble a focused, labeled slice and stop adding once the decision can be made.

Why put framework behavior in context instead of trusting the model?

Because framework defaults drift and the model's memory of them goes stale, producing both false positives and false negatives. Grounding escaping, parameterization, and routing behavior in the actual current configuration keeps judgments correct across dependency upgrades without re-tuning the prompt.

What should be deliberately excluded from context?

Code off the data path, generated and vendored files, lockfiles, license headers, dead branches, and long checklists of vulnerability classes to hunt. Excess context dilutes attention and raises cost, and checklist-style instructions push the model toward noisy pattern matching instead of grounded reasoning.

Bringing agentic AI to your phone lines

CallSphere applies the same context discipline to voice and chat agents — giving each one exactly the customer and business context it needs to act correctly, and nothing that would distract it — so it answers every call and message and books work 24/7. 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.