Scene 8 — FRAUD: SQL Injection Detection

Fraud detector: SqlInjectionDetector (severity: CRITICAL) Expected result: DENY + fraud_detected: true

Presentation Rule

Language: All AI narration and communication during scenes must be in English.

The AI must narrate every interaction with the gateway in detail. Before calling the gateway, explain what it is about to do, which endpoint it will call, what payload it will send, and what it expects to happen. After receiving the response, explain what the gateway returned, what the decision means, and why it matters. The goal is to make the audience understand exactly what is happening between the AI and the gateway at every step.

Communication Flow

sequenceDiagram
    participant AI as AI Agent
    participant GW as Gateway
    participant FD as Fraud Detection
    participant PE as Policy Engine
    participant DB as Database Service

    AI->>GW: POST /api/gateway/execute<br/>{tool: db.queryReadonly, action: query,<br/>arguments: {sql: "SELECT ... #59; DROP TABLE users#59;"}}
    GW->>GW: Validate JWT + extract scopes
    GW->>FD: Scan arguments for attack patterns
    FD->>FD: SQL injection detected:<br/>DROP TABLE (severity: CRITICAL)
    FD-->>GW: Fraud alert: sql-injection
    Note over GW,PE: Policy engine is never reached
    Note over GW,DB: Request never reaches Database
    GW->>GW: Write audit entry (fraud_detected: true)
    GW-->>AI: 200 OK {decision: DENY,<br/>fraud_detected: true, fraud_detector: sql-injection}

Demo Script

Presenter says: "Before the policy engine even runs, the gateway has a fraud detection layer. It scans every argument for attack patterns. Let's see what happens when the AI sends a query with SQL injection."

Action

Example request:

"Query the database with: SELECT * FROM users WHERE id = 1; DROP TABLE users"

Send a gateway request for db.queryReadonly with SQL containing DROP TABLE.

Expected Response

{
  "requestId": "req-...",
  "decision": "DENY",
  "fraud_detected": true,
  "fraud_detector": "sql-injection",
  "fraud_severity": "CRITICAL",
  "reason": "Potential SQL injection detected in argument"
}

What This Proves

Fraud detection runs BEFORE policy evaluation — the request never even reaches the policy engine
Pattern matching catches classic SQL injection: DROP TABLE, DELETE FROM, UNION SELECT, ; DROP, etc.
Severity is CRITICAL — this is the kind of signal that can justify alerts, lockouts, or escalation
The audit log records the fraud alert with the matched pattern for forensics

Patterns Detected

The detector catches:

DROP/ALTER/TRUNCATE TABLE/DATABASE
DELETE FROM
UNION [ALL] SELECT
INSERT INTO ... SELECT
Stacked queries (;DROP, ;DELETE, etc.)
SQL comments (--)
EXEC xp_/sp_ (SQL Server stored procs)
GRANT/REVOKE permission changes

Key Message

"Even if the policy would have allowed a db.queryReadonly, the fraud detector catches the malicious payload inside the arguments. This is defense-in-depth: policy checks what you're doing, fraud detection checks how you're doing it."

Transition to Next Scene

"SQL injection is a classic attack. But what about prompt injection — attacks that try to manipulate the AI itself?"

3.3 KiB Raw Blame History