AI Agent Security Attack Lab

Controlled security testing and evidence-driven assessment platform for AI agents and MCP servers.

AI Agent Security Attack Lab is a local-first security platform for discovering, testing, validating, and reporting security behavior in MCP servers and tool-using AI agent workflows.

It connects MCP discovery, capability analysis, controlled attack execution, evidence collection, security findings, risk analysis, attack-path correlation, policy decisions, remediation, and professional security reporting into one security workflow.

---

Product

AI Agent
   │
   ▼
MCP Server / Tools
   │
   ▼
┌──────────────────────────────────────────┐
│       AI AGENT SECURITY ATTACK LAB       │
├──────────────────────────────────────────┤
│ Discovery & Capability Inventory         │
│ Safety Attestation                       │
│ Controlled Attack Scenarios              │
│ Agent Action Gate                        │
│ Execution Trace                          │
│ Evidence & Result Validation             │
│ Findings & Risk                          │
│ Attack Graph & Correlation               │
│ Policy & Security Decisions               │
│ Remediation & Reporting                  │
└──────────────────────────────────────────┘

Core Security Model

MCP SERVER
    │
    ▼
DISCOVERY
    │
    ▼
CAPABILITY INVENTORY
    │
    ▼
SAFETY ATTESTATION
    │
    ▼
SCENARIO PRECONDITIONS
    │
    ▼
CONTROLLED AGENT
    │
    ▼
ACTION GATE
    │
    ▼
CONTROLLED TOOL EXECUTION
    │
    ▼
OBSERVATION + EXECUTION TRACE
    │
    ▼
RESULT VALIDATION
    │
    ▼
SECURITY FINDING
    │
    ├──────────────► RISK
    │
    ├──────────────► ATTACK GRAPH
    │
    ├──────────────► POLICY
    │
    └──────────────► REMEDIATION
                          │
                          ▼
                  SECURITY REPORT

The platform is designed to distinguish between a security signal, a controlled execution, and a validated security result.

---

Why AI Agent Security Attack Lab?

Modern AI agents increasingly interact with tools, APIs, filesystems, networks, and external services.

That creates a security testing problem:

It is not enough to inspect what an agent or MCP server can theoretically do. Security teams need controlled evidence of what actually happens when security-relevant behavior is exercised.

AI Agent Security Attack Lab is designed around that principle:

THEORY
  │
  ▼
PRECONDITION
  │
  ▼
CONTROLLED TEST
  │
  ▼
OBSERVATION
  │
  ▼
EVIDENCE
  │
  ▼
VALIDATED RESULT

No attack should be treated as proven solely because static metadata suggests that it might be possible.

---

Security Capabilities

MCP Security Assessment

• MCP server discovery
• Tool and capability discovery
• Static security inventory
• Runtime discovery
• Streamable HTTP analysis
• Authentication probing
• Network and endpoint analysis
• Security rule evaluation
• Evidence collection
• Finding generation
• Risk scoring
• Confidence assessment
• Security policy decisions
• Attack-path correlation
• Remediation guidance

AI Agent Security Testing

The controlled agent layer provides:

• Explicit action requests
• Tool approval through an action gate
• Approved MCP tool inventory
• Controlled tool execution
• Observation capture
• Execution trace preservation
• Timeout handling
• Failure handling
• Blocked-action evidence
• Reproducible security testing

---

Controlled Attack Lab

The Attack Lab validates security behavior through explicitly defined scenarios.

V1 Attack Scenarios

ID	Scenario	Security Focus
TP-001	Tool Poisoning	Malicious or unsafe instructions exposed through tool metadata
PI-001	Prompt Injection	Controlled prompt injection through tool output
PA-001	Permission Abuse	Controlled excessive-permission behavior
SD-001	Sensitive Data Exposure	Controlled sensitive-data exposure
EX-001	Controlled Exfiltration	Controlled exfiltration behavior
CE-001	Command Execution	Controlled command-execution behavior
FS-001	Filesystem Abuse	Controlled filesystem/path-abuse behavior
SSRF-001	SSRF / Network Abuse	Controlled network request behavior
CT-001	Cross-Tool Chaining	Security-relevant cross-tool chaining
MS-001	Multi-Step Attack	Multi-step attack behavior

---

Attack Execution Lifecycle

Every controlled scenario follows the same evidence-first lifecycle:

┌─────────────────────┐
│ Attack Scenario     │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Preconditions       │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Safety Validation   │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Controlled Agent    │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Action Gate         │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ MCP Tool Execution  │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Observation         │
│ + Execution Trace   │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Evidence Validation │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Security Result     │
└─────────────────────┘

---

Safety Architecture

Security testing is designed to fail closed.

The controlled execution layer uses explicit safety boundaries:

• Docker-based isolated execution
• Non-root execution
• Restricted network access
• Synthetic attack data
• Approved MCP tool inventory
• Capability-aware orchestration
• Scenario-specific preconditions
• Controlled execution channels
• Bounded execution time
• Bounded output
• Process/resource restrictions
• Cleanup verification
• Execution traces
• Result validation

Dangerous Capability Principle

Tool metadata does not automatically grant dangerous capabilities.

Capabilities such as:

PROCESS
FILESYSTEM
NETWORK

must be exercised through controlled execution paths and validated with scenario-specific evidence.

The engine does not infer dangerous runtime capability merely because a tool description contains words such as shell, file, network, or exec.

If a required safety boundary cannot be established:

DO NOT EXECUTE

The engine records the appropriate blocked or unavailable result.

---

Result Model

Every attack scenario produces one of the following states:

PROVEN
BLOCKED
PARTIAL
FAILED
NOT_APPLICABLE
ERROR

Meaning

Result	Meaning
PROVEN	The defined scenario produced validated evidence
BLOCKED	Execution was stopped by a security or safety control
PARTIAL	Part of the expected behavior was observed
FAILED	Execution did not complete as expected
NOT_APPLICABLE	Required capability or scenario condition was unavailable
ERROR	Scenario/framework execution encountered an error

The engine does not:

• Convert theoretical conditions into proof
• Fabricate evidence
• Claim impact that was not observed
• Execute when safety boundaries cannot be established

---

Evidence Model

Security evidence is preserved across the assessment pipeline.

SCENARIO
   │
   ▼
PRECONDITIONS
   │
   ▼
ACTION REQUESTED
   │
   ▼
ACTION ALLOWED / BLOCKED
   │
   ▼
ACTION EXECUTED
   │
   ▼
ACTION OBSERVED
   │
   ▼
EVIDENCE
   │
   ▼
VALIDATED FINDING

This makes security results traceable from the final report back to the controlled action that produced them.

---

Finding → Risk → Decision

Validated findings are integrated into the existing security intelligence pipeline.

                 SECURITY FINDING
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
       Severity     Confidence    Evidence
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                   RISK ENGINE
                        │
                        ▼
                 ATTACK GRAPH
                        │
                        ▼
                  POLICY ENGINE
                        │
             ┌──────────┼──────────┐
             ▼          ▼          ▼
           ALLOW      REVIEW      BLOCK
                        │
                        ▼
                   REMEDIATION
                        │
                        ▼
                     REPORT

---

Risk Assessment

Risk scoring incorporates security intelligence such as:

• Finding severity
• Confidenc

… README truncated here; the full file ships with the clone.