Role-Based Access Control Model Documentation Prompt

This prompt is designed for IAM architects, security engineers, and platform teams who need to produce authoritative RBAC documentation from a formal or semi-formal permission model specification. Use it when you have a defined set of roles, resources, and actions and need to generate documentation that covers role definitions, inheritance hierarchies, policy evaluation logic, deny-by-default semantics, and separation-of-duties constraints. The prompt assumes you can provide a structured input describing the permission model. It is not a replacement for the initial security design work; it transforms a completed model into documentation that downstream consumers (developers, auditors, compliance teams) can rely on.

The ideal input is a structured specification containing role names, parent-child inheritance relationships, resource types, allowed actions per role, explicit deny rules, and any separation-of-duties constraints. This can come from a policy-as-code file, an IAM system export, or a manually authored design document. The prompt works best when the model is complete and internally consistent—it will expose gaps and ambiguities during documentation generation, but it should not be used to invent roles or permissions that were never designed. For incomplete models, run a design review first, then feed the resolved specification into this prompt.

Do not use this prompt when the permission model is still under active debate, when you lack a clear resource taxonomy, or when the goal is to generate a security policy from scratch. The prompt documents what exists; it does not perform threat modeling or recommend least-privilege policies. For high-compliance environments (SOC 2, HIPAA, FedRAMP), always route the generated documentation through human review and an evidence-grounding step that links each documented permission to a specific policy requirement or control. The output is a documentation artifact, not an audit-ready compliance submission without additional review.

This prompt template is designed to ingest your organization's specific permission model data—such as role definitions, inheritance rules, and policy constraints—and produce a complete, structured RBAC documentation artifact. It is built for IAM architects and security engineers who need to move from a spreadsheet or internal spec to a clear, unambiguous reference for developers and auditors. The prompt enforces deny-by-default semantics, requires explicit separation-of-duties checks, and flags potential role explosion before the documentation is finalized.

codeCopy
You are an IAM documentation specialist. Your task is to generate a complete Role-Based Access Control (RBAC) model reference document from the provided permission model data. The output must be unambiguous, technically precise, and suitable for use by developers implementing authorization checks and by auditors reviewing access controls.

## Input Data
[ROLE_DEFINITIONS]
[PERMISSION_INVENTORY]
[ROLE_HIERARCHY]
[CONSTRAINT_POLICIES]

## Output Schema
Generate a document with the following sections, using the exact structure specified:

### 1. Role Catalog
For each role in [ROLE_DEFINITIONS], produce a row with these fields:
- **Role Name:** The canonical name.
- **Description:** A one-sentence summary of the role's purpose.
- **Inherits From:** List of parent roles from [ROLE_HIERARCHY]. Use "None" if it is a root role.
- **Assigned Permissions:** A list of permission keys from [PERMISSION_INVENTORY] directly assigned to this role (do not include inherited permissions here).
- **Effective Permissions:** The complete, resolved set of permission keys after inheritance is applied.

### 2. Permission Inventory
For each permission in [PERMISSION_INVENTORY], produce a row with:
- **Permission Key:** The canonical string identifier.
- **Resource:** The target resource or endpoint.
- **Action:** The allowed action (e.g., read, write, delete).
- **Description:** A human-readable explanation.

### 3. Inheritance Hierarchy
Describe the role inheritance structure from [ROLE_HIERARCHY] in plain text. For each parent role, list its direct children. Explicitly state that inheritance is additive: child roles receive all permissions of their parent roles.

### 4. Policy Evaluation Logic
Describe the exact evaluation algorithm:
1. Start with an empty permission set.
2. Add all permissions directly assigned to the user's assigned role.
3. Traverse the inheritance chain upward, adding all permissions from each parent role.
4. Apply any deny rules from [CONSTRAINT_POLICIES]. Deny rules always take precedence (deny-by-default).
5. The final permission set is the result.

### 5. Constraints and Separation of Duties
For each constraint in [CONSTRAINT_POLICIES], document:
- **Constraint Name:**
- **Type:** (e.g., Static Separation of Duty, Dynamic Separation of Duty, Deny Rule)
- **Description:** What the constraint enforces.
- **Conflicting Roles/Permissions:** The specific roles or permissions that cannot be combined.

### 6. Role Explosion Risk Analysis
Review the provided [ROLE_DEFINITIONS] and [ROLE_HIERARCHY]. If the number of distinct roles exceeds 20, or if the inheritance hierarchy is more than 3 levels deep, add a warning section here. Flag any roles that differ by only one permission and suggest consolidation.

## Constraints
- Use deny-by-default semantics: if a permission is not explicitly granted, it is denied.
- Do not invent permissions or roles not present in the input data.
- If [CONSTRAINT_POLICIES] is empty, state "No explicit separation-of-duty constraints are defined" in Section 5.
- Use the exact field names and structure specified in the Output Schema.
- Format the output as clean Markdown with tables for the Role Catalog and Permission Inventory.

To adapt this template, replace the four square-bracket placeholders with your structured data. [ROLE_DEFINITIONS] should be a list of roles with descriptions and direct permission assignments. [PERMISSION_INVENTORY] is your canonical list of permission keys with resource and action metadata. [ROLE_HIERARCHY] defines parent-child relationships. [CONSTRAINT_POLICIES] captures any separation-of-duties or deny rules. If you are pulling this data from a policy-as-code repository or an IAM system, pre-process it into a consistent text or JSON format before inserting it into the prompt. For high-risk production systems, always route the generated document through a human IAM architect for review before publication.

This prompt is designed to be called programmatically as part of a documentation pipeline or IAM policy review workflow. The primary integration point is an API endpoint or background job that accepts a structured [INPUT] payload containing role definitions, resource types, and policy rules. The application layer should validate the input schema before calling the model—rejecting missing required fields like roles, resources, or evaluation_rules—to prevent the model from hallucinating placeholder values. Because the output is a complete documentation artifact with deny-by-default semantics, the harness must treat this as a high-stakes generation task: the generated documentation will be read by security auditors and engineers implementing access controls, so factual accuracy to the input is non-negotiable.

Wire the prompt into a two-stage pipeline. Stage 1 (Generation): Send the prompt with the validated [INPUT] to a capable model (Claude 3.5 Sonnet or GPT-4o are appropriate for structured technical documentation). Set temperature=0.2 to balance consistency with the slight variability needed for natural language explanations. Enable structured output mode if available, binding the response to a JSON schema that matches [OUTPUT_SCHEMA] with required fields: role_definitions, inheritance_hierarchy, policy_evaluation_logic, deny_by_default_rules, and separation_of_duties_checks. Stage 2 (Validation): After generation, run automated checks: (a) verify every role name in the output exists in the input; (b) confirm the inheritance hierarchy contains no cycles; (c) check that every resource type has at least one associated permission; (d) flag any role with more than 20 permissions as a potential role explosion risk; (e) confirm separation-of-duties constraints are explicitly documented for mutually exclusive role pairs. If validation fails, retry once with the validation errors appended as [CONSTRAINTS] feedback. If the retry also fails, route to a human reviewer with the original input, failed output, and specific violation details.

For production deployment, log every generation with the input hash, model version, output hash, validation results, and reviewer decision. This audit trail is essential for governance reviews and debugging permission model drift. Never cache or reuse documentation outputs when the input role definitions change—always regenerate. If integrating with a CI/CD pipeline for infrastructure-as-code, trigger this prompt when IAM policy files change in the repository, and block the merge if validation fails. The prompt itself should not be modified to add organization-specific role naming conventions; instead, inject those conventions through the [CONSTRAINTS] placeholder to keep the template reusable across teams.