96 lines
3.3 KiB
Markdown
96 lines
3.3 KiB
Markdown
# 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
|
|
|
|
```mermaid
|
|
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
|
|
|
|
```json
|
|
{
|
|
"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?"
|