Permission Scope Conflict Detection Prompt

This prompt is an analytical tool for platform engineers and security architects who manage overlapping permission sets across multiple roles, tools, and agents. Its job is to catch conflicts, redundancies, and unintended privilege escalation paths that static analysis might miss. Use it during the design phase—before deploying new roles, merging permission policies, or refactoring tool access across a multi-agent system. The ideal user brings a structured specification of two or more permission scopes, including allowed actions, resource constraints, and any inheritance or delegation rules. This is a design-time review prompt, not a runtime enforcement mechanism; it does not block actions in production but surfaces risks that should be resolved before deployment.

The prompt expects a structured input describing the permission scopes under review. You should provide each scope as a clear declaration of allowed tools, data stores, action categories, and any explicit deny rules. The model will analyze these scopes for three categories of findings: conflicts where two scopes grant contradictory access, redundancies where overlapping permissions create unnecessary complexity, and escalation paths where combining scopes or delegating between roles could grant unintended privileges. The output includes a severity rating for each finding and a concrete resolution recommendation. Because this analysis can influence security-critical decisions, you must treat the model's output as an advisory starting point, not a final verdict. Every finding should be reviewed by a human with authority over the permission model before any policy changes are applied.

Do not use this prompt when you need runtime enforcement, real-time access control, or automated policy generation. It is not a substitute for a policy engine, an IAM system, or a code-level authorization framework. It is also not designed for analyzing permissions in systems where the model itself has no visibility into the underlying tool implementations—the analysis is only as good as the permission specifications you provide. After running the analysis, take the structured findings and feed them into your team's security review process. Pair this prompt with the Permission Scope Regression Test Prompt to validate that resolved conflicts don't reappear after subsequent policy changes.

This section provides the core prompt you will paste into your system instructions or send as a user message. The template is designed to accept one or more permission specifications—expressed as structured JSON or YAML—and return a conflict analysis with typed findings, severity ratings, and resolution recommendations. Use it as the analytical engine in a permission governance workflow, a CI/CD pre-commit check, or a security review harness before deploying agent roles to production.

textCopy
You are a permission scope conflict analyzer. Your job is to examine one or more permission specifications and identify conflicts, redundancies, unintended privilege escalation paths, and ambiguous grants.

## INPUT
You will receive one or more permission specifications. Each specification defines a role, its allowed tools, argument constraints, data scopes, and explicit denials.

[PERMISSION_SPECIFICATIONS]

## TASK
1. Parse all permission specifications and build a normalized model of granted capabilities per role.
2. Compare permissions across roles to detect:
   - **Conflicts**: Two roles grant contradictory access to the same resource or action.
   - **Redundancies**: Multiple roles grant identical access with no differentiating constraint.
   - **Escalation paths**: A role can gain access beyond its intended scope through inheritance, delegation, or transitive grants.
   - **Ambiguous grants**: Permissions that are underspecified, allowing interpretation drift at runtime.
   - **Missing denials**: Actions that should be explicitly denied but are only implicitly absent.
3. For each finding, determine:
   - **Conflict type** from the taxonomy above.
   - **Severity**: `CRITICAL` (security boundary violation), `HIGH` (likely unintended access), `MEDIUM` (maintenance risk), `LOW` (cosmetic or documentation gap).
   - **Affected roles**: Which role specifications are involved.
   - **Evidence**: Quote the specific permission statements that create the finding.
   - **Resolution recommendation**: Concrete change to one or more specifications.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "analysis_summary": {
    "total_roles_analyzed": <integer>,
    "total_findings": <integer>,
    "critical_count": <integer>,
    "high_count": <integer>,
    "medium_count": <integer>,
    "low_count": <integer>
  },
  "findings": [
    {
      "finding_id": "string, unique within this analysis",
      "conflict_type": "CONFLICT | REDUNDANCY | ESCALATION_PATH | AMBIGUOUS_GRANT | MISSING_DENIAL",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "affected_roles": ["role_name_1", "role_name_2"],
      "evidence": [
        {
          "role": "role_name",
          "permission_statement": "exact quote from the specification",
          "location": "section or line reference if available"
        }
      ],
      "description": "Human-readable explanation of the finding.",
      "escalation_path": "If conflict_type is ESCALATION_PATH, describe the chain of grants that enables privilege escalation. Otherwise null.",
      "resolution_recommendation": "Specific, actionable change to resolve the finding."
    }
  ],
  "unanalyzed_specifications": [
    {
      "role": "role_name",
      "reason": "Why this specification could not be analyzed (malformed, missing fields, etc.)"
    }
  ]
}

## CONSTRAINTS
- Do not invent permissions not present in the input specifications.
- If a specification is malformed or missing required fields, include it in `unanalyzed_specifications` rather than guessing.
- Treat explicit denials as overriding grants. A grant that contradicts an explicit denial is a CONFLICT.
- If two roles have identical permission sets, flag as REDUNDANCY with severity MEDIUM.
- If a role inherits permissions from another role and the inherited set exceeds the inheriting role's documented scope, flag as ESCALATION_PATH with severity CRITICAL or HIGH.
- Do not flag intentional overlap (e.g., two roles both needing read access to a shared resource) unless the overlap creates ambiguity about which role should perform write operations.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with concrete content. [PERMISSION_SPECIFICATIONS] should contain the full permission manifests you want analyzed, ideally in a structured format like JSON with fields for role, allowed_tools, argument_constraints, data_scopes, and explicit_denials. [EXAMPLES] is optional but strongly recommended: provide 2-3 annotated examples showing correct conflict detection to anchor the model's judgment. [RISK_LEVEL] should be set to HIGH if the analysis feeds automated enforcement (e.g., blocking a deployment) or MEDIUM if it feeds a human review queue. For high-risk use, always route CRITICAL and HIGH findings to a human security reviewer before taking automated action. Validate the output JSON against the schema before ingesting it into downstream systems—malformed JSON is the most common production failure mode for structured-output prompts.

This prompt is designed for a design-time analysis workflow, not a runtime agent loop. It should be integrated into a CI/CD pipeline that gates permission specification changes or into a periodic security review dashboard that scans deployed role definitions. The harness must treat the prompt as a deterministic analysis step: given a set of permission specifications, it produces a structured conflict report. The calling application is responsible for providing well-formed input, validating the output schema, and routing findings to the appropriate review queue. Do not deploy this prompt in a user-facing chat interface or as part of an agent's runtime decision-making—it is an offline analysis tool.

Wire the prompt into a pipeline stage that triggers on changes to permission files (e.g., JSON, YAML, or structured policy documents). The application layer should: (1) collect all active and proposed permission specs from the relevant source of truth; (2) assemble them into the [PERMISSION_SPECS] input block using a consistent format (role name, allowed tools, argument constraints, data scopes); (3) inject the [OUTPUT_SCHEMA] that defines the expected conflict report structure; (4) call the model with a low temperature setting (0.0–0.2) to maximize deterministic output; and (5) validate the response against the schema before passing it downstream. If validation fails, retry once with the error message appended to the prompt as a correction hint. After a second failure, escalate to a human reviewer and log the raw response for debugging.

The output of this prompt should feed into a review and approval workflow. Parse the conflict report and route findings by severity: CRITICAL conflicts (privilege escalation paths, cross-role data leakage) should block the pipeline and require immediate security review; WARNING conflicts (redundancies, overly broad scopes) should create a non-blocking ticket for the owning team; INFO findings (minor overlaps, documentation gaps) can be logged for audit. Store each report with a hash of the input permission specs so you can detect whether a conflict is new or pre-existing. For regulated environments, retain these reports as audit evidence that permission boundaries were reviewed before deployment. Avoid the temptation to auto-resolve conflicts—this prompt identifies issues, but resolution decisions require human judgment about acceptable risk and business intent.