Autonomous Agent Scope Increase Approval Prompt

This prompt is for AI product teams and platform engineers who manage autonomous agents with bounded capabilities. The job-to-be-done is generating a structured, reviewable scope expansion request before granting an agent new tool access, expanded decision authority, or additional API permissions. The ideal user is an engineering lead or AI safety engineer who needs a consistent, auditable format for proposing, assessing, and approving capability increases without slowing down safe iteration.

Use this prompt when an agent's operational boundary needs to change—for example, adding a database write tool, increasing a spending limit, or allowing an agent to bypass a confirmation step. The prompt requires several concrete inputs: a clear description of the new capability, the current agent scope for comparison, a risk assessment, a list of potential failure modes, and a phased rollout plan. Do not use this prompt for routine configuration changes that are already covered by existing approval workflows, or for one-off debugging sessions where scope changes are temporary and manually supervised.

This prompt is not a replacement for your identity and access management (IAM) system or your deployment pipeline's approval gates. It is a reasoning and documentation tool that sits before those systems. The output should feed into a human review queue or a change management system, not directly execute a permission change. Always pair this prompt with a blocking control in your application layer—such as a required approval in a ticketing system or a manual merge step—to ensure that no scope increase takes effect without explicit human authorization. For high-risk domains like finance or healthcare, require at least two reviewers and log the full approval payload for audit purposes.

This prompt template is designed to be integrated into an agent's decision loop when it identifies a need for a capability it does not currently possess. Instead of the agent simply failing or making an unsafe workaround, this prompt forces a structured justification. The output is a complete 'Scope Increase Request' payload that a human operator or an automated governance system can review. The template uses square-bracket placeholders to represent dynamic inputs from the agent's runtime state, such as its current task, the desired capability, and the operational context.

textCopy
You are an AI agent operating within a defined scope of authority and tool access. You have encountered a task that requires a capability outside your current permissions. You must not attempt to perform the action. Instead, generate a structured Scope Increase Request for human review.

CURRENT TASK: [CURRENT_TASK]
DESIRED CAPABILITY: [DESIRED_CAPABILITY]
REASON FOR REQUEST: [REASON]
CURRENT SCOPE: [CURRENT_SCOPE]
OPERATIONAL CONTEXT: [CONTEXT]

Generate a JSON object with the following structure:
{
  "request_id": "[REQUEST_ID]",
  "timestamp": "[TIMESTAMP]",
  "request_type": "scope_increase",
  "new_capability": {
    "name": "string",
    "description": "string",
    "required_tools_or_permissions": ["string"],
    "proposed_authority_limit": "string"
  },
  "risk_assessment": {
    "failure_modes": ["string"],
    "blast_radius": "string",
    "data_sensitivity_impact": "low" | "medium" | "high" | "critical",
    "rollback_feasibility": "immediate" | "complex" | "impossible"
  },
  "monitoring_and_rollout": {
    "success_metrics": ["string"],
    "monitoring_additions": ["string"],
    "phased_rollout_plan": [
      {
        "phase": "string",
        "duration": "string",
        "success_criteria": "string"
      }
    ]
  },
  "justification": "string"
}

CONSTRAINTS:
- Enumerate at least three distinct failure modes.
- The 'proposed_authority_limit' must be a specific, bounded scope, not an unbounded grant.
- If the rollback is not immediate, explain why.
- If the blast radius includes PII, financial data, or production infrastructure, the data_sensitivity_impact must be 'high' or 'critical'.

To adapt this template, replace the placeholders with data from your agent's runtime context. The [CURRENT_TASK] and [DESIRED_CAPABILITY] are generated by the agent's planning module. The [CURRENT_SCOPE] should be pulled from the agent's system prompt or a scoping document. The critical adaptation is the CONSTRAINTS section: you must tune these to match your organization's risk tolerance. For example, you might add a constraint that any request for a financial system tool requires a second, explicit approval from a finance admin. After generating the request, the application harness should validate the JSON schema, check that the failure modes list is not empty, and route the request to a human review queue. Never allow the agent to grant its own scope increase.

The Autonomous Agent Scope Increase Approval Prompt is not a standalone chat interaction. It is a gating function inside an agent orchestration layer. When an agent requests a new tool, permission, or decision authority, the system must pause execution, assemble the required context, invoke this prompt, and block the capability grant until a structured approval response is received and validated. The prompt output should be treated as a machine-readable approval request that a human reviews, not as a final decision.

Wire the prompt into your agent harness by intercepting capability registration calls. When an agent attempts to access a tool outside its current manifest, the orchestrator should collect: the agent's current scope definition, the requested capability, the task context that triggered the request, recent agent reasoning traces, and any existing risk assessments. Feed these into the prompt's [CURRENT_SCOPE], [REQUESTED_CAPABILITY], [TASK_CONTEXT], [AGENT_REASONING_TRACE], and [EXISTING_RISK_ASSESSMENTS] placeholders. The model must return a structured JSON object with fields for capability_description, risk_assessment, failure_mode_analysis, monitoring_additions, and phased_rollout_plan. Validate this output against a strict schema before presenting it to a human reviewer. Reject any response missing the failure_mode_analysis array or containing undefined authority boundaries.

Implement a blocking review queue as the next stage. The validated approval request should be routed to an authorized human with context about the agent's current workload, past scope changes, and the specific risk classification. The human's decision—approve, deny, or request modification—must be logged immutably with a timestamp, reviewer identity, and justification. Only after approval should the orchestrator update the agent's capability manifest. For high-risk domains, require a second approver or a cool-down period before the capability becomes active. Add monitoring hooks for the newly granted capability immediately upon activation, and set an automatic revocation trigger if anomaly thresholds are breached within the phased rollout window.

Model choice matters. Use a model with strong structured output support and low refusal rates on risk-classification tasks. GPT-4o and Claude 3.5 Sonnet are suitable defaults. Avoid smaller or older models that may collapse the failure mode enumeration into generic statements. Set temperature=0 or very low to ensure consistent risk classification across repeated evaluations. Do not use this prompt with models that lack reliable JSON mode, as a malformed approval request can block agent operations or, worse, allow scope increases without proper review. Log every prompt invocation, the raw model response, the validation result, and the human decision for audit and prompt regression testing.

What to avoid: Never allow the agent to self-approve scope increases by feeding its own output back into the decision path. Never skip the failure mode enumeration check—this is the primary safety mechanism. Never grant permanent scope increases without a time-bound phased rollout that includes automatic rollback criteria. If the prompt returns a risk level of 'critical' or 'high' and no human is available in the review queue, the system must default to denial and alert the on-call engineering team.