Security Operations Prototyping and Proof-of-Concept Documentation
Why pattern-based security can’t keep pace with adaptive adversaries
Reactive defense assumes a stable threat landscape where attacks can be enumerated, patterns can be catalogued, and remediations can be prescribed. This assumption fails for MCP-based agentic systems because:
| Dimension | Reactive Model | SFAMDF Proactive Model |
|---|---|---|
| Detection Method | Pattern matching against known signatures | Behavioral anomaly detection + patterns |
| Novel Attacks | Missed until pattern added to library | Detected via baseline deviation |
| Partial Patterns | Not detected (waiting for full match) | Triggers graduated defensive posture |
| Coordinated Attacks | Each boundary defends independently | Federated correlation across organizations |
| Response Speed | As fast as pattern lookup | Continuous + adaptive |
| Human Role | Approval queue (bottleneck) | Expert judgment at decision points |
| Adaptation | Manual rule updates | Automated baseline evolution |
| Trust Model | Implicit (allow until blocked) | Explicit governance contracts |
| Execution Bounds | Code-level enforcement | System-level (AgentBox sandbox) |
| Failure Mode | Silent miss on unknown patterns | Anomaly alert on deviation |
Reactive:
IF request MATCHES pattern_library THEN block
ELSE allow
The reactive model maintains a library of known-bad patterns. If an attack doesn’t match an existing pattern, it passes through. This creates a fundamental “first victim” problem—someone must be compromised before a pattern can be added.
Proactive (SFAMDF):
IF request MATCHES pattern_library THEN block
IF behavior DEVIATES from baseline THEN investigate
IF partial_pattern DETECTED THEN elevate_posture
SFAMDF layers behavioral analysis on top of pattern matching. Even if an attack uses a novel technique, unusual behavior relative to established baselines triggers investigation. Partial pattern detection allows defensive posture to escalate before full attack materializes.
Reactive:
Organization A sees: Suspicious tool registration Organization B sees: Unusual data access pattern Neither alerts because neither meets local threshold.
Proactive (SFAMDF):
Organization A sees: Suspicious tool registration -> shares anonymized signal Organization B sees: Unusual data access -> shares anonymized signal Federated layer: Correlates signals -> identifies coordinated campaign Both organizations receive proactive alert.
+-------------------+ +-------------------+
| Organization A | | Organization B |
| +-----------+ | | +-----------+ |
| | Partial | | | | Partial | |
| | Signal P1 |----+----+----+---| Signal P2 | |
| +-----------+ | | | +-----------+ |
+-------------------+ | +-------------------+
v
+-----------------+
| Federated Layer |
| P1 + P2 = Full |
| Attack |
+--------+--------+
|
+------------+------------+
v v
+-------------+ +-------------+
| Alert to A | | Alert to B |
+-------------+ +-------------+
Reactive:
EVERY suspicious pattern -> human approval queue
This creates a bottleneck that attackers exploit. Flood the system with borderline suspicious requests, exhaust human reviewers, slip malicious requests through fatigue.
Proactive (SFAMDF):
Routine operations -> automated
Anomaly investigation (>70% confidence) -> async review
Attribution assessment (>85% confidence) -> sync approval
Active response (>90% confidence) -> expert panel
Ambiguous (<70% confidence) -> mandatory escalation
Humans are expert judgment sources, not approval queues. They engage at decision points where their expertise adds value. Routine operations proceed without delay.
| Decision Type | Reactive | SFAMDF |
|---|---|---|
| Normal request | Auto-allow | Auto-allow |
| Pattern match | Human decides | Auto-block |
| Anomaly detected | N/A (not detected) | Async review |
| Attribution needed | N/A | Sync approval |
| Active response | N/A | Expert panel |
Reactive:
Defense tools have implicit trust
Whatever the code does is what happens
No runtime enforcement of declared capabilities
Proactive (SFAMDF):
# Governance Contract (AgentManifest)
agentType: DefenseOperator
capabilities:
- monitor
- alert
denyCapabilities:
- terminate
- modify_config
escalation:
threshold: 0.85
AgentBox runtime enforces manifest at system level
Agent cannot exceed declared capabilities
Even if code attempts unauthorized action, blocked
Reactive:
New attack discovered
-> Analyst reviews
-> Pattern created
-> Pattern deployed
-> Library updated
Timeline: Hours to days. Every organization independently.
Proactive (SFAMDF):
Successful defense
-> Baseline updated automatically
-> Detection sensitivity adjusted
-> Federated signal shared (anonymized)
-> Other organizations benefit
Timeline: Minutes to hours. Collective improvement.
Reactive defense works when:
For many traditional applications, reactive defense is appropriate and cost-effective.
Proactive defense becomes necessary when:
MCP-based agentic systems meet all these criteria.
Organizations don’t need to go fully proactive immediately. SFAMDF supports incremental adoption:
| Maturity Level | Reactive Components | Proactive Components |
|---|---|---|
| Level 1 | Allowlists, basic patterns | None |
| Level 2 | Gateway validation, logging | Behavioral baselines |
| Level 3 | Layered controls | Anomaly detection, EITL |
| Level 4 | Full pattern library | Federated signals |
| Level 5 | Maintained | Full adaptive defense |
Start with reactive foundations, layer proactive capabilities as maturity increases.
| If you believe… | Then use… |
|---|---|
| “We can enumerate all attacks” | Reactive |
| “Adversaries will find gaps” | Proactive |
| “Attacks arrive one at a time” | Reactive |
| “Attacks coordinate across boundaries” | Proactive |
| “Humans can review everything” | Reactive |
| “Expert judgment should focus on high-value decisions” | Proactive |
SFAMDF enables proactive defense without abandoning reactive foundations. Pattern matching remains valuable—it’s just not sufficient.