Skip to content
Back to skills

Agent Action Proof

ASecurity

Grades evidence for an AI agent's downstream actions without overstating what a callback, tool trace, file read, command result, or target change proves. Use when validating impact, writing findings, or reviewing agent test receipts.

  • 53 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 16, 2026
ai-agentssecurity

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned October 16, 2026

npx -y skills add zero-lab-ai/skills --skill agent-action-proof --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Agent Action Proof?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Agent Action Proof
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/zero-lab-ai-agent-action-proof/badge)](https://www.skillsdirectory.com/skills/zero-lab-ai-agent-action-proof)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: agent-action-proof
description: "Grades evidence for an AI agent's downstream actions without overstating what a callback, tool trace, file read, command result, or target change proves. Use when validating impact, writing findings, or reviewing agent test receipts."
metadata:
  portability: universal
  discipline: engagement-operations
  domain: ai-systems
  tags: [agents, evidence, impact, provenance, reporting]
---

# Agent action proof

Determine the strongest claim supported by an agent test receipt. Keep model
output, tool invocation, target-side effect, and business impact distinct.

## When to Use

- Reviewing evidence from an authorized agent or tool-use assessment.
- Deciding whether a result proves instruction acceptance, tool use, target
  action, or demonstrated impact.
- Preparing a reproducible finding or validation handoff.

## When NOT to Use

- Do not use this skill to execute the action being evaluated.
- Do not promote screenshots, model narration, or a callback alone into proof
  of target-side execution.
- Do not preserve secrets or sensitive output in the report when a restricted
  evidence reference is sufficient.

## Evidence ladder

Use the highest rung supported by independent receipts:

1. `presented` — the instruction or data reached the model context.
2. `accepted` — the model output adopted or repeated the requested intent.
3. `tool-selected` — the agent requested a named tool with recorded arguments.
4. `tool-invoked` — the runtime dispatched the request to the tool boundary.
5. `target-observed` — target-origin evidence shows the requested read, write,
   query, or operation occurred.
6. `effect-verified` — a separately observed target state changed as expected.
7. `impact-demonstrated` — the bounded effect reached the stated security or
   business consequence.

Never collapse rungs. A DNS or HTTP callback is interaction evidence; a file
read is not command execution; command execution is not elevated execution; an
attempted write is not a durable state change.

## Workflow

1. Record the authorization reference, exact target, test identity, environment,
   time window, approved action class, disruption limit, and cleanup duty.
2. Assign a unique run identifier and carry it through model, runtime, tool,
   target, and cleanup records.
3. Preserve the original artifacts. Record origin, collector, timestamp, target
   identity, resource identity, integrity value where available, and access
   restrictions.
4. Reconstruct the chain chronologically: input, model response, agent decision,
   tool request, runtime dispatch, tool result, target observation, state check,
   and cleanup receipt.
5. Mark each link `present`, `missing`, `contradicted`, or `not-applicable`.
   Correlation by time alone is not identity proof.
6. Place the result on the evidence ladder. State the missing receipt required
   for the next rung.
7. Check alternative explanations: synthetic tool output, replayed callback,
   cached data, a different identity, pre-existing state, race conditions, or
   operator action outside the agent path.
8. Separate severity from proof. Severity may consider the demonstrated
   consequence and preconditions, but it cannot strengthen the evidence chain.
9. Confirm cleanup from target-origin state where cleanup was required. Record
   residual artifacts and failed rollback explicitly.

## Deliverable

Return the bounded claim, achieved evidence rung, receipt chain, missing and
contradictory links, alternative explanations, identity and timestamp limits,
cleanup status, and the exact additional evidence needed to strengthen the
claim.

## Rationalizations to reject

- **“The agent said it succeeded.”** Model narration is not a target receipt.
- **“The tool returned success.”** Tool output can be wrong, spoofed, cached, or
  disconnected from the intended target.
- **“The callback proves code execution.”** It proves only the observed
  interaction unless a stronger target-side receipt exists.
- **“The timestamps line up.”** Temporal correlation does not prove identity or
  causation.
- **“The impact is obvious from the primitive.”** Report the demonstrated
  effect and keep downstream consequences as bounded analysis.
- **“Cleanup probably happened when the session ended.”** Cleanup needs its own
  receipt when state could persist.

Files in this skill

  • SKILL.md4.3 KB
  • agents/openai.yaml222 B
  • assets/zero-lab-mark.svg9.4 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.