version: 1
metadata:
  key: api-security-testing
interface:
  display_name: "API Security Testing"
  short_description: "Evidence-bounded api-security-testing analysis and validation preparation"
  default_prompt: "Use the api-security-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": "api-security-testing",
  "max_commands": 20,
  "max_total_tokens": 100000,
  "permissions": {
    "max_escalations": 0
  }
}

# API Security Testing Prompt

## Input

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

- known: scope, API security, roles, or constraints directly supported by a source.
- missing: material needed to judge API attack surface, input boundaries, identity and authorization, error leakage, and security contracts 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 API attack surface, input boundaries, identity and authorization, error leakage, and security contracts.
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 API security as the domain anchor and AST-## 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

- API security 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. API security and Security Risk Model

Describe API attack surface, input boundaries, identity and authorization, error leakage, and security contracts scenarios, triggers, expected behavior, impact, priority, and evidence gaps.

### AST-## 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 API attack surface, input boundaries, identity and authorization, error leakage, and security contracts, 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.