Conditional Tool Access Grant Prompt

This prompt is for platform engineers and AI architects who need to define a structured, auditable policy mapping which tools an AI agent can access at each stage of graduated autonomy. The core job-to-be-done is translating a high-level autonomy stage definition (e.g., 'Supervised', 'Restricted Auto', 'Full Auto') into a concrete, machine-readable access control list. The ideal user is someone integrating a new tool into an agent framework or designing the initial security boundaries for a multi-stage agent deployment. Required context includes a list of available tools with their risk profiles and the definitions of your system's autonomy stages.

You should use this prompt when you need a first draft of a tool access policy that explicitly links permissions to autonomy gates, required approvals, and blocking conditions. It is most effective when the tool landscape is known but the permission mapping is complex and prone to privilege-escalation gaps. Do not use this prompt if you are defining the autonomy stages themselves; use the Staged Autonomy Policy Definition Prompt for that foundational work. This prompt assumes the stages are already defined and focuses solely on the tool-to-stage mapping. It is also not a replacement for runtime enforcement code; the output is a policy specification that must be implemented in your agent's authorization layer.

The prompt is designed to force explicit reasoning about dangerous transitions, such as an agent in a 'Restricted' stage gaining access to a 'delete' tool without a human approval step. It requires you to specify the exact approval mechanism for each sensitive tool-stage combination. After generating the policy, you must validate it against your actual tool schemas and test for missing coverage. The next step is to take the structured output and use it to configure your agent's tool gateway, then run the Autonomy Sandbox Testing Prompt to verify the policy behaves as expected before any production deployment.

This prompt template is the core instruction set for generating a Conditional Tool Access Grant Policy. It is designed to be dropped into an AI orchestration layer where the system has access to a list of available tools and a defined set of autonomy stages. The prompt forces the model to reason about privilege escalation, missing coverage, and the specific conditions under which a tool can be invoked at each stage of graduated autonomy.

textCopy
You are an AI platform security architect. Your task is to generate a strict Tool Access Policy based on the provided inputs.

## INPUTS
- **Available Tools:** [TOOLS]
- **Autonomy Stages:** [STAGES]
- **Risk Level:** [RISK_LEVEL]
- **Constraints:** [CONSTRAINTS]

## INSTRUCTIONS
1.  **Map Tools to Stages:** For each tool in [TOOLS], determine the minimum [STAGES] at which it can be granted. A tool may be granted at a higher stage but never at a lower one.
2.  **Define Conditions:** For each tool-stage mapping, specify the exact conditions that must be true for access to be granted. Conditions can include user role, time-boxed windows, specific request parameters, or confirmation requirements.
3.  **Specify Approvals:** For each mapping, define the required approval type: `auto`, `human_confirm`, `multi_stakeholder`, or `blocked`.
4.  **Privilege Escalation Analysis:** Identify any sequences of tools that, if chained together, could result in an unintended privilege escalation. Flag these paths explicitly.
5.  **Coverage Gap Analysis:** Identify any tools from [TOOLS] that have no clear mapping to any stage and flag them as `unmapped`.

## OUTPUT SCHEMA
You must return a single valid JSON object conforming to this structure:
{
  "policy_name": "string",
  "generated_at": "ISO8601 timestamp",
  "risk_level": "[RISK_LEVEL]",
  "tool_access_map": [
    {
      "tool_name": "string",
      "minimum_stage": "string from [STAGES]",
      "conditions": ["string"],
      "approval_type": "auto | human_confirm | multi_stakeholder | blocked",
      "escalation_paths": ["string describing a dangerous chain"]
    }
  ],
  "unmapped_tools": ["string"],
  "global_constraints": ["string from [CONSTRAINTS]"]
}

## CONSTRAINTS
- A tool with `approval_type: blocked` must have a clear justification in its conditions.
- Do not invent tools or stages not present in the inputs.
- If a tool's risk is unclear, default to `human_confirm` for the `minimum_stage`.

To adapt this template, replace the square-bracket placeholders with data from your application's control plane. The [TOOLS] placeholder should receive a structured list of tool names and descriptions. The [STAGES] placeholder expects an ordered list of your defined autonomy stages (e.g., supervised, supervised_write, autonomous_read, full_autonomy). After generating the policy, you must validate the output JSON against the schema and run an eval to ensure no high-risk tool is incorrectly mapped to an auto approval without explicit, verified conditions.

The Conditional Tool Access Grant Prompt is designed to be called by a policy enforcement service—not directly by an agent at runtime. The service should invoke this prompt during policy authoring or update cycles, passing the current autonomy stage definition, the complete tool catalog, and any existing access policies as [CONTEXT]. The model's output is a structured tool access policy mapping, which the service must parse, validate, and store before any agent is allowed to reference it. This separation ensures that tool access decisions are made offline by a governed process, not negotiated by an agent mid-task.

After receiving the model's JSON output, the implementation must run a strict validation pass before the policy takes effect. Check that every tool in the input catalog appears in the output mapping with an assigned stage, condition, and approval requirement. Validate that no privilege escalation paths exist—for example, a tool assigned to Stage 1 must not grant capabilities that could bypass Stage 2 restrictions. Reject any policy that references undefined stages, tools, or approval roles. If validation fails, log the specific violation, cache the rejected output for debugging, and either retry with a corrected [CONTEXT] or escalate to a human policy author. The service should also compare the new policy against the previous version and flag any tools that lost coverage or gained access without an explicit justification.

For production deployment, store the validated policy in a versioned configuration store with an audit log entry capturing the timestamp, the model version used, the input context hash, and the identity of the human who approved the change. The agent runtime should load this policy once at startup and enforce it on every tool call attempt—never call the LLM to decide tool access at invocation time. If the agent requests a tool outside its current stage, the harness must block the call, log the attempt, and return a structured denial that the agent can surface to the user or escalate. Avoid building a system where the model self-polices its own tool access; the policy must be enforced in application code with the LLM's output treated as a proposal, not a runtime authority.