Domain Model Security Boundary Audit Prompt

This prompt is designed for security architects and domain engineers who need to audit authorization boundaries across aggregates and bounded contexts before code ships. It takes a documented domain model description—including aggregates, contexts, and actor definitions—and produces a structured security audit identifying missing access controls, data leakage risks, and trust boundary violations. The primary job-to-be-done is to shift security review left into the design phase, catching authorization flaws when they are cheap to fix rather than after implementation.

Use this prompt during design review sessions, threat modeling workshops, or as a pre-implementation gate before committing to aggregate and service boundaries. The prompt assumes you have a documented domain model with explicit aggregate roots, bounded context definitions, and actor or role descriptions. If your model is purely verbal, sketched on a whiteboard without detail, or missing actor definitions, the audit will produce low-confidence findings that require extensive human verification. The more precise your input, the more actionable the output.

Do not use this prompt as a replacement for penetration testing, runtime security scanning, or production access control audits. It operates at the design level and cannot detect implementation bugs, misconfigured identity providers, or runtime injection vulnerabilities. Additionally, this prompt is not suitable for systems without a domain-driven design foundation—if your architecture lacks explicit aggregate boundaries or context mapping, the security boundary analysis will be speculative at best. Always pair the output with human security review before accepting findings as authoritative.

The prompt below is designed to be copied directly into your AI harness. Every placeholder in square brackets must be replaced with concrete artifacts from your domain model before execution. This template assumes you have already prepared a domain model representation (aggregates, entities, value objects, and their relationships), a set of actor roles with intended access patterns, and a list of sensitive data classifications. The prompt instructs the model to act as a security architect performing a structured audit, not as a general-purpose assistant offering vague advice.

textCopy
You are a security architect reviewing a domain model for authorization boundary violations, data leakage risks, and trust boundary misconfigurations.

## DOMAIN MODEL
[DOMAIN_MODEL]

## ACTOR ROLES AND INTENDED ACCESS
[ACTOR_ROLES_AND_ACCESS]

## SENSITIVE DATA CLASSIFICATIONS
[SENSITIVE_DATA_CLASSIFICATIONS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "audit_summary": {
    "total_findings": <integer>,
    "critical_count": <integer>,
    "high_count": <integer>,
    "medium_count": <integer>,
    "low_count": <integer>
  },
  "findings": [
    {
      "id": "SEC-<4-digit-increment>",
      "severity": "critical|high|medium|low",
      "category": "missing_access_control|data_leakage|trust_boundary_violation|privilege_escalation|insecure_default|other",
      "affected_aggregates": ["<aggregate_name>"],
      "description": "<clear description of the finding>",
      "threat_scenario": "<how an attacker or unauthorized actor could exploit this>",
      "violated_principle": "<least_privilege|defense_in_depth|fail_secure|separation_of_duty|other>",
      "remediation": "<specific design change recommendation>",
      "effort_estimate": "small|medium|large"
    }
  ],
  "trust_boundary_map": {
    "boundaries": [
      {
        "name": "<boundary_name>",
        "between": ["<context_or_aggregate>", "<context_or_aggregate>"],
        "current_protection": "<description>",
        "gaps": ["<gap_description>"]
      }
    ]
  },
  "data_flow_risks": [
    {
      "flow": "<source> -> <destination>",
      "data_classification": "<classification>",
      "risk": "<description>",
      "current_controls": "<description>",
      "recommendation": "<description>"
    }
  ]
}

## CONSTRAINTS
- Only report findings supported by evidence in the provided domain model.
- Do not invent aggregates, roles, or data flows not present in the input.
- If a finding is speculative, mark it as "low" severity and note the assumption.
- For each finding, provide a concrete threat scenario, not a generic security platitude.
- If no findings exist for a category, return an empty array for that field.
- Prefer specific remediation steps over vague guidance like "add access controls."

## RISK_LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

After copying the template, replace [DOMAIN_MODEL] with a structured representation of your aggregates, entities, and their relationships. This can be a JSON schema, a text description of bounded contexts and aggregate roots, or a diagram description. Replace [ACTOR_ROLES_AND_ACCESS] with a mapping of user roles, service accounts, or external systems to their intended read/write access on each aggregate. Replace [SENSITIVE_DATA_CLASSIFICATIONS] with your organization's data classification taxonomy (e.g., PII, PCI, PHI, confidential, internal-only). The [RISK_LEVEL] placeholder should be set to the system's risk tolerance (e.g., "high" for regulated systems, "medium" for internal tools). The [EXAMPLES] placeholder should contain one or two example findings that demonstrate the expected depth and specificity. Do not skip this step—examples are the most reliable way to calibrate output quality. Before deploying this prompt into a production pipeline, validate the output against the JSON schema, run at least three known-domain test cases where you already know the expected findings, and require human review for any finding marked "critical" or "high" severity.

This prompt is designed for a human-in-the-loop security review workflow, not for autonomous enforcement. The model produces a structured audit report that a security architect or senior engineer must review, challenge, and sign off on before any findings become action items. Wire the prompt into a review pipeline that captures the model's output alongside the source artifacts (domain model diagrams, aggregate definitions, authorization policies) so that every finding is traceable to evidence. The output schema includes a finding_id and evidence_reference field for each issue, which your application should use to link findings back to specific aggregate boundaries, API contracts, or policy documents.

Validation and retry logic: Parse the model's JSON output immediately after generation. Validate that every finding includes a non-empty finding_id, severity (one of CRITICAL, HIGH, MEDIUM, LOW), affected_aggregate, risk_description, and evidence_reference. If the output fails schema validation, retry once with the same prompt plus the validation error message appended as a [VALIDATION_ERROR] constraint. If the second attempt also fails, flag the review session for manual completion and log the raw output for debugging. Do not silently accept malformed audit reports. Model choice: Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because boundary analysis requires tracing relationships across multiple aggregates and detecting implicit trust assumptions. Smaller or faster models frequently miss indirect data leakage paths and produce false negatives on MEDIUM and LOW severity findings.

Logging and audit trail: Store the full prompt, model response, validation result, and human reviewer's disposition (accepted, rejected, modified) for every audit run. This creates an evidence trail for compliance reviews and lets you measure the prompt's precision and recall over time. If your organization requires SOC 2, ISO 27001, or similar evidence, the audit trail must include the reviewer's identity, timestamp, and any findings they downgraded or dismissed with rationale. Tool integration: If your domain model lives in a structured format (e.g., OpenAPI specs, protobuf definitions, or architecture decision records in a git repository), use retrieval-augmented generation (RAG) to pull the relevant aggregate definitions and authorization policies into the [DOMAIN_MODEL_CONTEXT] placeholder rather than asking the reviewer to paste them manually. This reduces copy-paste errors and ensures the model audits the actual source of truth. When to escalate: If the model reports a CRITICAL finding, your workflow should automatically create a security review ticket and notify the security team, not wait for the next scheduled review cycle. For HIGH findings, require explicit human approval before closing. For MEDIUM and LOW, allow the reviewer to accept or dismiss with a required comment.

What to avoid: Do not use this prompt as a replacement for penetration testing, threat modeling sessions, or manual code review. The model cannot discover runtime authorization bugs, misconfigured IAM policies, or injection vulnerabilities that exist only in implementation. It audits the design of security boundaries, not their implementation. If your team treats the model's output as a complete security assessment, you will miss implementation-level vulnerabilities. Always pair this prompt with static analysis of authorization code, dynamic testing of access controls, and periodic manual threat modeling. The prompt is a force multiplier for experienced reviewers, not a substitute for security expertise.