Permission Boundary Documentation Prompt

This prompt is for governance, compliance, and security engineering teams who need a single, version-controllable document that defines every permission boundary for an AI agent. The primary job-to-be-done is converting a raw permission specification, tool manifest, or internal policy document into a structured, auditable output that separates allowed tools, argument constraints, data scope, and explicit denial rules. The ideal user is a security engineer preparing for an audit, a compliance officer documenting agent capabilities for a regulatory review, or a platform engineer onboarding a new agent into a regulated environment where every capability must be traceable to a documented permission decision.

You should use this prompt when you have a concrete source of truth—such as an approved tool manifest, an MCP server configuration, or a written policy—and you need to produce a human-readable, machine-parseable permission boundary document. The prompt is designed to enforce a strict output schema that captures allowed actions, denied actions, argument constraints, data scope, and the governing policy reference for each permission. It is not a replacement for runtime enforcement; the output is a documentation artifact meant for review, version control, and audit evidence. You will get the most value when you pair this prompt with a validation step that checks the generated document against the source manifest for completeness and against a set of known disallowed actions to confirm they are explicitly denied.

Do not use this prompt as a substitute for actual permission enforcement in your agent runtime. The generated document describes what should be allowed, but it does not enforce those rules at the tool-call level. If you need runtime guardrails, pair this documentation prompt with a separate system prompt that implements deny-before-allow logic or with middleware that intercepts and validates tool calls. Also avoid using this prompt when the source permission specification is incomplete or contradictory; the model will faithfully document the ambiguity rather than resolve it, which can create a false sense of security. For high-risk deployments, always route the generated permission boundary document through a human reviewer who can verify that every declared permission aligns with the intended security posture before the document is committed to version control or submitted to auditors.

This prompt template produces a structured permission boundary document suitable for compliance review, security audit, and version control. It takes a raw permission specification—including allowed tools, argument constraints, data scope, and denial rules—and transforms it into a standardized, human-readable document with explicit allow/deny declarations, inheritance rules, and capability statements. The output schema is designed to be diff-friendly and machine-readable, so you can track permission changes over time and integrate the document into automated governance pipelines.

codeCopy
You are a Permission Boundary Documentation Generator. Your task is to produce a structured, auditable permission boundary document from the provided agent specification.

## INPUT
[AGENT_SPECIFICATION]

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "document_metadata": {
    "agent_id": "string",
    "agent_role": "string",
    "document_version": "string",
    "generated_at": "ISO8601 timestamp",
    "specification_source": "string"
  },
  "permission_scope": {
    "allowed_tools": [
      {
        "tool_name": "string",
        "tool_description": "string",
        "argument_constraints": {
          "allowed_parameters": ["string"],
          "forbidden_parameters": ["string"],
          "value_constraints": { "parameter_name": "constraint_description" }
        },
        "rate_limits": { "max_calls_per_session": "number or null", "cooldown_seconds": "number or null" },
        "requires_human_approval": "boolean",
        "approval_condition": "string or null"
      }
    ],
    "explicitly_denied_tools": [
      {
        "tool_name": "string",
        "denial_reason": "string",
        "denial_rule_source": "string"
      }
    ],
    "data_access_scope": {
      "readable_stores": ["string"],
      "writable_stores": ["string"],
      "tenant_isolation": "string",
      "pii_handling": "string"
    },
    "delegation_rules": {
      "can_delegate_to": ["agent_role"],
      "permissions_transferred_on_handoff": ["string"],
      "permissions_stripped_on_handoff": ["string"]
    },
    "capability_declaration": {
      "can_do": ["string"],
      "cannot_do": ["string"],
      "requires_clarification": ["string"]
    }
  },
  "deny_rules": [
    {
      "rule_id": "string",
      "rule_description": "string",
      "applies_to_tools": ["string"],
      "applies_to_actions": ["string"],
      "refusal_message": "string",
      "priority": "number"
    }
  ],
  "inheritance": {
    "parent_role": "string or null",
    "inherited_permissions": ["string"],
    "overridden_permissions": ["string"],
    "additional_restrictions": ["string"]
  },
  "compliance_notes": {
    "regulatory_classifications": ["string"],
    "audit_log_requirements": ["string"],
    "review_cadence": "string"
  }
}

## CONSTRAINTS
- Every tool in the specification must appear in either allowed_tools or explicitly_denied_tools. No tool may be omitted.
- If a tool is not listed in the specification, classify it as explicitly denied with denial_reason "Not present in source specification."
- Argument constraints must be specific: list exact allowed parameters, forbidden parameters, and value constraints per parameter.
- Deny rules must be ordered by priority (lower number = higher priority).
- The capability_declaration must be derivable solely from the permission scope. Do not infer capabilities beyond what is explicitly granted.
- If the specification includes tenant or user context, data_access_scope.tenant_isolation must describe how cross-tenant access is prevented.
- If no delegation rules exist, set can_delegate_to to an empty array and include a note that delegation is not permitted.

## INSTRUCTIONS
1. Parse [AGENT_SPECIFICATION] completely. Identify every tool, data store, action category, and constraint mentioned.
2. For each tool, extract argument constraints, rate limits, and approval requirements. If the specification is silent on a constraint, mark it as null and note the absence in a comment field.
3. Identify all explicit denial rules. If the specification uses deny-before-allow logic, preserve that ordering in the deny_rules array.
4. Derive the capability_declaration by translating the permission scope into plain-language statements. Use "Can [action] using [tool]" and "Cannot [action]" formats.
5. Validate that the output is internally consistent: no tool appears in both allowed and denied lists, no capability contradicts a deny rule, and inheritance does not create privilege escalation.
6. If [RISK_LEVEL] is "high", add a human_review_required flag to the document_metadata and include a reviewer_signoff field.

[RISK_LEVEL]: [low|medium|high]

To adapt this prompt, replace [AGENT_SPECIFICATION] with your raw permission specification—this could be a YAML manifest, a JSON tool config, a natural-language policy document, or the output of a tool discovery scan. Set [RISK_LEVEL] based on the agent's deployment context: use "high" for production agents handling sensitive data or write operations, "medium" for internal tools with limited scope, and "low" for sandboxed or read-only agents. The output JSON is designed to be committed to version control alongside your agent configuration. Run a structural validator against the output before accepting it—check that every tool in your specification appears in the output, that no tool is duplicated across allowed and denied lists, and that deny rule priorities are non-overlapping. For high-risk deployments, route the generated document through a human reviewer before it becomes the authoritative permission record.

This prompt is designed to be a deterministic documentation generator, not an interactive assistant. It should be wired into a structured workflow where the input permission specification (tools, arguments, data scopes, deny rules) is provided by a machine-readable source of truth, such as an agent configuration file, an MCP server manifest, or a role-based access control (RBAC) policy. The primary integration point is a post-deployment or pre-review step: after an agent's permissions are defined in code, this prompt generates the human-auditable compliance artifact. Avoid using this prompt in a free-form chat interface where the input spec could be hallucinated or drift from the actual deployed configuration.

The implementation harness should enforce a strict input contract. Before calling the model, validate that the [PERMISSION_SPEC] placeholder is populated with a structured object containing at minimum: allowed_tools (with per-tool argument_constraints), data_scopes, deny_rules, and a role_id. The application layer should serialize this object into the prompt's expected format. After the model returns the [OUTPUT_SCHEMA] (the structured permission boundary document), run a schema validator to confirm the JSON structure matches the expected fields: boundary_id, role_id, effective_date, allowed_actions, denied_actions, data_access_scope, delegation_rules, and compliance_notes. If validation fails, retry once with the validation error injected into the [CONSTRAINTS] field. If it fails again, escalate for human review rather than silently accepting a malformed document.

For governance and audit workflows, integrate this prompt into a version-controlled pipeline. Store the generated permission boundary document alongside the source permission spec in a repository (e.g., as a JSON artifact in Git). Use a diff check to flag any structural changes between versions for human sign-off. The compliance_notes field should be reviewed by a responsible party before the document is published to an audit system. Do not treat the model's output as authoritative without review—this prompt documents what the spec says, but a human must confirm it matches the actual deployed agent behavior. Wire the output into your existing compliance tooling (e.g., GRC platforms, internal wikis) via a simple API integration that posts the validated JSON. For high-risk deployments, add a mandatory approval step in your CI/CD pipeline that blocks the agent release until the permission boundary document is reviewed and signed off.