version: 1
metadata:
  key: authorization-testing
interface:
  display_name: "Authorization Testing"
  short_description: "Evidence-bounded authorization-testing analysis and validation preparation"
  default_prompt: "Use the authorization-testing skill for evidence-bounded analysis."
policy:
  allow_implicit_invocation: true

schema_version: v1alpha1

environment:
  type: none

skills:
  - source: local_path
    path: .

engine:
  name: claude_code

cases:
  files:
    - evals/cases/basic-success.yaml
    - evals/cases/edge-incomplete-input.yaml
    - evals/cases/edge-scope-boundary.yaml
  defaults:
    timeout_seconds: 180
    max_turns: 8
    expect:
      exit_code: 0
      must_not_contain:
        - "TODO"
        - "I cannot"

report:
  formats: [json]

{
  "skill": "authorization-testing",
  "max_commands": 20,
  "max_total_tokens": 100000,
  "permissions": {
    "max_escalations": 0
  }
}

# Authorization Testing Prompt

## Input

Start with an input audit and record known, missing, conflicting, stale, out_of_scope, and assumptions:

- known: scope, authorization decision, roles, or constraints directly supported by a source.
- missing: material needed to judge subject-resource-action relations, permission boundaries, denial paths, and delegation that has not been supplied.
- conflicting: incompatible objectives, conditions, roles, or behaviors across sources.
- stale: architecture, version, policy, log, or scan evidence that may be out of date.
- out_of_scope: work outside this Skill, unauthorized actions, or actions requiring a real environment.
- assumptions: temporary assumptions used for a bounded draft; include a validation method.

## What to do

1. Restate the security objective, object, scope, and success criteria.
2. Model scenarios, triggers, expected concerns, and evidence needs around subject-resource-action relations, permission boundaries, denial paths, and delegation.
3. Separate static review, candidate validation, and unauthorized real-system actions.
4. Record priority, owner role, close condition, and validation method for every finding.
5. Separate facts, evidence-backed inferences, candidate recommendations, and Human decisions.

## Execution Rules

- Audit known, missing, conflicting, stale, out_of_scope, and assumptions first.
- Trace every conclusion to a source; mark unsupported evidence as pending, blocked, or a validation recommendation.
- Use authorization decision as the domain anchor and AZT-## as the finding identifier.
- Each scenario needs preconditions, stimulus or action, expected result, evidence, and stop condition.
- Do not log in, call real APIs, read credentials, or perform destructive security actions.
- Do not upgrade files, names, templates, or dry-runs into absence-of-vulnerability, exploit success, or release-approval evidence.

## Minimum Coverage Checklist

- authorization decision and applicability
- Primary risks or failure modes and triggers
- Data, permissions, impact, and priority
- Existing controls, dependencies, trust boundaries, and evidence freshness
- Expected result, evidence state, and validation method
- Close condition, residual risk, and Human decision
- facts, evidence-backed inferences, candidate recommendations, Human decisions

## Output

### 1. Scope and Task Understanding

State the objective, object, included and excluded work, success criteria, and unauthorized actions.

### 2. Input Audit

List known, missing, conflicting, stale, out_of_scope, and assumptions with source and freshness.

### 3. authorization decision and Security Risk Model

Describe subject-resource-action relations, permission boundaries, denial paths, and delegation scenarios, triggers, expected behavior, impact, priority, and evidence gaps.

### AZT-## Finding Contract

Every finding must include:

- object/rule
- source
- trigger or applicability
- expected concern/rationale
- evidence state
- impact/priority
- owner role
- close condition
- validation method

### 4. Candidate Validation and Residual Risk

Separate candidate recommendations from completed execution. State the smallest isolated validation, stop/escalation conditions, residual risks, and open questions.

### 5. Human Decisions

List only items requiring Human confirmation, risk acceptance, exception authorization, or release judgment.

The output must preserve: facts, evidence-backed inferences, candidate recommendations, Human decisions.

## Quality Bar

- The content must target subject-resource-action relations, permission boundaries, denial paths, and delegation, not a generic template with a substituted title.
- Without direct evidence, never write “tests were executed”, “all tests passed”, or “release approved”.
- Vulnerabilities, impact, thresholds, exploit success, and remediation status require sources.
- Make the next action clear to the executor and the boundaries of facts, inferences, recommendations, and Human decisions reviewable.