API Gateway Security Architecture Review Prompt

This prompt is designed for security architects and platform engineers who need to perform a structured security assessment of an API gateway design before it is implemented or during a formal architecture audit. The job-to-be-done is converting a static design document, configuration spec, or architecture proposal into a dynamic control assessment that identifies specific gaps in authentication enforcement, authorization policy, rate limiting, request validation, and threat protection. The ideal user has access to a detailed gateway architecture document that describes routing rules, policy configurations, and backend service relationships, and they need an output that maps findings directly to the OWASP API Security Top-10 risks with severity ratings and actionable remediation guidance.

To use this prompt effectively, you must provide a design document that contains enough technical detail for the model to reason about control placement and effectiveness. The input should describe how the gateway handles token validation, scope checks, rate limit keys, request schema validation, and threat detection rules. The prompt assumes the gateway sits at the boundary between clients and backend services, and it will probe for common architectural weaknesses such as direct backend access paths that bypass the gateway, inconsistent authorization across routes, and missing controls on internal service-to-service calls. Do not use this prompt for runtime incident response, where you need live traffic analysis and real-time attack correlation, because it lacks the context of production telemetry. Do not use it for code-level vulnerability scanning, which requires static analysis of implementation details rather than architectural control placement. Do not use it for penetration test reports, which demand evidence of exploitability and proof-of-concept validation that a design review cannot provide.

Before running this prompt, verify that your input document covers the gateway's role in the broader system architecture, including how it integrates with identity providers, service meshes, and monitoring systems. The prompt is most effective when the design is stable enough to review but not yet locked into implementation, giving you time to address findings before they become expensive to fix. After receiving the assessment, treat high-severity findings as candidates for immediate architectural revision, and use the OWASP mapping to prioritize remediation based on your organization's risk appetite. If the input document is incomplete or the gateway design is still in early exploration, consider using a lighter-weight threat modeling prompt first, then return to this assessment when the design has enough detail to support a control-by-control review.

This prompt template is designed to be pasted directly into your AI workflow. It instructs the model to act as a security architect reviewing an API gateway design for authentication, authorization, rate limiting, request validation, and threat protection controls. The prompt is structured for single-pass execution and returns a machine-readable JSON output that can be validated by downstream application code.

textCopy
You are a principal security architect specializing in API gateway security. Review the provided API gateway architecture description against the OWASP API Security Top 10 and common gateway bypass patterns. Your review must be evidence-based, referencing specific details from the input. Do not invent controls that are not described.

## INPUT
[ARCHITECTURE_DESCRIPTION]

## CONSTRAINTS
- Only assess controls explicitly mentioned or clearly implied by the architecture description.
- Flag missing controls as gaps; do not assume they exist.
- If the description is insufficient to assess a risk, mark it as "INSUFFICIENT_DATA" with a brief explanation of what information is needed.
- For each finding, cite the specific part of the architecture description that supports your assessment.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "assessment_summary": {
    "overall_risk_level": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
    "total_findings": <number>,
    "critical_findings": <number>,
    "high_findings": <number>,
    "medium_findings": <number>,
    "low_findings": <number>
  },
  "findings": [
    {
      "id": "F-<sequential number starting at 001>",
      "owasp_category": "<OWASP API category, e.g., API1:2023 Broken Object Level Authorization>",
      "severity": "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "INFO",
      "title": "<concise finding title>",
      "description": "<detailed description of the finding>",
      "evidence": "<direct quote or reference from the architecture description>",
      "impact": "<what an attacker could achieve if this is exploited>",
      "recommendation": "<specific, actionable remediation step>",
      "bypass_risk": "<description of how this control could be bypassed, or 'NONE' if not applicable>"
    }
  ],
  "bypass_analysis": {
    "direct_backend_access": "<assessment of whether backend services can be reached without traversing the gateway>",
    "header_injection_risk": "<assessment of header forwarding and trust boundaries>",
    "authentication_bypass_paths": "<identified paths that might skip authentication>",
    "rate_limit_evasion": "<assessment of rate limiting bypass techniques like IP rotation or header manipulation>"
  },
  "insufficient_data_items": [
    {
      "topic": "<what is missing>",
      "why_needed": "<why this information matters for the assessment>"
    }
  ]
}

## RISK_LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

Adapting the template: Replace [ARCHITECTURE_DESCRIPTION] with the full text of your API gateway design document, architecture diagram description, or configuration summary. The [RISK_LEVEL] placeholder accepts a value like HIGH to calibrate the review's sensitivity—use HIGH for payment systems or PII-handling APIs, and MEDIUM for internal tools. The [EXAMPLES] placeholder can be populated with one or two example findings from prior reviews to calibrate output style and severity judgment. After pasting, verify that the model returns valid JSON matching the output schema before wiring this into an automated pipeline.

Validation and safety: Because this prompt produces security findings that may influence architectural decisions, always run the output through a JSON schema validator before ingestion. For high-risk systems, route findings marked CRITICAL or HIGH to a human security reviewer before accepting them as actionable. The bypass_analysis section is particularly important—many gateway reviews focus on the happy path and miss direct backend access or header injection paths. If the model returns INSUFFICIENT_DATA items, treat those as blockers: do not proceed with the review until the missing information is provided. A common failure mode is the model inventing controls that are not described; the evidence field requirement and the constraint against assuming controls are designed to catch this.

This prompt is designed to be integrated into a security review pipeline, not used as a one-off chat. The primary integration point is a CI/CD or design-review platform where architecture documents (ADRs, interface specs, network diagrams) are submitted for automated assessment. The prompt expects a structured [ARCHITECTURE_DOCUMENT] input, typically a markdown or JSON representation of the gateway configuration, routing rules, and authentication policies. The output is a structured JSON assessment that downstream systems can parse, store, and compare against previous reviews.

Wire the prompt into an application by first validating the input document for completeness before calling the model. Implement a pre-flight check that verifies the presence of required sections: authentication mechanisms, authorization policies, rate limiting configuration, request validation rules, and backend service mappings. If any section is missing, return a structured error to the user rather than sending an incomplete document to the model. After the model responds, validate the output JSON against a strict schema that includes required fields like findings, severity, owasp_category, affected_endpoints, and remediation. Use a JSON Schema validator in your application code—do not rely on the model to always produce valid JSON. On validation failure, implement a single retry with the error message appended to the prompt context, then escalate to human review if the retry also fails.

For high-risk deployments, route all CRITICAL or HIGH severity findings to a human approval queue before the review is considered complete. Log every prompt invocation with the input document hash, model version, output findings, and reviewer decision. This creates an audit trail for compliance and allows you to track whether the model's assessments are becoming more or less conservative over time. Use a model with strong structured output support (GPT-4o with response_format or Claude with tool use) and set temperature=0 to minimize variance across repeated reviews. If your gateway configuration includes sensitive endpoints or internal IP addresses, redact them in a pre-processing step before sending to the model API. Finally, implement a bypass-detection eval: after the model produces its assessment, run a separate check that verifies every public endpoint is accounted for in the authentication and authorization findings—this catches the common failure mode where the model misses direct backend access paths that bypass the gateway entirely.