The Safeguard extension for Cursor is built for inline security scanning, guardrails and fixes while you code. It is a source of useful signals for an audit, but it is not the place where audit evidence is assembled. That work lives in Safeguard's compliance tabs in the web app.
What does the extension do?
The extension is published on Open VSX, the registry Cursor, Windsurf, Codium and other compatible editors use in place of the Visual Studio Marketplace. Safeguard's download page describes IDE extensions as providing inline security scanning, guardrail enforcement and one-click remediation inside your editor. It also lists inline security annotations, in the style of git blame.
That is the full scope we can confirm. The docs do not describe the Cursor extension producing reports, exports or evidence packages, so this post does not claim it does.
Why would an auditor care about editor behaviour?
Auditors rarely ask what plugin you used. They ask whether your process catches problems before release, and whether you can show it. Typical questions under secure development controls include how code is reviewed, how vulnerable dependencies are found and how findings get fixed.
Inline findings help the process happen. They do not prove it happened. Proof is a record that is dated, attributable and hard to rewrite after the fact, such as pull request checks, scan results from CI and tickets that show a finding opened and closed.
Where does the evidence come from, then?
Safeguard's compliance suite in the web app has tabs for frameworks, controls, evidence, monitoring, tests and questionnaires. Evidence there is collected by connectors and mapped to controls. The CLI documentation also describes a report command that generates a report from an existing scan result, described as the artifact you hand an auditor. The documentation does not list its formats or flags, so run the built-in help on your installed build before promising a format.
The practical split:
- In Cursor: developers see and fix issues early, which reduces what reaches review.
- In CI and the CLI: scans run the same way every time and write results to files.
- In the platform: results map to controls and sit in one evidence store with dates.
Does the extension help with other evidence?
Indirectly. If developers fix issues before opening a pull request, your CI scan and your audit sample will look cleaner. But fewer findings is a result, not a record. Do not tell an auditor that the extension demonstrates control operation.
What to do
- Install the Safeguard extension from Open VSX in Cursor, and confirm it signs in to your workspace.
- Write down the control it supports, such as finding vulnerable code during development, in your control description.
- Run the CLI scan in CI so every merge produces a dated result file.
- Use the compliance Evidence tab in the web app to attach scan results to the control.
- Keep ticket history showing findings opened and fixed.
- Before the audit, sample a few merged pull requests and walk the trail from finding to fix.
If a surface cannot show a step, say so in your control narrative. A narrow, accurate description passes an auditor's questions better than a broad one.
Quick check
Can I send an auditor a screenshot of the extension instead of evidence?
It is weak evidence. A screenshot shows the extension is installed, not that findings were handled. Prefer dated scan results, pull request checks and tickets.
Does the extension work in VS Code too?
Safeguard lists a separate extension for VS Code on its download page. The Open VSX one is for Cursor and compatible editors.
Sources
Last reviewed: 18 October 2026.
