Zero-Trust Boundary Validation Prompt

This prompt is built for security architects and platform engineers reviewing architecture documents, data flow diagrams, or infrastructure-as-code specifications before implementation. It produces a structured trust-boundary map that identifies violations where a component trusts another without explicit credential validation, authorization checks, or network policy enforcement. The output is designed to feed directly into threat modeling workflows, security decision records, and pre-deployment review gates. You should use this prompt when you have a concrete design artifact—a service topology description, an architecture decision record, or a set of Terraform or CloudFormation templates—and you need to systematically surface every place where one component implicitly trusts another.

The prompt assumes you have a design document, architecture diagram description, or service topology specification as input. It does not replace a formal threat model but accelerates the identification of trust-boundary violations that a human reviewer would otherwise need to trace manually. For best results, provide the prompt with a clear description of your system's components, their communication paths, the authentication mechanisms in use, and any network policies or security groups that govern traffic. The prompt will cross-reference these against zero-trust principles: every call must be authenticated, every request must be authorized, and no component should trust another based solely on network location or shared infrastructure.

Do not use this prompt for runtime incident response, live penetration testing reports, or compliance audits that require attestation under a specific regulatory framework. It is a design-time review tool, not a runtime detection system. The prompt will flag architectural patterns such as services accepting unauthenticated requests from within the same VPC, database connections that bypass credential rotation, or inter-service calls that rely on shared secrets without identity propagation. Each finding includes the violating component, the trust assumption being made, and a recommended remediation path. After running the prompt, you should validate its findings against your actual implementation, prioritize violations by blast radius, and document accepted risks in a security decision record before proceeding to implementation.

This prompt template is designed to be copied directly into your prompt management system, IDE, or orchestration harness. It uses square-bracket placeholders for all dynamic inputs. Before sending this to a model, replace every placeholder with concrete values from your architecture review context. The prompt instructs the model to act as a zero-trust security architect, systematically analyzing a system design for violations of the principle 'never trust, always verify.' It produces a structured trust-boundary map, a list of violations, and prioritized remediation guidance.

textCopy
You are a zero-trust security architect reviewing a system design. Your task is to identify every implicit trust assumption and produce a trust-boundary validation report.

## SYSTEM DESIGN
[DESIGN_DOCUMENT]

## CONTEXT
- Organization security policy highlights: [SECURITY_POLICY_CONTEXT]
- Known technology stack: [TECH_STACK]
- Regulatory or compliance requirements: [COMPLIANCE_REQUIREMENTS]

## INSTRUCTIONS
1. Identify every trust boundary in the system. A trust boundary exists wherever a request crosses between components, services, users, or data stores.
2. For each boundary, determine whether explicit authentication (AuthN) and authorization (AuthZ) are enforced. Flag any boundary where trust is implicit.
3. For each violation, classify the severity as CRITICAL, HIGH, MEDIUM, or LOW based on the sensitivity of the data or action involved.
4. Identify lateral movement paths: if an attacker compromises one component, what else can they reach without re-authentication?
5. Produce a remediation plan ordered by risk severity.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "trust_boundaries": [
    {
      "boundary_id": "string",
      "source": "string (calling component/user)",
      "target": "string (receiving component/data store)",
      "protocol": "string (e.g., gRPC, HTTP, message queue)",
      "authn_enforced": boolean,
      "authn_mechanism": "string or null",
      "authz_enforced": boolean,
      "authz_mechanism": "string or null",
      "implicit_trust_detected": boolean,
      "data_sensitivity": "PUBLIC | INTERNAL | CONFIDENTIAL | RESTRICTED"
    }
  ],
  "violations": [
    {
      "violation_id": "string",
      "boundary_id": "string",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "description": "string",
      "missing_control": "string",
      "exploit_scenario": "string"
    }
  ],
  "lateral_movement_paths": [
    {
      "path_id": "string",
      "entry_point": "string",
      "reachable_components": ["string"],
      "trust_exploited": "string"
    }
  ],
  "remediation_plan": [
    {
      "priority": integer,
      "violation_id": "string",
      "recommended_control": "string",
      "implementation_guidance": "string"
    }
  ],
  "summary": "string (executive summary of findings)"
}

## CONSTRAINTS
- Do not assume any authentication or authorization exists unless explicitly stated in the design.
- Treat every service-to-service call as untrusted by default.
- Flag any hardcoded credentials, shared secrets, or API keys mentioned in the design.
- If the design document lacks sufficient detail to determine a control, flag it as a finding with severity HIGH and note the missing information.
- Do not invent controls that are not described in the design.

To adapt this template, replace [DESIGN_DOCUMENT] with the full text of your architecture document, ADR, or system diagram description. The [SECURITY_POLICY_CONTEXT] placeholder should contain relevant excerpts from your organization's security standards—such as required AuthN mechanisms, approved protocols, or data classification rules. [TECH_STACK] helps the model reason about protocol-specific risks (e.g., mTLS for gRPC, JWT validation for REST). [COMPLIANCE_REQUIREMENTS] should list applicable frameworks like SOC 2, HIPAA, or PCI DSS so the model can flag gaps against specific control requirements. If you do not have policy context or compliance requirements, replace those placeholders with 'No specific policy provided' or 'No compliance framework specified' rather than leaving them empty. The output schema is strict JSON; wire this into a parser that validates the schema before accepting the result. For high-risk systems, always route the output to a human security reviewer before closing any findings.

This prompt is designed to be run against structured architecture documents, not live infrastructure. The implementation harness must treat the model's output as a draft security finding, not a final verdict. Every identified violation must be verified by a human reviewer before it becomes an action item. The harness should enforce this by routing all outputs to a review queue and blocking direct ticket creation or CI/CD gating until approval is recorded.

Wire the prompt into a document-processing pipeline: when a design doc (e.g., an ADR, a system boundary diagram description, or a service topology spec) is committed to a repository, a webhook triggers a job that extracts the relevant text, injects it into the [DESIGN_DOCUMENT] placeholder, and calls the model. The output schema—a JSON array of trust-boundary violations with source, target, protocol, authz_check, and severity fields—must be validated with a strict JSON Schema validator before the pipeline proceeds. If validation fails, retry once with a repair prompt that includes the schema and the raw output. If it fails again, log the failure and alert the pipeline owner; do not silently drop the review.

For each violation the model returns, the harness should attempt to ground the finding by searching the source document for the named services and protocols. If the cited services or calls are not present in the document, flag the finding as a potential hallucination and suppress it from the default report. This grounding step is critical: models will sometimes invent plausible-sounding service names or call paths that do not exist in the actual design. A simple string-match or fuzzy-search check against the input document reduces noise and builds reviewer trust.

The harness must also check for lateral movement paths across findings. After collecting all validated violations, run a graph-reachability query: if Service A trusts Service B without authz, and Service B trusts Service C without authz, then Service A can reach Service C. The harness should generate a separate lateral_movement_paths section in the final report, distinct from the direct violations. This analysis is deterministic code, not model inference—it belongs in the harness, not the prompt.

Log every model call with the prompt version, input hash, output, validation result, grounding result, and reviewer decision. This audit trail is essential for security review workflows, where you must be able to trace why a finding was accepted, rejected, or modified. Store logs in an append-only system and retain them for at least the duration of the architecture's lifecycle. Do not log the full design document if it contains secrets or sensitive topology details; log a content hash instead and store the document separately with access controls.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window (e.g., Claude 3.5 Sonnet or GPT-4o) because architecture documents can be long and the analysis requires multi-hop reasoning across service boundaries. Avoid small or fast models for this task—they are more likely to miss indirect trust relationships and produce underspecified findings. If cost is a concern, run the prompt on document commit (not on every push) and cache results keyed by document hash until the document changes.