Authorization Role Coverage Gap Prompt

This prompt is built for security testers and AppSec engineers who need to prove that their test suites cover every role-permission combination defined in a formal RBAC matrix. The core job-to-be-done is audit readiness: before a security review, as part of a release gate, or when onboarding new roles, you feed the prompt a validated matrix and an inventory of existing test cases. It then produces a coverage matrix that highlights untested paths, missing negative tests, and potential privilege escalation vectors. The ideal user already has a machine-readable or clearly structured RBAC definition and a test case list that includes test IDs, descriptions, and the roles exercised. Without those two inputs, the prompt cannot produce reliable output.

Do not use this prompt if your RBAC matrix is incomplete, inferred, or unvalidated. The output is only as reliable as the inputs: if the matrix omits a role or permission, the coverage report will silently miss that gap. Similarly, if your test inventory is stale or only covers happy-path scenarios, the prompt will report false confidence. This prompt is also not a substitute for dynamic authorization testing or penetration testing—it analyzes coverage of existing tests, it does not generate new attack payloads. For high-risk regulated environments, always pair the output with a human review step that confirms the RBAC matrix is current and that the test inventory accurately reflects what is actually executed in CI/CD.

After running the prompt, treat the resulting coverage matrix as a working document for your next test planning cycle. Prioritize filling gaps where the matrix shows zero test coverage for a role-permission pair, especially for write, delete, or admin-level operations. Then move on to missing negative tests—cases where a role should be denied access but no test confirms the denial. Finally, review the privilege escalation vectors the prompt surfaces; these often reveal paths where lower-privilege roles can reach higher-privilege endpoints through indirect means. If the prompt flags a gap you cannot explain, escalate it to the application's architecture owner before closing the finding.

This prompt template is designed to be pasted directly into your AI harness. It expects a structured RBAC matrix and a list of existing test cases as inputs. The model's job is to produce a coverage matrix that flags every role-permission combination that lacks a corresponding test, along with the associated privilege escalation risk. Replace every square-bracket placeholder with your own data before sending the prompt to the model.

codeCopy
You are an AppSec test architect. Your task is to analyze the provided role-based access control (RBAC) matrix and the existing test case inventory to identify authorization coverage gaps.

[INPUT]
### RBAC Matrix
[ROLE_PERMISSION_MATRIX]

### Existing Test Cases
[EXISTING_TEST_CASES]

[CONSTRAINTS]
- Map every role-permission pair from the matrix to zero or more test cases.
- Flag any role-permission pair that has zero associated test cases as a 'Coverage Gap'.
- For each gap, assess the privilege escalation risk as 'Critical', 'High', 'Medium', or 'Low' based on the sensitivity of the permission.
- Do not invent test cases. Only reference test cases provided in the input.
- If a test case ID is provided, use it exactly. If only descriptions are provided, reference them by a short, generated slug.

[OUTPUT_SCHEMA]
Return a single JSON object with the following structure:
{
  "coverage_matrix": [
    {
      "role": "string",
      "permission": "string",
      "mapped_test_case_ids": ["string"],
      "coverage_status": "Covered" | "Coverage Gap",
      "risk_level": "Critical" | "High" | "Medium" | "Low" | null
    }
  ],
  "summary": {
    "total_role_permission_pairs": number,
    "covered_pairs": number,
    "gap_pairs": number,
    "critical_gaps": number,
    "high_gaps": number
  }
}

[EXAMPLES]
Input RBAC Matrix row: Admin | delete:user
Input Test Cases: [{"id": "TC-101", "description": "Verify Admin can delete a user account"}]
Output row: { "role": "Admin", "permission": "delete:user", "mapped_test_case_ids": ["TC-101"], "coverage_status": "Covered", "risk_level": null }

Input RBAC Matrix row: Viewer | export:financial_data
Input Test Cases: []
Output row: { "role": "Viewer", "permission": "export:financial_data", "mapped_test_case_ids": [], "coverage_status": "Coverage Gap", "risk_level": "Critical" }

[RISK_LEVEL]
This workflow involves security authorization analysis. The output is a gap report, not an authorization decision. A human AppSec reviewer must validate the completeness of the input RBAC matrix and the final gap assessment before any remediation is planned.

To adapt this prompt, replace [ROLE_PERMISSION_MATRIX] with your structured role-to-permission mapping (e.g., a CSV converted to JSON or a markdown table). Replace [EXISTING_TEST_CASES] with a JSON array of your test case objects, each containing at least an id and a description. If your test management tool uses different field names, update the [OUTPUT_SCHEMA] and the [EXAMPLES] to match your data model. The [CONSTRAINTS] section is critical for preventing hallucinated test cases; keep the instruction to only reference provided IDs. For high-risk environments, consider adding a [TOOLS] section that allows the model to call a test management API to validate test case IDs, though this adds complexity and requires a human-in-the-loop approval step for any write operations.

This prompt is designed to operate as a batch analysis step within a CI/CD security gate or a periodic AppSec review workflow. It expects a structured RBAC matrix (roles × permissions) and a list of existing test case identifiers with their role-permission coverage tags. The prompt should be called after the RBAC matrix and test inventory have been extracted from their source systems (e.g., IAM policy files, test management tools) and normalized into the expected input format. Do not call this prompt on raw, unparsed policy documents or unstructured test plans; pre-processing into the defined schema is required for reliable coverage analysis.

Integration pattern: Build a thin service that (1) fetches the latest RBAC definition from your identity provider or policy-as-code repository, (2) queries your test case management system for test cases tagged with authorization or role-permission metadata, (3) assembles both into the [RBAC_MATRIX] and [TEST_INVENTORY] input blocks, and (4) invokes the LLM with this prompt. On response, validate the output against the [OUTPUT_SCHEMA] using a JSON Schema validator. Any record that fails validation should trigger a single retry with the original prompt plus the validation error message appended as a [CORRECTION_HINT]. If the retry also fails, escalate to a human reviewer via your ticketing system rather than silently dropping the gap.

Model selection and latency: This is a structured reasoning task with a large input context (the full RBAC matrix). Use a model with strong JSON mode and long-context handling, such as gpt-4o or claude-3-opus. The prompt is not latency-sensitive; it runs on a schedule (e.g., weekly or per-release) rather than in a user-facing request path. Set a generous timeout (60–120 seconds) and log the full prompt and response for auditability. For high-security environments, consider running this prompt in a private deployment (e.g., Azure OpenAI Service or AWS Bedrock) to avoid sending role-permission data to a shared SaaS endpoint.

Human review and sign-off: The output gap report must not auto-close gaps. It is a detection artifact. Route the validated output to a security engineering review queue where a human confirms each identified gap, dismisses false positives, and creates tickets for confirmed missing tests. Store the final reviewed report as an audit artifact. For SOC 2 or PCI-DSS environments, this report serves as evidence of periodic authorization coverage review. Never treat the raw LLM output as a reviewed, approved artifact without human sign-off.

What to avoid: Do not feed live production session tokens or user data into this prompt. The input should contain role and permission definitions, not runtime access logs. Do not use the prompt to generate new test cases directly—it identifies gaps, but test case authoring requires separate, human-reviewed prompts with exploit-step detail. Avoid running this prompt on every commit; it is a periodic analysis tool, not a pre-commit hook. Finally, ensure the RBAC matrix input is complete before analysis; a partial matrix will produce a misleadingly small gap report.