Authority Spec Template (Agentic AI Product)

Purpose
Define the explicit boundaries for an AI system that can take actions (tools), retain state (memory), and interact with sensitive data. This document is written for Product, Engineering, and Security to agree on behavior that is testable and auditable.

1) System Scope
- Product surface(s): (web, mobile, API, Slack/Teams bot, browser extension)
- Primary jobs-to-be-done: (3 bullets)
- Environments touched: (customer SaaS, internal DB, third-party APIs)

2) Tool Inventory (Action Catalog)
For each tool/action, fill:
- Tool name:
- Description:
- Inputs required:
- Outputs produced:
- Data sensitivity: (public / internal / confidential / regulated)
- Side effects: (none / writes data / sends message / deletes / changes permissions)

3) Authority Levels (Default: Deny)
Define allowed behavior per tool:
- Deny: tool is never callable by the AI
- Ask: tool requires explicit user approval every time
- Allow with constraints: callable only under specific rules

For each tool, specify:
- Authority level: Deny / Ask / Allow with constraints
- Constraints (if any): e.g., allowed domains, max records, rate limits, read-only modes
- Required UI confirmation copy (one sentence)
- Escalation path: what happens if tool fails or constraints aren’t met

4) Memory Policy
- Memory types supported: Session / User / Workspace
- What can be stored (allowed fields): (bullets)
- What must never be stored: (bullets; include secrets, credentials, payment data)
- Retention defaults: (session end / time window / admin-defined)
- User controls: view/edit/delete; where in UI; how fast deletion propagates

5) Logging & Audit
For each run/tool call, define minimum log fields:
- run_id, user_id, workspace_id, timestamp
- model identifier (provider + version)
- tool call list (tool name + args hash/reference)
- approvals (who approved + when)
- policy decisions (rule id + action)
- output references (where stored)

Access rules:
- Who can view logs: (end user / admin / support)
- Redaction rules for logs:

6) Policy & Refusal Rules
- Categories of requests that must be refused:
- Required refusal UX: (tone, explanation level, next step)
- Safe alternatives: (what the product should offer instead)

7) Evaluation Plan (Regression)
Define a small, repeatable suite:
- Golden tasks (10–30): representative workflows
- Adversarial tasks: prompt injection attempts, data exfiltration attempts
- Pass/fail criteria per task: tool correctness, boundary adherence, safe handling
- When tests run: on prompt changes, model changes, tool/schema changes

8) Incident Triggers
List conditions that create an incident ticket:
- Unauthorized action attempted or executed
- Sensitive data exposure suspected
- Repeated tool failures impacting users
- Memory storing disallowed data

Owner Sign-off
- Product owner:
- Engineering owner:
- Security/Compliance owner:
- Date: