Skip to main content

Security Assumptions

What Manicode Guarantees​

  1. Prompt content is reviewed and versioned. Every prompt in the library undergoes review before release. Changes are tracked in Git with full diff history.
  2. Prompts encode known-good security patterns. Each prompt is written from the technology's official documentation and security advisories for its exact version, and its rules are mapped to CWE entries, shown in the registry.
  3. Prompts are inert. They contain no executable code, no network calls, and no side effects. They are plain text system instructions.

Limitations​

Manicode does not guarantee:

  1. Correct output. LLMs are non-deterministic. A security prompt reduces the probability of insecure code but does not eliminate it. The model may still generate code with vulnerabilities.
  2. Complete coverage. Security prompts cover known vulnerability classes for their target framework. Zero-day vulnerabilities, novel attack techniques, and framework-specific bugs discovered after the prompt was written are not covered.
  3. Deterministic behavior. The same prompt, model, and input may produce different outputs on different runs. Temperature, sampling, and model version all affect output.
  4. Resistance to prompt injection. If an attacker can modify the system prompt or inject instructions through user input, the security constraints in the prompt can be overridden. Code generation is vulnerable to prompt injection through user-controlled input.
  5. Consistency across models. The same prompt may behave differently on Claude Opus 5.5, GPT-6 Astra, or Gemini 4 Argon.
  6. Fit for your environment. Security controls in generated code should be checked against your own deployment environment.

Trust Boundaries​

What You Control​

  • Prompt content — You choose which prompts to copy into your code repos. Changes to those copies go through your standard code review process.
  • Deployment configuration — You decide where prompts run (IDE, CI, API) and who has access.
  • Review gates — You determine which outputs require human review before adoption.

Threat Model​

Prompt Injection​

Risk: An attacker embeds instructions in user input, retrieved documents (RAG), or code comments that override the security prompt's constraints.

Mitigation:

  • Keep the system prompt under your control, and treat user input, retrieved documents, and code comments as untrusted
  • Defense is probabilistic, not guaranteed — sophisticated injection attempts may evade detection

Residual risk: High for applications processing untrusted user input.

Context Poisoning​

Risk: Malicious content in the context window (uploaded files, repository code, retrieved documents) causes the model to generate insecure output despite the security prompt.

Mitigation:

  • Review generated code before use, especially when the context includes untrusted files or retrieved documents

Residual risk: Medium. Context poisoning is harder to execute than direct prompt injection but harder to detect.

Model Hallucination​

Risk: The model generates plausible but incorrect security implementations — for example, a cryptographic function with the wrong parameters, or an authorization check that is syntactically correct but logically flawed.

Mitigation:

  • Security prompts encode specific, concrete patterns (e.g., "use Argon2id with at least m=19456 KiB, t=2, p=1") rather than abstract guidance

Residual risk: Medium. Hallucinated security logic is especially dangerous because it looks correct to non-specialists.

Incomplete Control Enforcement​

Risk: The model follows some security constraints from the prompt but ignores others, particularly in long or complex outputs.

Mitigation:

  • Each prompt covers one technology version, so it carries only the rules that apply to that code
  • Splitting tasks into smaller requests reduces the chance of constraint drift

Residual risk: Medium. Constraint adherence degrades with output length and complexity.

Output Misinterpretation​

Risk: A developer accepts model output as correct without understanding its security implications, or misapplies generated code to a different context where it is not secure.

Mitigation:

  • Have a developer with security knowledge review generated code before production use (see below)

Residual risk: Low to medium. Depends on the developer's security knowledge and review process.

Model Provider Changes​

Risk: The LLM provider updates the model (weights, safety filters, system prompt handling), changing how prompts are interpreted. A prompt that worked yesterday may behave differently after a model update.

Mitigation:

  • Pin model versions in API calls where possible (e.g., claude-opus-5-5)
  • Test prompts against your specific use cases after model updates

Residual risk: Low to medium. Model updates are infrequent but can have unexpected effects.

Required Human Review Points​

Generated code for production should always be reviewed by a developer with security knowledge before use. LLM output may contain subtle vulnerabilities.

Defense in Depth​

Manicode prompts are one layer in a defense-in-depth strategy. They are not a substitute for:

  • Static analysis (SAST) — Tools like Semgrep, CodeQL, or SonarQube catch vulnerability patterns that prompts may miss
  • Dynamic testing (DAST) — Runtime testing catches issues that static analysis and prompts cannot
  • Dependency scanning — Tools like Dependabot, Snyk, or Trivy catch vulnerabilities in third-party packages
  • Code review — Human reviewers catch logical errors and context-specific issues
  • Security training — Developers need to understand security concepts, not just rely on AI guardrails
  • Penetration testing — Red team testing validates the entire security posture, not just code quality

Use Manicode prompts alongside these practices, not as a replacement for them.