Security Audit
Audit Stages
Stage 1: Policy Validation
Call workbench_validate_policy with the policy YAML. Check for:
- Errors — Schema violations, invalid regex patterns, version mismatches
- Warnings — Empty names, short timeouts, suboptimal configurations
Stage 2: Guard Coverage Analysis
Call workbench_list_guards to get the full registry of 13 guards, then compare against the policy. Identify:
- Active guards — Enabled and properly configured
- Inactive guards — Disabled or missing from the policy
- Coverage gaps — Action types with no guard protection
The 13 guards cover 6 categories:
| Category | Guards |
|---|---|
| Filesystem | ForbiddenPath, PathAllowlist |
| Network | EgressAllowlist |
| Content | SecretLeak, PatchIntegrity |
| Tools | ShellCommand, McpTool |
| Detection | PromptInjection, Jailbreak, SpiderSense |
| Computer Use | ComputerUse, RemoteDesktopSideChannel, InputInjection |
Stage 3: Compliance Scoring
Call workbench_compliance_check against all three frameworks:
- HIPAA (10 requirements) — Healthcare data protection
- SOC 2 (8 requirements) — Service organization trust criteria
- PCI-DSS (7 requirements) — Payment card industry standards
For each framework, note:
- Overall score (percentage of requirements met)
- Specific gaps with citations
- Required guards and settings to close gaps
Stage 4: Scenario Testing
- Call
workbench_suggest_scenariosto generate guard-specific test cases. - Combine suggested scenarios with the 20 built-in scenarios (available via the
workbench://scenarios/builtinresource). - Call
workbench_run_all_scenarioswith the combined scenario set. - Analyze results:
- False negatives — Attacks that were allowed (critical findings)
- False positives — Benign actions that were blocked (operational issues)
- Pass rate — Overall scenario pass/fail percentage
Stage 5: Policy Comparison
If comparing against a baseline (e.g., the strict ruleset):
- Fetch the strict ruleset YAML from the
workbench://rulesets/builtinresource. - Call
workbench_diff_policiesto identify gaps relative to the baseline. - Flag any areas where the policy is weaker than the baseline.
Stage 6: Report Generation
Compile findings into a structured report:
## Security Audit Report
### Validation
- Status: [PASS/FAIL]
- Errors: [count]
- Warnings: [count]
### Guard Coverage
- Active: [X]/13 guards
- Gaps: [list uncovered categories]
### Compliance Scores
- HIPAA: [X]% ([Y]/10 requirements met)
- SOC 2: [X]% ([Y]/8 requirements met)
- PCI-DSS: [X]% ([Y]/7 requirements met)
### Test Results
- Scenarios: [X] total, [Y] passed, [Z] failed
- Pass rate: [X]%
- Critical failures: [list]
### Prioritized Recommendations
1. [CRITICAL] ...
2. [HIGH] ...
3. [MEDIUM] ...
Severity Classification
| Severity | Criteria |
|---|---|
| Critical | Attacks pass through with no guard evaluation; secrets can be exfiltrated |
| High | Guards enabled but misconfigured; compliance gaps in active frameworks |
| Medium | Non-critical guards missing; detection thresholds too permissive |
| Low | Informational; best practices not followed but no direct risk |
Instructions
- Run all 6 stages in order
- Present findings organized by severity (critical first)
- Provide YAML remediation for each finding
- Include compliance citations where relevant
- End with a prioritized action list