Service-to-Service Authentication Architecture Prompt

This prompt is designed for platform architects and security engineers who need to evaluate service-to-service authentication mechanisms before implementation. Use it when you have a system design document, a list of services, and a set of operational constraints (compliance, latency, team maturity). The prompt produces a structured comparison across mTLS, SPIFFE, JWT, and API-key approaches, covering credential lifecycle, revocation speed, identity propagation, and blast-radius impact.

The ideal input is a concrete architecture proposal, not a blank-slate brainstorming session. Provide the prompt with a description of the services involved, their communication patterns (synchronous vs. asynchronous), the trust boundaries between them, and any hard constraints such as regulatory requirements (PCI-DSS, HIPAA), latency budgets, or existing infrastructure (service mesh, API gateway). The prompt is most effective when you also specify the operational maturity of the teams that will manage the credentials, as this directly impacts the feasibility of complex solutions like SPIFFE.

Do not use this prompt for user-facing authentication flows, OAuth grant-type analysis, or secrets storage review. Those belong in sibling playbooks covering Authentication Flow Review, OAuth 2.0 Security Review, and Secrets Management Architecture Review. This prompt is also not a substitute for a full threat model; use the Threat Modeling Architecture Prompt Template for that. If your primary concern is network-level segmentation rather than service identity, start with the Network Segmentation Analysis Prompt. Finally, avoid this prompt if you lack a concrete design document—it requires specific architectural context to produce a useful comparison, not generic best-practice advice.

The prompt below is designed to be pasted directly into your AI system. It forces the model into a specific architectural persona and constrains the output to a structured comparison format. Every square-bracket placeholder must be replaced with your actual design context before use. The prompt explicitly requests trade-off analysis rather than advocacy, which reduces the risk of the model confidently recommending an approach that doesn't fit your operational reality.

textCopy
You are a platform security architect reviewing a service-to-service authentication design. Your task is to produce a structured comparison of authentication approaches for the following context.

## DESIGN CONTEXT
[SYSTEM_DESCRIPTION]

## CONSTRAINTS
- Service mesh available: [YES/NO]
- Cloud provider: [PROVIDER]
- Compliance requirements: [COMPLIANCE_STANDARDS]
- Maximum acceptable credential lifetime: [DURATION]
- Existing identity provider: [IDP_DETAILS]
- Number of services: [COUNT]
- Service topology: [MESH_HUB_SPOKE_PEER_TO_PEER]

## APPROACHES TO COMPARE
Evaluate these approaches against the context above:
- mTLS with short-lived certificates
- SPIFFE/SPIRE-based identity
- JWT with OAuth 2.0 client credentials grant
- API keys with HMAC signing
- Cloud-provider managed identity (e.g., AWS IAM, GCP service accounts)

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "comparison_matrix": [
    {
      "approach": "string",
      "credential_rotation": {"mechanism": "string", "automation_level": "high|medium|low", "revocation_speed": "string"},
      "identity_propagation": {"mechanism": "string", "caller_identity_preserved": true|false, "delegation_support": "string"},
      "operational_burden": {"key_management": "string", "observability": "string", "onboarding_complexity": "string"},
      "blast_radius_analysis": {"compromised_credential_impact": "string", "lateral_movement_risk": "high|medium|low", "mitigation_options": ["string"]},
      "fit_for_context": {"score": 1-5, "rationale": "string", "blockers": ["string"]}
    }
  ],
  "recommendation": {
    "primary_approach": "string",
    "rationale": "string",
    "required_compensating_controls": ["string"],
    "migration_complexity": "low|medium|high",
    "risks_if_adopted": ["string"]
  },
  "rejected_approaches": [
    {
      "approach": "string",
      "rejection_reason": "string",
      "context_change_that_would_make_it_viable": "string"
    }
  ]
}

## RULES
1. Do not invent capabilities that don't exist in the specified cloud provider or service mesh.
2. If a compliance standard requires specific credential handling, cite the relevant control.
3. For each approach, identify at least one failure mode specific to the described topology.
4. If the context lacks enough detail to evaluate an approach, flag it as "insufficient context" rather than guessing.
5. Prefer approaches that minimize long-lived credentials and support automated rotation.

After pasting this prompt, replace every [PLACEHOLDER] with concrete values from your architecture. If you don't know a value, replace it with "UNKNOWN" so the model can flag it rather than hallucinate. The output schema is strict JSON, which means you can validate it programmatically before feeding the results into a decision document or ADR. For high-risk deployments, run this prompt with at least two different models and compare the blast_radius_analysis and rejected_approaches sections for consistency. Disagreement between models on rejection reasons is a signal that your context description may be ambiguous.

This prompt is designed to be embedded in a design review pipeline, not used as a one-off chat. The typical integration point is a pull request or architecture RFC workflow where a design document is submitted, the prompt is executed, and the output is attached as a structured review comment. The prompt expects a design document describing the proposed service-to-service authentication architecture, including protocol choices, credential management, rotation strategy, and revocation mechanisms. Without these inputs, the model will produce generic advice rather than a targeted comparison.

Wire the prompt into an application by first validating that the input document contains the required sections: authentication protocol, credential lifecycle, identity propagation, and revocation approach. If any section is missing, return an error to the user rather than sending an incomplete prompt to the model. Use a two-stage pipeline: first, run a classification check to confirm the document is actually about service-to-service authentication (not user auth, not database auth). Second, execute the main prompt with the validated input. On the output side, parse the JSON response and validate that every comparison dimension (credential rotation, revocation, identity propagation, blast radius) is present with a non-empty assessment. If the output fails schema validation, retry once with the validation errors appended to the prompt as [CONSTRAINTS]. If the retry also fails, escalate to a human reviewer with the raw output and validation failure details attached.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, as design documents can be lengthy and the comparison requires holding multiple architectural patterns in memory simultaneously. Claude 3.5 Sonnet or GPT-4o are appropriate defaults. Avoid smaller or faster models for this task—the cost of a missed authentication weakness far exceeds the latency savings. Set temperature to 0.1 or lower to maximize consistency across runs. Log every prompt execution with the input document hash, model version, output, validation result, and any retry attempts. This audit trail is essential for security review workflows where decisions must be traceable. For teams running this prompt at scale across many design reviews, cache results by document hash to avoid redundant model calls when the same design is re-submitted without changes.

Do not use this prompt's output as an automated approval gate. The comparison it produces is a structured analysis for human reviewers, not a pass/fail verdict. Always route the output to a security architect or platform engineer for review before merging the design. The prompt can identify patterns and surface risks, but it cannot replace domain judgment about which trade-offs are acceptable for a specific system. If the design involves regulated data or compliance requirements (PCI, HIPAA, SOC 2), add a mandatory human approval step before the review comment is published. The harness should enforce this by checking a [RISK_LEVEL] parameter: if set to 'high' or 'regulated', block automated publishing and require explicit approval in the review tool.