/permission-qa

Scope and intent

A controlled workflow specification

This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.

Use when

Appropriate use

Use for role-based access control, organisation switching, shared resources, admin features, APIs, invitations, and security-sensitive workflows.

Do not use when

Non-goals

Do not use as a full penetration test, with real customer accounts, or without an isolated permission matrix and explicit security handling.

8: versioned workflow phases
4: explicit approval gates
6: defined result states
9: versioned output artifacts

Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.

Workflow

The 8 phases

Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.

Phase 1: Authorisation model preflight Gate 1 · approve permission model

Resolve roles, permissions, tenants, resource ownership, inheritance, feature flags, endpoints, UI controls, token types, and authorised expectations.

actor · tenant · resource · operation · expected decision

Phase 2: Identity and session design

Create isolated users, tenants, memberships, tokens, ownership states, and session transitions. Record how each identity is independently verified.

identity IDs · role attestation · token scope · session state

Phase 3: Permission matrix generation

Create positive and negative combinations for read, create, update, delete, share, invite, export, and administrative operations.

allow · deny · not found · inherited · cross-tenant · owner/non-owner

Phase 4: Side-effect and security approval Gate 2 · approve actions

Review invitations, emails, exports, deletions, audit events, rate limits, and any tests that could expose or modify sensitive data.

test sinks · destructive action · audit impact · data boundary

Phase 5: UI and direct API execution

Test both visible controls and direct requests. Verify role, tenant, ownership, endpoint, and operation before every assertion.

UI state · HTTP response · resource state · audit event

Phase 6: Session and transition checks

Test role changes, organisation switches, token expiry, cached permissions, revoked access, concurrent sessions, and reauthentication.

before/after role · cache invalidation · token reuse · session isolation

Phase 7: Finding assessment Gate 3 · confirm finding

Classify over-permission, under-permission, information leakage, inconsistent UI/API, stale authorisation, or requirement gap.

security impact · reproducibility · affected scope

Phase 8: Publish restricted report and cleanup Gate 4 · publish

Publish through the appropriate security or product channel, remove isolated identities and resources, and preserve redacted evidence.

restricted evidence · defect route · cleanup · audit record

Approval contract

Every gate approves an exact decision object

An approval cannot be reused after its environment, source, action plan, or approved document changes.

Approval gates and binding requirements
Gate	Decision	Required binding
1	Gate 1 · approve permission model	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.
2	Gate 2 · approve actions	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.
3	Gate 3 · confirm finding	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.
4	Gate 4 · publish	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.

Result model

Defined states prevent vague conclusions

Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.

PASS

The verified actor receives the approved decision for the tested operation and resource state.

OVER-PERMISSION

An actor can perform or observe an operation that should be denied.

UNDER-PERMISSION

An actor is incorrectly denied an approved operation.

INFORMATION LEAK

The response reveals resource existence or sensitive details beyond the actor's permission.

INCONSISTENT

UI and API, sessions, or related endpoints enforce different decisions.

REQUIREMENT GAP

The authorised permission expectation is missing or contradictory.

Evidence contract

Evidence must directly support the claim

Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.

Required evidence by claim type
Claim	Primary evidence	Required validation
Identity	Independent role and tenant attestation	The tested token and session belong to the intended actor.
UI authorisation	Screenshot and interaction trace	Visibility and enabled state match the expected capability.
API authorisation	Request and response capture	Endpoint, method, status, body, and relevant headers are recorded.
Object isolation	Resource IDs and ownership map	Cross-tenant and non-owner access are directly attempted.
State change	Before-and-after resource verification	Denied operations create no hidden side effect.
Auditability	Audit-log entry where required	Allowed and denied sensitive actions produce the expected record.

Trust and safety

Controls that must be enforced outside the prompt

These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.

Runtime control

Least-privilege data

Use synthetic tenants and resources; never enumerate real customer objects.

Runtime control

Restricted findings

Potential security issues are not published in ordinary public channels.

Runtime control

Independent identity verification

UI labels alone do not prove the active role or tenant.

Runtime control

Direct-request coverage

Hidden UI controls do not substitute for server-side enforcement.

Runtime control

No destructive ambiguity

Delete and export tests require approved ownership and sinks.

Runtime control

Token isolation

Tokens, cookies, and credentials never enter reports or model-visible evidence.

Decision policy

Ordered outcomes, not averaged pass counts

The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.

SECURITY ESCALATION

Over-permission, information leakage, or cross-tenant access requires restricted handling.

FAIL

Required permission behaviour is incorrect.

BLOCKED

Identity, expectation, or safe test data cannot be established.

PASS WITH GAP

Required checks pass but accepted optional combinations remain.

PASS

All required permission combinations enforce the approved decisions.

Known limitations

Uncertainty and coverage limits remain visible

The workflow documents what it cannot prove and what further evidence would change confidence.

Limit 1. This skill validates known authorisation rules; it is not a comprehensive offensive security assessment.
Limit 2. Identity providers and caches can introduce delayed permission changes.
Limit 3. Not-found versus forbidden behaviour may be intentionally product-specific.
Limit 4. Rate limiting and abuse controls may require isolated security environments.
Limit 5. Audit-log access can be restricted and may need specialist verification.
Limit 6. Permission models change frequently and require versioned expectations.

Outputs

Versioned records for review and continuation

Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.

permission-context.json