Context Engineering for Application Security | Endor Labs

What it is

An Endor Labs whitepaper on "context engineering" for AI coding assistants: assembling prompts, rules, tool output and retrieved data so the model avoids insecure code at generation time. Its running example is a "hook up to the DB, pull recent users, add a leaderboard" prompt that yields an endpoint with no authorization and no rate limiting. SAST misses both because they are business-logic flaws, not CWEs.

How it works

The page gives reusable text you can copy.

Prompt patterns (design-spec and test-first), applied through priming, decomposition or refinement. Priming example: require authorization checks for authenticated users and a rate limit of 5 requests per second on the endpoint. Decomposition sends the same requirements as separate sequential prompts: endpoint, then authorization, then throttling, then sorting. Refinement asks the model to review its own code for authorization, then to write a fuzzing-style security test against the endpoint.

Rule categories, each with a sample:

• Enforce standards: every DB-touching function or endpoint must call a named permission check (AuthService.checkPermission(User, 'READ_RECENT_USERS')).
• Guide logic: parameterized queries or ORM-safe methods only, and schema validation on all inputs, including sort, filter and limit parameters.
• Define context: a RateLimiter library behind the API gateway, defaulting to 10 requests per minute per user ID.
• Manage scope: any new dependency, new endpoint or direct DB query makes the model insert // @SECURITY_REVIEW_REQUIRED at the top of the file, to trigger human review.

CSA R.A.I.L.G.U.A.R.D. is a checklist for writing rules: Risk first, Attached constraints, Interpretative framing, Local defaults, Gen path checks, Uncertainty disclosure, Auditability, Revision + dialogue.

External tools over MCP. An .mcp.json-style config declares the tool, and a separate rule tells the model when to call it. The page's Cursor rule for Endor Labs SAST has alwaysApply: true and a broad file glob. It requires a scan via endor-cli-tools immediately after any matching file is created or modified. The agent must then auto-fix findings and loop until critical issues are resolved. Tool-call errors must be self-corrected and retried, and results logged to .cursor/security-scan.log. The scan path must be an absolute directory, not a file.

The page argues this fixes what prompts and rules cannot: stale training data (averaging over a year old), CVEs issued after the cutoff, and hallucinated dependencies that enable slopsquatting.

What to do

• Put the authorization, input-validation, rate-limit and review-flag rules in repo or org-level rule files rather than relying on individual prompting habits.
• Wire SAST, SCA and secrets scanning in over MCP, and scope them with globs so they don't produce needless scans and cost developer trust.
• Review community-sourced rules before adopting them by asking an LLM: "Review these instructions and tell me all the ways they could open us up to an exploit."
• Treat MCP servers as dependencies, using the page's five pillars:
• Visibility and control: registry or allowlist, vetting of new servers, usage visibility.
• Pre-deployment vetting: SAST/SCA on the server, review of sensitive API use, review of its prompts.
• Operational security: package discipline, prompt integrity, least privilege.
• Continuous monitoring: runtime monitoring (Inspector is named), action and data tracking, host resource access.
• Developer enablement: training and security champions.
• Cursor Hooks are described as an alternative that intercepts agent actions such as npm install, scanning for malware and blocking before local install. The page says Cursor is "working on" them.

Caveats

• Rules raise token spend. Cheaper or free models ignore them more often: in the author's BSides London workshop, about 25% of participants had their models completely ignore the security rules they wrote.
• MCP configs and rules are deployed machine by machine, which is hard to scale. A noisy scanner just moves noise into developer workflows.
• The page says it has seen little real-world MCP exploitation but expects it.
• Statistics are cited, not shown: 62% of AI-generated solutions contain design flaws or vulnerabilities; about 80% of imported dependencies were hallucinated or vulnerable (Endor Labs' own finding); a recursive self-audit prompting technique cut weaknesses by 77.5%. These come from the page's references, which were not checked here.
• The long Cursor sample rule on the page is a Python cybersecurity-tooling style guide, not an application-security control. It is a format example only.
• The page is vendor content, and the tool example is Endor's own product.