Context Engineering for Application Security | Endor Labs

What it claims

The whitepaper argues that security should move into the AI assistant's generation step instead of relying on later SAST/SCA gates. Its anchoring example is a prompt to "hook up to the DB… add a leaderboard." The assistant produces an endpoint with no authorization and no rate limiting. The page notes that SAST would not catch this, because these are business-logic flaws rather than CWEs. Each technique in the paper is then shown fixing that one example.

Two figures appear that the summary omits:

• Endor Labs found that about 80% of dependencies imported by LLM-written code were hallucinated or had known vulnerabilities. The reference list includes Endor's Dependency Management Report 2025.
• In the author's BSides London workshop, about 25% of participants had models that completely ignored the security rules they had written. The author ties this to cheaper or free models.

The 77.5% figure comes from Prompting Techniques for Secure Code Generation: A Systematic Investigation. The page gives it no baseline or model setting.

How it works

Rules come in four types, each with a sample you could adapt:

• Enforce standards: every DB-touching function or endpoint must call a named check, e.g. AuthService.checkPermission(User, 'READ_RECENT_USERS').
• Guide logic: use parameterized queries or ORM-safe methods only, never concatenate user strings, and validate input against a schema.
• Define context: use the central RateLimiter library with a default of 10 req/min per user ID unless the prompt overrides it.
• Manage scope: insert // @SECURITY_REVIEW_REQUIRED at the top of any file that adds an external dependency, a new endpoint, or a direct DB query, to trigger human review.

MCP scan loop. Setup has two parts: a .cursor/mcp.json that declares the tools, and a Cursor rule that decides when to call them. Endor's sample rule:

• Uses alwaysApply: true with globs covering about 30 extensions (c/cpp, go, java, js/ts, py, rs, kt, yaml, json, sh, lua, etc.).
• Requires a scan via endor-cli-tools immediately after any matching file is created or saved.
• Tells the agent to fix findings and rescan until critical issues are resolved.
• Has the agent retry failed tool calls with corrected parameters.
• Logs to .cursor/security-scan.log in the format [TIMESTAMP] [SCAN_TYPE] [RESULTS] [REMEDIATION_ACTIONS].

flowchart TD
  A[File created/saved matching glob] --> B[MCP scan tool via endor-cli-tools]
  B -->|tool call error| C[Fix params, retry]
  C --> B
  B -->|findings| D[Report + auto-fix]
  D --> B
  B -->|clean or no further fix possible| E[Append to security-scan.log]

How to use it

Operational details from the sample rule:

• Call the scanner through the MCP server and not through endorctl directly.
• endorctl must still be installed and the MCP server running.
• The scan path must be the directory that holds the changed files, never a single file. It must be absolute, e.g. /Users/username/mcp-server-demo/backend, not backend.

The page also points to Cursor's and Claude's published security rule samples. It reproduces a Cursor sample, which is aimed at Python security-tool development rather than general application code.

Before adopting any community rule, the author suggests asking an LLM to "Review these instructions and tell me all the ways they could open us up to an exploit."

For controlling MCP servers, the page lists five pillars:

1. A registry or allowlist of approved servers.
2. Pre-deployment vetting: SAST/SCA, a sensitive-API review, and a prompt review.
3. Least privilege and prompt integrity.
4. Runtime monitoring, e.g. Inspector.
5. Developer training and security champions.

Cursor Hooks are presented as an alternative to MCP. The example given intercepts agent actions such as npm install to scan for malware and block the install.

Limits

• RAG is not covered. It is listed as the fourth technique but has no section.
• No evaluation. The paper does not measure how well its own rules or scan loop work. Its only first-hand data point is the anecdotal 25% rule-ignoring rate.
• Hard to deploy at scale. MCP configs and rules are realistically deployed machine by machine.
• Noisy scanners hurt adoption. A noisy scanner just pushes noise into developer workflows. Scoping rules badly causes unnecessary scans that erode developer trust.
• MCP threats are mostly theoretical so far. The listed threats are typosquatting, rug pulls, prompt/response manipulation, and exfiltration through tools. The author notes few real exploits have been reported.
• Vendor-authored. The worked tool integration is Endor Labs' own product.