Agent Permission Testing Skill: Verify tool access, identity, and refusal at every boundary

Agent Permission Testing checks whether an agent has authority for a specific identity, tool, resource, tenant, action, and parameter set. A tool’s name or an instruction in retrieved content does not establish permission.

Build the principal-to-action matrix

For each candidate action, record the actual caller and delegation chain, tool, resource and tenant, action and parameter bounds, authorization source and version, expiry or revocation state, and expected allow, deny, or reapproval decision.

Decision input	Evidence to preserve
Identity and delegation	Authenticated principal, delegated-by chain, current role or grant
Resource and tenant	Exact object and ownership or tenant scope
Action and parameters	Operation, amount, recipient, and any policy-defined bounds
Authority	Source, version, expiry, revocation, and required approval
Outcome	Allow, deny, or reapprove, with audit evidence

Do not infer a grant from an agent name, tool listing, user request, or external document.

Check denial evidence with an isolated case

This is an illustrative case: the test policy explicitly denies a principal in tenant-A access to a mock resource in tenant-B. The fixture must supply the policy, principal, and resource; this example is not a rule for any real system.

Record	Evidence to retain
Case and input	`AGP-EX-01` (example ID), principal, delegation chain, target tenant, and proposed action
Authority	Policy ID and version, resource scope, and the applicable denial rule
Denial evidence	Authorization decision, tool execution trace, post-run mock state, and audit record
Control path	A test action explicitly permitted by policy, with its grant evidence, to detect false denial

A refusal in the agent’s text without an authorization decision, execution trace, or post-run state or audit evidence remains “insufficient evidence.” For a denial, also confirm that no tool executed and that there was no write, message, or cost side effect. If policy requires denial and the trace shows execution or a side effect, the case fails. If a permitted control path is denied, record a false denial against the policy. Label static review separately from runtime results.

Recheck authority when the request changes

Before a proposed action, compare the current identity, grant status, resource, and parameters with the supplied policy. Delegation cannot expand the original grant. If the resource, amount, recipient, or action changes, request approval again when policy requires it. Expired or revoked authority is no longer valid.

Distinguish permission from remembered state

Permission testing asks whether this principal may perform this action now, including the approval and side-effect boundary. Agent Memory Testing follows stored information across updates, expiry, sessions, and deletion. A memory record’s presence neither grants access nor proves that access was correctly denied.

Record an AGP-## finding

Capture the object or rule, source, trigger or applicability, expected concern, evidence state, impact and priority, owner role, close condition, and validation method. For a denial, name the evidence needed to prove no tool call and no side effect; for an allowed path, record the policy source for the grant.

Human reviewers must make risk-acceptance, exception-approval, and safety decisions. The Skill can list those decisions; it cannot make them for the team.

Keep review and execution separate

Compare supplied identity, policy, request, and audit material as a static review. Any runtime check requires separate authorization and an isolated or mocked environment. Do not access real resources, execute a tool, or report an unrun candidate as a pass.

Agent Memory Testing: https://inaodeng.com/en/qaskills/agent-memory-testing/ reviews stored state and deletion behavior.
Agent Tool Testing: https://inaodeng.com/en/qaskills/agent-tool-testing/ reviews tool behavior and invocation boundaries.
Authorization Testing: https://inaodeng.com/en/qaskills/authorization-testing/ covers broader subject/resource/action decisions.

Install and invoke

Install the English Skill with the Agent Skills CLI:

npx skills add naodeng/awesome-qa-skills --skill agent-permission-testing

Installation and troubleshooting guides:

In a tool that discovers Agent Skills automatically, describe the task directly. If the tool supports explicit invocation, use its syntax to select agent-permission-testing. Provide the identity and delegation context, policy source and version, resource and tenant, proposed action and parameters, approval state, scope, environment, and audit evidence.

For example:

Use agent-permission-testing to review this Agent permission design.
Identity and delegation chain: [fill in]
Policy source, version, and expiry: [fill in]
Tool, resource, tenant, action, and parameters: [fill in]
Approval state and audit evidence: [attach relevant material]
Scope, environment, and constraints: [fill in; do not access real resources or execute tools]
Separate facts, evidence-supported inferences, candidate validation, and Human decisions. For each finding, include priority, owner role, close condition, and validation method.

FAQ

Does an Agent’s refusal prove that the permission decision was correct? No. Check the policy decision, tool execution trace, post-run state, and audit evidence. Without them, mark the result “insufficient evidence.”
Will this Skill run permission tests? No. It organizes static review and candidate validation. Actual execution requires separate authorization and should be performed by the team in an isolated or mocked environment.
What if identity or policy materials are incomplete? List the unknowns and input gaps. Do not infer permission from an Agent name, tool listing, or external content.

Source

Read the Agent Permission Testing prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/agent-permission-testing/prompts/agent-permission-testing.md. It defines the AGP-## finding contract and evidence needed for approval, denial, and side-effect boundaries.