Tool Access Policy Extraction Prompt from Config

This prompt is designed for platform engineers and AI safety architects who need to convert a human-readable policy document, configuration file, or natural language specification into a structured, machine-enforceable tool access policy object. The primary job is extraction, normalization, and conflict resolution, not policy authoring. Use this when you have an existing policy document and need to programmatically enforce it within an agent harness, an API gateway, or a pre-execution authorization layer. This prompt assumes the input policy is well-formed but may contain ambiguities, overlapping rules, or implicit defaults that must be surfaced. It does not replace a legal review of the policy itself.

The ideal user is someone who owns the safety infrastructure for an agentic system and needs to close the gap between a written policy and runtime enforcement. You should have a clear policy artifact—such as an internal security standard, a compliance requirement, or a product spec—that defines which tools are allowed, denied, or conditionally permitted. The prompt works best when the input policy uses consistent terminology and explicit allow/deny language. If your policy is a set of vague principles or aspirational guidelines, this prompt will produce a low-confidence, incomplete output that requires significant human rework. Before using this prompt, ensure you have a target schema for the output policy object, such as a JSON schema that your authorization service can consume directly.

Do not use this prompt when the policy itself is the thing you are trying to draft, debate, or get legal sign-off on. This prompt extracts and structures existing policy; it does not create new policy from first principles. Do not use it for real-time per-request authorization decisions—that is the job of a separate enforcement prompt that consumes the structured policy this prompt produces. If your input document mixes policy with implementation details, tutorials, or historical commentary, pre-process it to isolate the normative policy statements. Finally, always run the extracted policy object through a validation harness that checks for completeness, conflicts, and coverage gaps before deploying it to production enforcement. A malformed policy object is a safety incident waiting to happen.

This prompt template is the core engine for translating a natural-language policy document or configuration file into a structured JSON policy object. It is designed to be pasted into your prompt layer and wired into a policy ingestion pipeline. The template uses square-bracket placeholders for all dynamic inputs, allowing you to swap in different policy documents, output schemas, and constraints without rewriting the core instruction set. The goal is a deterministic, auditable extraction that a downstream policy enforcement engine can consume directly.

textCopy
You are a policy extraction engine. Your task is to convert the provided human-readable policy document into a structured, machine-enforceable tool access policy object.

## INPUT
[POLICY_DOCUMENT]

## OUTPUT SCHEMA
You must output a single JSON object conforming to this exact schema:
{
  "policy_name": "string",
  "version": "string",
  "rules": [
    {
      "rule_id": "string",
      "description": "string",
      "target": {
        "tool_name": "string | null",
        "tool_category": "string | null",
        "argument_pattern": "string | null"
      },
      "condition": {
        "user_role": ["string"],
        "risk_level": "low | medium | high | critical",
        "session_state": "string | null",
        "time_window": "string | null"
      },
      "action": "allow | deny | flag_for_review",
      "priority": "integer",
      "policy_reference": "string"
    }
  ],
  "default_action": "deny | flag_for_review",
  "conflicts": [
    {
      "rule_ids": ["string", "string"],
      "description": "string",
      "resolution": "string"
    }
  ],
  "ambiguities": [
    {
      "location": "string",
      "description": "string",
      "suggested_clarification": "string"
    }
  ]
}

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
1. Parse the entire [POLICY_DOCUMENT] to identify every explicit and implicit tool access rule.
2. For each rule, extract the target tool, conditions, and action. If a tool name is not specified, use the `tool_category` field.
3. Assign a `priority` integer to each rule where higher numbers indicate higher precedence.
4. Populate the `conflicts` array if two or more rules could apply to the same request with different actions. Propose a resolution based on rule priority or explicit policy statements.
5. Populate the `ambiguities` array for any policy language that is vague, undefined, or could be interpreted in multiple ways. Suggest a clarification.
6. Set the `default_action` based on the policy's stated default posture. If not stated, default to `deny`.
7. Every rule must include a `policy_reference` string quoting or citing the exact text from [POLICY_DOCUMENT] that supports it.
8. Do not invent rules, tools, or conditions not present in the document.

To adapt this template, replace [POLICY_DOCUMENT] with the full text of your access policy. The [CONSTRAINTS] placeholder should be populated with any additional extraction rules specific to your environment, such as required tool name formats, known user roles, or risk level definitions. If your policy is split across multiple files, concatenate them into a single input string. The output schema is intentionally strict; validate the generated JSON against this schema before allowing it to reach your policy enforcement engine. For high-risk production systems, always route the extracted policy object through a human review step before enforcement.

This prompt is designed to be a pre-processing step in a policy enforcement pipeline, not a real-time decision engine. It should be run offline or on a scheduled basis whenever the source policy document or configuration file changes. The output is a machine-enforceable policy object that downstream systems—such as a tool authorization proxy or an agent's pre-flight check—can consume directly. Do not call this prompt on every user request; its job is to convert human-readable policy into structured rules once, so that runtime enforcement can be a fast, deterministic lookup.

Wiring the prompt into a pipeline requires three stages: extraction, validation, and deployment. First, call the model with the prompt template, passing the raw policy text as [POLICY_DOCUMENT] and your expected output schema as [OUTPUT_SCHEMA]. The schema should define the structure you need downstream—typically an array of rules, each with fields for tool_name, allowed_roles, required_risk_threshold, deny_message, and policy_citation. Second, validate the output programmatically: check that every rule references a known tool from your tool registry, that role names match your identity provider's groups, and that no two rules produce conflicting decisions for the same tool and role combination. Use a deterministic conflict resolver (e.g., most-specific-rule-wins) rather than asking the model to fix conflicts, which introduces non-determinism. Third, deploy the validated policy object to your enforcement layer—this could be a Redis cache, a configuration file read by your agent framework, or a row in a database queried by your tool authorization middleware.

Logging and observability are critical because policy extraction errors can silently create security gaps. Log the model's raw output, the validation errors, and the final deployed policy version. Attach a version hash to each deployed policy so you can trace which extraction run produced the rules currently in effect. If validation fails—for example, the model hallucinates a tool name or produces ambiguous deny conditions—the pipeline must block deployment and alert the platform team. Never fall back to a previous policy version automatically without human review, as the old policy may be intentionally permissive for tools that should now be restricted. For high-security environments, add a human approval gate between validation and deployment: a diff view showing what rules were added, removed, or modified, with the responsible engineer required to approve before the policy goes live.

Model choice matters for this task. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that are more likely to drop rules, merge conditions, or invent tool names. Set temperature=0 to maximize determinism, and use the model's structured output or JSON mode feature if available. If your policy document exceeds the model's context window, chunk it by section and run extraction per section, then merge the results with the same validation and conflict resolution logic. Do not summarize the policy before extraction—summarization can drop edge cases that are precisely the rules you need to enforce.

Testing the extraction requires a golden dataset of policy documents paired with expected rule outputs. Build at least 20 test cases covering: simple allow/deny rules, role-based access, risk-threshold gating, conflicting statements within the same document, ambiguous language (e.g., 'generally not allowed'), and missing information (e.g., a tool mentioned without a clear policy). Run these tests on every prompt or model change. Measure precision (did the prompt invent rules not in the document?) and recall (did it miss rules that are present?). A single missed deny rule is a security incident; a single invented deny rule is an availability incident. Both should block deployment.

What to avoid: Do not use this prompt as a runtime classifier for individual tool calls—it is too slow, too expensive, and too non-deterministic for that path. Do not skip the validation step and trust the model's output directly. Do not deploy a policy that failed validation. And do not treat the extracted policy as the source of truth; the human-authored policy document remains the authoritative record. The extracted policy object is a machine-readable derivative, and any discrepancy between the two must be resolved in favor of the human-authored source, with the extraction pipeline updated to close the gap.