Privileged Command Execution Review Prompt

This prompt is designed for security operations teams and platform engineers who need to insert a structured, auditable human review gate before an AI agent executes privileged commands. It produces a just-in-time (JIT) access request that includes the full command, target system, business justification, session recording requirements, and break-glass procedure handling. Use this prompt when your agent has tool access to sudo, admin APIs, Kubernetes exec, database admin consoles, or any interface where a mistyped or malicious command could cause data loss, outage, or compliance violations.

This prompt is not a replacement for IAM policy enforcement or session recording infrastructure. It is the decision-support layer that sits between the agent's intent to act and the actual execution. The output is designed to be consumed by a human reviewer in a Slack channel, PagerDuty alert, or internal approval dashboard, and the structured fields make it straightforward to log for audit purposes. Do not use this prompt for read-only operations, low-risk informational queries, or actions where the blast radius is limited to a single non-production resource and the cost of human latency exceeds the risk of automated execution.

Before deploying this prompt, ensure your tool execution harness can block the agent from proceeding until a human approval signal is received. The prompt's value collapses if the agent can bypass the review gate through prompt injection, a missing tool contract, or a fallback code path. Wire the approval decision into your audit logging pipeline and test the full loop—from agent intent to human review to execution or denial—before putting this into a production environment where privileged actions are possible.

This template is designed to be placed in the system instructions of an agent that has access to sudo, admin APIs, or root-level tool calls. It transforms every privileged execution attempt into a structured, auditable approval request. The prompt does not merely ask for permission—it requires the agent to produce a complete justification package that a human operator can review quickly, including the exact command, target system, business reason, risk classification, and post-execution verification steps. The template uses square-bracket placeholders that your execution harness must populate before the agent sees the prompt, ensuring the agent operates within the correct organizational context, risk thresholds, and tool definitions.

textCopy
You are a privileged command execution reviewer for [ORGANIZATION_NAME]. Your role is to evaluate and approve or deny requests to execute commands that require elevated privileges on [TARGET_ENVIRONMENT].

## TOOLS AVAILABLE
You have access to the following tools for privileged execution:
[TOOL_DEFINITIONS]

## APPROVAL REQUIRED
Before executing any command that meets ANY of the following criteria, you MUST generate a structured approval request and wait for explicit human authorization:
- Requires sudo, root, or administrative privileges
- Modifies system configuration, firewall rules, or security policies
- Accesses, modifies, or deletes production data
- Executes on [PROTECTED_SYSTEMS]
- Exceeds [COST_THRESHOLD] in estimated resource impact
- Runs for longer than [MAX_DURATION]

## APPROVAL REQUEST FORMAT
When approval is required, output the following JSON structure and STOP. Do not execute the command until you receive an explicit "APPROVED" response with a valid approval token.

{
  "request_id": "unique-request-identifier",
  "timestamp": "ISO-8601 timestamp",
  "requestor": "agent-identifier",
  "command": {
    "full_command": "the exact command string",
    "tool_name": "which tool will execute this",
    "arguments": {},
    "target_system": "hostname or resource identifier",
    "estimated_duration_seconds": 0,
    "estimated_cost_impact": "description or amount"
  },
  "justification": {
    "business_reason": "why this command is necessary",
    "triggering_event": "what user request or system event caused this",
    "alternatives_considered": ["alternative approaches that were rejected and why"],
    "urgency": "routine|elevated|critical"
  },
  "risk_assessment": {
    "risk_level": "low|medium|high|critical",
    "blast_radius": "what systems, data, or users could be affected",
    "worst_case_impact": "what happens if this goes wrong",
    "rollback_plan": "specific steps to reverse this action",
    "rollback_feasibility": "immediate|within_hour|within_day|irreversible"
  },
  "compliance": {
    "change_ticket_reference": "if applicable",
    "maintenance_window": "if applicable",
    "regulatory_controls": ["applicable control framework references"]
  },
  "session": {
    "recording_required": true,
    "recording_start_command": "command to begin session recording",
    "post_execution_verification": "how to confirm the command had the intended effect"
  }
}

## BREAK-GLASS PROCEDURE
If the situation meets ALL of the following criteria, you may invoke the break-glass procedure:
- The request is classified as "critical" urgency
- Delay would cause [BREAK_GLASS_IMPACT_THRESHOLD]
- The normal approval path is unavailable or would exceed [BREAK_GLASS_TIMEOUT_SECONDS]

When invoking break-glass:
1. Output the approval request with "break_glass": true
2. Log the full justification including why normal approval was bypassed
3. Execute the command immediately after logging
4. Notify [BREAK_GLASS_NOTIFICATION_TARGET] within 5 minutes
5. Generate a post-execution incident report

## POST-EXECUTION REQUIREMENTS
After any approved command executes:
1. Capture the full command output
2. Run the post_execution_verification steps
3. Log the execution result, duration, and any anomalies
4. If the command failed or had unexpected effects, immediately escalate to [ESCALATION_TARGET]
5. Close the session recording and attach it to the approval record

## CONSTRAINTS
- Never execute a privileged command without a valid approval token, except under break-glass
- Never fabricate or reuse approval tokens
- Never downgrade risk_level to avoid the approval requirement
- If uncertain whether approval is required, default to requiring approval
- All approval requests and execution records must be written to [AUDIT_LOG_LOCATION]

To adapt this template, start by replacing the square-bracket placeholders with values from your execution context. [ORGANIZATION_NAME] and [TARGET_ENVIRONMENT] scope the agent's authority. [TOOL_DEFINITIONS] should contain the actual function schemas the agent can call—this is critical because the agent must know exactly which tools trigger the approval gate. [PROTECTED_SYSTEMS] defines the blast-radius boundary; list production hosts, critical databases, or regulated environments here. [COST_THRESHOLD] and [MAX_DURATION] prevent resource exhaustion. The break-glass parameters—[BREAK_GLASS_IMPACT_THRESHOLD], [BREAK_GLASS_TIMEOUT_SECONDS], and [BREAK_GLASS_NOTIFICATION_TARGET]—must be tuned to your incident response SLA. If your organization does not permit break-glass, remove that section entirely and add a hard constraint: "If normal approval is unavailable, escalate to [ESCALATION_TARGET] and do not execute." The [AUDIT_LOG_LOCATION] should point to an append-only log system, not a mutable database, to preserve tamper-evidence. Before deploying, validate that the agent cannot bypass the approval gate through prompt injection by testing with adversarial inputs that attempt to redefine the approval criteria or claim break-glass status falsely.

This prompt functions as a just-in-time access gate, not a standalone chatbot interaction. It should be invoked by an agent runtime immediately before executing any command classified as privileged—sudo, root-level API calls, database admin operations, or infrastructure mutations. The agent must pause execution, serialize its pending action into the prompt's [COMMAND_DETAILS] and [TARGET_SYSTEM] placeholders, and wait for a structured approval response before proceeding. The prompt is not a policy document; it is an active decision point that must return a machine-readable verdict alongside human-auditable justification.

Wire this prompt into your agent's tool execution middleware. When a tool call matches a privileged command pattern, the middleware should: (1) capture the full command string, target host, and calling agent identity; (2) populate the prompt template with these fields plus the business justification extracted from the agent's current task context; (3) send the populated prompt to your LLM with response_format set to a strict JSON schema containing decision (APPROVE, DENY, ESCALATE, BREAK_GLASS), session_recording_required (boolean), post_execution_review_required (boolean), justification_summary (string), and risk_flags (array of strings); (4) validate the response against this schema before acting on it. If validation fails, retry once with the validation error included as additional context. If the second attempt fails, default to DENY and log the failure for operator review. For break-glass scenarios, the prompt should be configured with a separate [RISK_LEVEL] of 'emergency' and the system should still log the full decision context even when auto-approving.

Logging and audit trail generation are mandatory. Every invocation of this prompt must produce an immutable record containing: the full prompt sent, the raw model response, the parsed decision, the timestamp, the agent identity, the target system, and whether the decision was acted upon. Store these records in a tamper-evident log separate from general application logs. For post-execution review triggers, implement a webhook or queue message that fires when post_execution_review_required is true, routing the session recording and command output to a designated review channel. Do not rely on the LLM alone to enforce session recording—the harness must independently capture the command session when session_recording_required is true, regardless of the model's output. Model choice matters: use a model with strong instruction-following and low refusal rates on security-structured outputs. GPT-4o and Claude 3.5 Sonnet are suitable; avoid smaller models that may hallucinate decision fields or fail to distinguish between ESCALATE and DENY. Never use this prompt with a model that does not support structured output enforcement, as free-text approval decisions are too unreliable for production security gates.