Context

Implement the Security Operations (SecOps) meta-agent as defined in spec 12.3. This is a special agent that acts as a gatekeeper for all agent actions, validating them against safety rules and company policies before execution.

SecOps responsibilities:

• Evaluate action safety before execution
• Check for data leaks, credential exposure, and destructive operations
• Validate actions against company policies
• Maintain a comprehensive audit log
• Escalate uncertain cases to the human approval queue
• Cannot be overridden by other agents (only humans can override)

Acceptance Criteria

• SecOps implemented as a special agent role (distinct from regular agents)
• Action validation pipeline — all agent actions pass through SecOps before execution
• Rule-based risk assessment checks (data leak detection, credential exposure, destructive ops)
• Company policy validation (configurable policy rules)
• Comprehensive audit log with full action details (who, what, when, result, risk level)
• Escalation to human approval queue for uncertain/high-risk actions
• Override protection — other agents cannot bypass or disable SecOps
• Configurable security policies (YAML-based)
• Risk classification (low, medium, high, critical)
• Unit tests for validation pipeline, risk checks, and escalation logic

Dependencies

• Implement parallel agent execution with async coordination #22 — Agent execution framework
• Set up type checking with mypy or pyright and strict config #25 — Tool execution system

Design Spec Reference

• Spec 12.3 — Security Operations agent

Design Decisions Finalized

• D1 — Action Type Taxonomy: Enum core + validated registry, two-level category:action hierarchy (~25 leaf types across 9 categories), static tool metadata classification. Each BaseTool declares its action_type.
• D4 — SecOps Approach: Hybrid — rule engine fast path (sub-ms, ~95% of cases) + LLM slow path for uncertain cases (~5%). Full autonomy mode: rules + audit only. Hard safety rules never bypass.
• D5 — SecOps Integration: Pluggable SecurityInterceptionStrategy protocol. Initial: before every tool invocation (slots into ToolInvoker). Policy strictness configurable per autonomy level. Post-tool scanning for sensitive data in outputs.

Common pattern: All strategies use pluggable protocol interfaces with one initial implementation. Alternative strategies are documented in DESIGN_SPEC.md for future.