Skip to main content
Answers to the questions teams ask most when evaluating or rolling out Sparkle. For issues with a specific setup, see Troubleshooting.
No. SAST finds vulnerabilities in code that already exists. Sparkle prevents classes of issues from being written in the first place by giving agents the rules before generation, then verifies the output against those rules.Most teams run both: Sparkle reduces the volume of findings reaching SAST and review, and SAST remains the deep static-analysis backstop.
Sparkle analyzes your repositories to generate guardrails and verify changes, but it is not a code host. Your code stays in your git provider.For details on what is processed, what is retained, and for how long, contact team@sparkle.security for the current data handling documentation.
Yes. Cursor, Windsurf, and VS Code use the Sparkle Guardrails extension. Claude Code and Codex are configured through the Sparkle CLI:
sparkle setup --ide claudeCode
Any MCP-compatible agent can also use the Sparkle MCP server directly.
Yes. Sparkle generates rules from each repo’s actual stack, structure, and patterns, and scopes them by git remote. A rule fetched for acme/payments-api never applies to code in another repo.
Yes. Sparkle applies guardrails at the repo level. When you change files in more than one repository, Sparkle resolves each repo from its git remote and fetches that repo’s guardrails separately. Rules from one repo are never applied to another.
Yes. Sparkle identifies a repository by its git remote. When you code in a worktree, Sparkle resolves the same repo and applies the same guardrails as it would from the primary working tree.
Yes. Organization rules — for example, “never log tokens, credentials, or PII” — are defined once in the workspace and returned alongside repo-specific rules on every get_guardrails call. Developers get one merged rule set per task and don’t manage the layering.
Guardrails are context, not a hard block: an agent follows them during generation, and Sparkle verifies the output afterward. If a developer intentionally deviates — say, a legitimate exception to a pattern — the deviation is visible in verification and the guardrails summary rather than silently ignored.This keeps the decision with the developer while giving security teams a record of where and why rules weren’t followed.
Guardrails are fetched fresh at the start of every coding task, so day-to-day you do nothing. Regenerate a repo’s guardrails when its architecture changes meaningfully — a new framework, a new service boundary, a new auth flow. Organization policy updates apply centrally on the next task.
A hand-written rules.md works until it doesn’t:
  • It goes stale as the codebase changes. Sparkle keeps guardrails fresh from the current code.
  • It reflects what one author knew to write down. Sparkle covers security standards (OWASP, PCI-DSS) systematically.
  • It’s per-repo and inconsistent across a fleet. Sparkle layers organization rules onto every repo uniformly.
  • Nothing checks whether the agent followed it. Sparkle verifies output and records which rules were applied.
If you already have a good rules.md, that knowledge feeds into the same system — with verification and governance on top.

​
Still have questions?

Email team@sparkle.security.