mimosa-security-scan

Mimosa Security Scan

Run only when the user explicitly requests a deep security audit. Mimosa returns sealed scan artifacts and status; do not put it into daily Hooks.

Execute workflow

1. Call security_scan_start, default depth: "deep", use the user-specified scope for the project path. It should return immediately jobId, to avoid a large repository scan occupying the host's single tool-call window.
   • If the tool is unavailable, stop and prompt the user to enable Mimosa MCP and retry; do not switch to a self-managed model path.
2. Use security_scan_status({jobId}) to poll; a single call only reads the current persistent state and does not wait for a long time.
   • running: continue polling later; do not present an unfinished task as a final audit result.
   • User requests stop: call security_scan_cancel, then use status to confirm cancelled。
   • interrupted、cancelled or failed and the user requests to continue: call security_scan_resume; it increments attempt by one and safely reruns unsealed attempts, without treating a half-finished product as a checkpoint; this is a retry, not a resumed scan.
   • completed: read the returned scanId, scanDir, seal, finding summary, and dependencySummary (if any).
3. Deliver the scan ID, seal, dependency risks, and the returned finding summary; do not additionally call other MCP tools, modify code, or execute the target project.

Conclusion discipline

• Do not automatically modify code, and do not execute the target project.
• Do not automatically conclude that the "project is completely secure" or "risk-free".

Delivery order

The final report gives, in order:

1. Scan target, scan ID, seal status, and artifact directory;
2. Dependency risk summary (if any);
3. Returned finding summary.

When you need to explain sealed artifacts, history lists, or compare semantics, read scan contract。