Security Audit Task Breakdown Prompt

This prompt is designed for security review agents and autonomous audit orchestrators that must convert a high-level audit scope into a structured, executable work plan. The ideal user is an engineering lead or security architect integrating an AI agent into a continuous security review pipeline. The required context includes a defined audit objective, a list of available security tools and their capabilities, the target system's architecture, and a clear risk tolerance or rules of engagement. The prompt decomposes the objective into four sequential phases: reconnaissance, vulnerability assessment, finding documentation, and remediation planning. The output is a risk-prioritized task list with evidence collection steps, tool assignments, and explicit approval gates for any destructive or high-impact testing.

Use this prompt when you need a machine-readable audit plan that a downstream agent runtime can execute step by step. The generated plan is suitable for ingestion by a state machine or workflow engine that can manage tool calls, check preconditions, and enforce approval gates. The harness must validate that the output contains no hallucinated tools, that all destructive tests are flagged for human approval, and that the task ordering respects data dependencies between phases. For example, a vulnerability assessment task should not appear before its prerequisite reconnaissance task is complete. The prompt is most effective when the audit scope is well-defined but the specific steps require expert decomposition.

Do not use this prompt for real-time incident response, where predefined runbooks and human judgment must take precedence over generated plans. It is also unsuitable for physical security audits, social engineering assessments, or any context where the model's lack of real-world grounding could produce dangerous recommendations. For high-risk production environments, always pair the generated plan with a human review step before execution begins. The plan is a starting point for expert refinement, not a replacement for security engineering judgment.

The following prompt template is designed to be copied directly into your AI harness. It instructs the model to act as a security audit planner and decompose a high-level audit scope into a structured set of subtasks. The template uses square-bracket placeholders that you must replace with your specific audit scope, available tools, and output requirements before sending it to the model. The prompt enforces a strict JSON output schema so that the resulting task plan can be parsed and executed by a downstream agent orchestrator without manual reformatting.

codeCopy
You are a security audit planning agent. Your job is to decompose the provided audit scope into a structured, executable work plan. You must produce a risk-prioritized sequence of subtasks covering reconnaissance, vulnerability assessment, finding documentation, and remediation planning. You must only use the tools listed in [TOOL_INVENTORY]. Do not invent or assume capabilities not present in that list.

## AUDIT SCOPE
[SYSTEM_DESCRIPTION]

## CONSTRAINTS
- Target environment: [TARGET_ENVIRONMENT]
- Compliance framework (if any): [COMPLIANCE_FRAMEWORK]
- Out-of-scope items: [OUT_OF_SCOPE]
- Risk level: [RISK_LEVEL]

## AVAILABLE TOOLS
[TOOL_INVENTORY]

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "audit_plan": {
    "objective": "string",
    "scope_boundaries": ["string"],
    "tasks": [
      {
        "task_id": "string",
        "phase": "reconnaissance | vulnerability_assessment | finding_documentation | remediation_planning",
        "description": "string",
        "tool": "string from TOOL_INVENTORY or 'manual'",
        "inputs": ["string"],
        "expected_outputs": ["string"],
        "dependencies": ["task_id"],
        "risk_priority": "critical | high | medium | low",
        "is_destructive": true | false,
        "requires_approval": true | false,
        "approval_rationale": "string if requires_approval is true, otherwise null",
        "evidence_required": ["string"]
      }
    ],
    "execution_order": ["task_id"],
    "approval_gates": [
      {
        "before_task_id": "string",
        "reason": "string",
        "approver_role": "string"
      }
    ]
  }
}

## RULES
1. Every task must reference a tool from TOOL_INVENTORY or be marked as 'manual'.
2. Mark any task that modifies the target system, runs exploits, or could cause disruption as `is_destructive: true` and `requires_approval: true`.
3. Include an `approval_rationale` for every task that requires approval.
4. Tasks must be ordered by dependency and risk priority. Critical-risk tasks come first within their dependency group.
5. Do not include tasks for out-of-scope items.
6. If the audit scope is too vague to decompose safely, return a JSON object with a single `clarification_needed` field containing a list of specific questions.

To adapt this template, start by replacing [SYSTEM_DESCRIPTION] with a concrete description of the target system, including its architecture, exposed services, and data sensitivity. Populate [TOOL_INVENTORY] with the exact list of tools your agent has access to, such as nmap, sqlmap, burp_scanner, or aws_inspector. If your audit must align with a specific compliance framework like SOC 2 or PCI DSS, specify it in [COMPLIANCE_FRAMEWORK] so the model can generate evidence collection steps that map to control requirements. Before integrating this prompt into a production harness, validate that the output schema is enforced by a JSON schema validator and that any task flagged as is_destructive: true triggers a hard stop in your orchestration layer until a human approves it. Do not remove the clarification_needed escape hatch; it prevents the model from hallucinating a plan when the scope is insufficiently defined.

This prompt is designed to be called by an agent orchestrator, not a human chat interface. The orchestrator must treat the prompt's output as a structured work plan that requires validation before any task is executed. The primary integration point is a planning module that receives a high-level audit scope and returns a JSON task graph. The harness must parse this graph, validate its structure, and then hand validated subtasks to an execution engine that respects the risk-prioritized ordering and approval gates.

The harness must enforce several critical checks before execution begins. First, validate that the output contains a valid task graph with no cycles in the dependency structure—use a topological sort to confirm a valid execution order exists. Second, scan every subtask for destructive or high-risk actions (e.g., active vulnerability scanning, exploitation attempts, configuration changes) and flag them for human approval. A simple keyword and pattern matcher can catch common destructive actions, but a secondary LLM call with a classification prompt is more robust for novel phrasings. Third, confirm that every subtask has a defined completion criterion and that evidence collection steps precede any analysis or documentation steps that depend on them. If any of these checks fail, the harness must reject the plan and either request a replan or escalate to a human operator.

For model choice, use a model with strong reasoning and JSON output capabilities. The prompt includes an [OUTPUT_SCHEMA] placeholder that should be populated with a strict JSON schema definition. Enable structured output mode if the model supports it. Set a retry policy: if the model returns malformed JSON or fails schema validation, retry up to two times with the validation errors included in the retry prompt. After two failures, log the full response and escalate. All prompt calls, outputs, validation results, and approval decisions must be logged with timestamps and trace IDs for auditability. Never execute a destructive or high-risk subtask without a recorded human approval. For evidence collection steps, store outputs in a structured evidence log that downstream analysis and documentation subtasks can reference, ensuring traceability from findings back to the collected evidence.