88 lines
3.1 KiB
Markdown
88 lines
3.1 KiB
Markdown
# Scene 7 — DENY: Restricted Jira Project (Argument Validation)
|
|
|
|
**Policy rule:** Argument allowlist (`jira.createTicket` only allowed for projects in allowlist)
|
|
**Expected result:** DENY for restricted project
|
|
|
|
---
|
|
|
|
## 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 PE as Policy Engine
|
|
participant JR as Jira Service
|
|
|
|
AI->>GW: POST /api/gateway/execute<br/>{tool: jira.createTicket, action: create,<br/>arguments: {project: FINANCE, summary: ...}}
|
|
GW->>GW: Validate JWT + extract scopes
|
|
GW->>PE: Evaluate policy rules
|
|
PE->>PE: Scope check: jira.write ✓
|
|
PE->>PE: Argument allowlist: FINANCE<br/>not in [SAFE, PLATFORM, OPS] ✗
|
|
PE-->>GW: Decision: DENY
|
|
Note over GW,JR: Request never reaches Jira
|
|
GW->>GW: Write audit entry
|
|
GW-->>AI: 200 OK {decision: DENY,<br/>reason: "Project not in allowlist"}
|
|
```
|
|
|
|
## Demo Script
|
|
|
|
> **Presenter says:** "Even when the AI has write access to Jira, it can only create tickets in approved projects. The FINANCE project? Off limits."
|
|
|
|
### Action
|
|
|
|
Example request:
|
|
|
|
> "Create a Jira ticket in project FINANCE with summary 'AI-generated report' and type Bug"
|
|
|
|
Send a gateway request for `jira.createTicket` with `project=FINANCE`.
|
|
|
|
### Expected Response
|
|
|
|
```json
|
|
{
|
|
"request_id": "req-...",
|
|
"decision": "deny",
|
|
"reason": "Project not in allowlist",
|
|
"matched_rule": "restrict-jira-projects"
|
|
}
|
|
```
|
|
|
|
### Contrast — Allowed Project
|
|
|
|
Then ask:
|
|
|
|
> "Create a Jira ticket in project PLATFORM with summary 'Update documentation' and type Task"
|
|
|
|
This returns **ALLOW** — PLATFORM is in the allowlist `[SAFE, PLATFORM, OPS]`.
|
|
|
|
---
|
|
|
|
## What This Proves
|
|
|
|
- **Argument-level validation** — not just "can you use this tool?" but "can you use it *with these parameters*?"
|
|
- The allowlist is in the policy config (`data.allowed_projects`), not in code
|
|
- Changing which projects are allowed = editing YAML, not redeploying
|
|
- Prevents data leakage to sensitive projects (FINANCE, HR, LEGAL)
|
|
- Same pattern applies to Liquibase changelogs: only approved changelogs can run
|
|
|
|
---
|
|
|
|
## Key Message
|
|
|
|
> "The AI has `jira.write` scope — it CAN create tickets. But the policy engine adds a second layer: WHICH projects. This is fine-grained access control, defined as data, enforced at the gateway."
|
|
|
|
---
|
|
|
|
## Wrap-Up
|
|
|
|
> "We've seen 7 scenarios covering all 6 policy categories. The AI agent is a requesting client — it asks, the gateway decides. Credentials stay server-side, policies are data, and every decision is audited."
|