Governance & Audit

Code Scalpel pairs precision tooling with governance: server-enforced boundaries, complete audit trails, and cryptographic policy verification with compliance evidence generation.

๐Ÿ—๏ธ Security Architecture

Understanding where security boundaries are enforced and how data flows through Code Scalpel:

AI Agent / MCP Client (Claude Desktop, Cursor, etc.) MCP Protocol Code Scalpel MCP Server Policy Enforcement Engine Audit Logger Trust Boundary Read Bounded Access Local Filesystem Workspace Files (Read/Write/Scan) Policy Store .code-scalpel/policy.json โœ“ Cryptographic Signature Audit Logs .code-scalpel/logs/ Every operation logged Append-only External Services (Optional) OSV.dev API Vulnerability Database SIEM Integration Splunk, Datadog, etc. SSO Provider Okta, Azure AD, etc. Central Policy Repo Enterprise Policy Dist. Security Architecture Key Points Trust Boundary: All enforcement happens server-side, never in the AI model Cryptographic Verification: Policies are signed; tampering detection is fail-closed Audit Trail: Every operation logged with identity, scope, outcome, and evidence

Why this architecture matters: Security enforcement happens inside the MCP server (trust boundary), not by prompting the AI to behave. Policy violations are denied before reaching the filesystem. All decisions are cryptographically verifiable and generate audit evidence for compliance frameworks.

๐Ÿ”’ Core Governance Principles

  • Server-enforced boundaries: Limits are hard gates, not model suggestions
  • Complete audit trails: Every operation logged with who, what, when, why
  • Bounded writes: Edits target one symbol instead of whole-file rewrites
  • No execution by default: Analysis tools parse code; they don't run it

๐Ÿ›ก๏ธ Enterprise Governance

  • Cryptographic policy integrity: Signed policies with tamper detection
  • Fail-closed enforcement: Verification failure = operation denied
  • Compliance evidence: Generate artifacts for HIPAA, SOC2, GDPR, PCI-DSS
  • Organization-wide controls: Centralized policy management and reporting

๐Ÿ“‹ Audit Trail Capabilities

Every Code Scalpel operation generates a complete audit record:

  • Operation identity: Tool name, parameters, tier, timestamp
  • Actor identity: User/agent, license key, session ID
  • Scope: Files accessed, symbols modified, boundaries enforced
  • Outcome: Success/failure, validation results, policy decisions
  • Evidence: Before/after snapshots, compliance mappings, CWE references

โš–๏ธ Compliance Evidence Generation

Enterprise tier generates audit-ready artifacts your compliance team will accept:

Framework Evidence Type Controls Mapped
SOC2 Change logs, access controls, integrity verification CC6, CC7, CC8
HIPAA PHI access logs, modification trails, policy enforcement ยง164.312
GDPR Data flow tracking, processing logs, consent verification Art. 30, 32
PCI-DSS Change management, access logs, vulnerability scans Req. 6, 10, 11

๐Ÿ” Cryptographic Policy Verification

Enterprise policies are cryptographically signed. The verify_policy_integrity tool detects tampering before any governed operation executes:

  • Signature verification: Policy files signed with Ed25519
  • Tamper detection: Any modification invalidates the signature
  • Fail-closed: Invalid signature = operation denied (no exceptions)
  • Audit trail: Every verification attempt logged

๐Ÿ” Security Scanning: What We Detect (and Don't)

Transparency is critical for security tools. Here's exactly what our scanning capabilities cover:

โœ“ What We Detect

  • Injection vulnerabilities: SQL injection, XSS, command injection via taint analysis
  • Secrets & crypto: Hardcoded credentials, API keys, weak encryption algorithms
  • Dangerous operations: Insecure deserialization, path traversal, unsafe eval/exec
  • CWE mapping: All findings mapped to Common Weakness Enumeration with severity levels
  • Cross-file taint tracking: Data flow analysis across module boundaries (Pro/Enterprise)

โœ— What We Don't Detect

  • Template injection: SSTI patterns inside Jinja2/Mustache string literals are opaque to the parser
  • Framework middleware: Global sanitization (Express/Flask middleware) is invisible unless explicitly registered
  • Simple obfuscation: String splitting like "ex" + "ec" instead of "exec" evades detection
  • Runtime-only issues: Vulnerabilities in C-extensions or compiled dependencies
  • Dead code: Vulnerabilities in never-called functions are flagged (useful for audits, but can create noise)

๐Ÿ”’ Fail-Closed Behavior

Dependency scanning (scan_dependencies): Returns success=False on API timeouts or network errors. We never report "no vulnerabilities found" when the security check couldn't complete.

Need to register custom sanitizers? See our configuration docs for SANITIZER_PATTERNS setup.

๐Ÿ’ก The Thesis: You Can't Govern Operators with Suggestions

Traditional security advice (prompt the model to be careful, review outputs, test after deployment) doesn't scale when agents operate autonomously. You need structural controls โ€” limits enforced by the server, not requested from the model.

๐Ÿ“ฆ Need a Security Review Packet?

We provide detailed documentation for SOC2, HIPAA, and PCI questionnaires. Contact sales to schedule a security review or request our compliance evidence package.