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

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

{
  "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."

3.1 KiB Raw Blame History