SOC 2 Type II — Vectimus Mapping

Your SOC 2 auditor will eventually ask: “What controls do you have on AI agent tool access?” Vectimus gives you a concrete answer and the audit trail to back it up.

This document maps Vectimus capabilities to specific SOC 2 Trust Service Criteria. It is honest about scope. Vectimus is the enforcement and audit layer for AI agent actions. It is not a complete SOC 2 programme and does not replace organisational controls like user provisioning, access reviews or incident response procedures.

CC6.1 — Logical access controls

Coverage: HIGH

Vectimus enforces logical access controls on every action an AI agent attempts:

• Credential protection: Blocks agent reads of .env files, SSH keys, AWS credentials, npmrc tokens and files in secrets directories (rules 011-014)
• MCP server allowlisting: Default-deny for all MCP servers. Agents cannot call any MCP tool until the server is explicitly approved (rule 030)
• MCP input inspection: Blocks MCP tool calls whose inputs reference credential paths, private keys or governance configuration (rules 032-036)
• Privilege escalation blocking: Blocks sudo, su, cloud CLI role assumption and cross-user file access (OWASP rules 007-009)
• Agent weaponisation prevention: Blocks agents from spawning other AI tools with —dangerously-skip-permissions, —yolo, —trust-all-tools and other safety bypass flags (rules 047-050). These rules only fire when an agent launches a sub-agent as a shell subprocess, not when a human runs these tools directly.
• Governance self-modification: Blocks agents from running vectimus CLI commands or writing to governance config files (rules 020b, 021, 036, 052)
• Database protection: Blocks destructive ORM commands that bypass safety confirmations (rules 040-046)

Audit evidence: Every evaluation is logged to JSONL with the action attempted, the policy that matched, the decision (allow/deny) and a timestamp.

CC6.6 — System boundary protection

Coverage: PARTIAL

Vectimus detects data exfiltration patterns that cross system boundaries:

• Base64-encoded data piped to curl or wget (OWASP rule 001)
• DNS exfiltration via nslookup or dig with encoded subdomains (OWASP rule 002)
• Credential file contents piped to network transfer tools (OWASP rule 003)

Limitation: Vectimus inspects the tool call, not network traffic. It cannot detect exfiltration through approved MCP servers or through channels that do not use recognisable command patterns.

CC6.8 — Controls against malicious software

Coverage: HIGH

• Supply chain attacks: Blocks npm publish, pip installs from non-standard indexes, npm installs from URLs, cargo installs from git (rules 015-016c, OWASP rules 010-012)
• Remote code execution: Blocks curl|sh, reverse shells, download-execute chains, eval/exec patterns (rules 006, OWASP rules 014-017)
• Script execution from temp directories: Blocks execution of agent-written scripts in /tmp (OWASP rule 005)

CC7.2 — Monitor system components for anomalous behaviour

Coverage: PARTIAL (HIGH in server mode)

• Local mode: Every action evaluated and logged. Audit trail captures all allow and deny decisions with full context.
• Server mode: Session-level tracking detects anomalous patterns:
  • Agent spawn floods (50+ spawns per session)
  • Inter-agent message floods (50+ messages per session)
  • Action rate spikes across sessions
• Multi-agent controls: Blocks broadcast amplification, excessive turn counts, background agents with bypass permissions (OWASP rules 022-029)

CC7.3 — Evaluate security events

Coverage: PARTIAL

Each deny decision in the audit log includes:

• The matched policy ID and description
• The incident that motivated the rule
• A human-readable reason for the denial
• A suggested alternative action

This gives security teams context for evaluating whether a denied action was a legitimate developer need or a genuine threat.

Limitation: Vectimus does not correlate events across sessions or generate alerts. Security teams review audit logs manually or export them to a SIEM (enterprise tier).

CC8.1 — Change management

Coverage: PARTIAL

Vectimus protects against unauthorised changes to critical configuration:

• CI/CD pipelines: Blocks writes to GitHub Actions workflows, GitLab CI, Jenkinsfiles and CircleCI configs (rules 019, 034)
• Container configuration: Blocks writes to production Dockerfiles and docker-compose files (rule 020c)
• Package lockfiles: Blocks direct modification of lockfiles across npm, yarn, pnpm, pip, poetry, uv, cargo, bundler and composer (OWASP rule 010)
• Registry configuration: Blocks writes to .npmrc, .pypirc, pip.conf and cargo config (OWASP rule 011)
• Git history: Blocks force push to protected branches, git reset —hard and git clean -f (rules 017-018b)
• Repository integrity: Blocks writes to .git directory (rule 020d)

Limitation: Vectimus enforces the policy but does not implement a change approval workflow. Denied actions tell the developer to submit a pull request or request human review. The approval process itself lives outside Vectimus.

Summary

What Vectimus does not cover

SOC 2 Type II requires organisational controls that sit outside the scope of a tool-level governance layer:

• CC1 (Control environment): Board oversight, management philosophy, organisational structure. Vectimus is a tool, not a governance programme.
• CC2 (Communication): Internal and external communication of policies. Vectimus enforces policies but does not communicate them to stakeholders.
• CC3 (Risk assessment): Entity-level risk identification. Vectimus mitigates specific risks but does not perform risk assessments.
• CC5 (Control activities): Segregation of duties, user provisioning, access reviews. Vectimus controls what agents can do, not who can use agents.
• CC9 (Risk mitigation): Vendor management, insurance, business continuity.

Organisations should treat Vectimus as one control within a broader SOC 2 programme, not as a replacement for the programme itself.