Centralized vs Decentralized Identity Management Prompt Template

This prompt is for security architects and platform engineers who need a structured, evidence-based comparison of centralized and decentralized identity management models before committing to an implementation path. Use it when the decision involves multiple services, teams, or compliance boundaries. The prompt forces explicit reasoning about consistency, failure modes, latency, audit capability, and team autonomy. It is designed to prevent advocacy-driven decisions by requiring the model to argue both sides before synthesizing a recommendation grounded in your specific constraints.

Before using this prompt, you must have a clear understanding of your system's topology: the number of services, their trust boundaries, the user populations they serve, and the regulatory environment they operate in. The prompt requires you to supply [CONTEXT] that includes your current architecture, team structure, latency budgets, and any hard compliance requirements. Without this context, the model will produce a generic textbook comparison that fails to account for your operational reality. You should also define [CONSTRAINTS] such as mandatory audit trails, data residency requirements, or existing identity provider contracts that cannot be changed.

Do not use this prompt for trivial single-service authentication decisions or when the architecture is already locked by regulatory mandate with no room for trade-off analysis. If your decision is already made and you are seeking post-hoc justification, this prompt will surface the weaknesses in your chosen approach, which may be useful for risk documentation but not for confirmation. Similarly, avoid this prompt if you lack the authority or organizational context to act on the output; a thorough trade-off analysis that cannot influence implementation is wasted effort. For teams new to identity architecture, pair this prompt with a human expert review of the output before using it as a decision document.

This prompt template is designed to produce a rigorous, dimension-by-dimension comparison of identity management strategies. It forces the model to act as a security architect, evaluating options against explicit operational constraints rather than generating a generic pro-con list. The output is a structured decision memo suitable for an Architecture Decision Record (ADR) or a technical design review. Before using this prompt, you must gather specific context about your system's scale, latency requirements, audit needs, and team topology; the quality of the output depends directly on the precision of the inputs you provide in the placeholders.

textCopy
You are a principal security architect reviewing an identity management strategy for a distributed system. Your task is to produce a structured trade-off analysis comparing a centralized identity provider (IdP) model against a decentralized, service-local identity model. Do not advocate for one approach. Instead, evaluate both options across the specified dimensions, grounded in the provided system context.

## SYSTEM CONTEXT
[SYSTEM_CONTEXT]

## EVALUATION DIMENSIONS
For each dimension below, provide a comparative analysis (1-2 paragraphs) that explains the concrete trade-off for this specific system, not a generic definition.
- **Consistency and Policy Enforcement:** How is uniform policy (e.g., MFA, password complexity) guaranteed? What is the risk of drift?
- **Failure Modes and Resilience:** Analyze the blast radius of an IdP outage vs. a single service's auth module failure. Address the single-point-of-failure risk.
- **Latency and Performance:** Compare the network hop cost of a centralized token introspection call vs. local validation. Consider caching strategies.
- **Audit and Compliance:** Evaluate the difficulty of producing a unified audit trail of all authentication and authorization events across the system.
- **Team Autonomy and Operational Burden:** Compare the developer experience and operational overhead for teams owning their own identity logic vs. depending on a central platform team.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT FORMAT
Produce a JSON object with the following structure. Do not include any text outside the JSON.
{
  "analysis_title": "Identity Management Trade-off Analysis",
  "context_summary": "A 1-sentence summary of the system context.",
  "comparisons": [
    {
      "dimension": "string",
      "centralized_assessment": "string",
      "decentralized_assessment": "string",
      "key_trade_off": "string"
    }
  ],
  "risk_register": [
    {
      "risk": "string",
      "associated_model": "centralized | decentralized | both",
      "severity": "low | medium | high | critical",
      "mitigation_note": "string"
    }
  ],
  "recommendation": "A final paragraph that synthesizes the trade-offs and suggests a path forward, including a hybrid model if appropriate. Explicitly state the primary reason for the recommendation."
}

To adapt this template, replace the placeholders with dense, factual context. The [SYSTEM_CONTEXT] should describe the number of services, their trust boundaries, current auth mechanisms, and user types. The [CONSTRAINTS] placeholder must include hard requirements like 'latency budget for auth calls is <10ms p99' or 'SOC2 audit trail must be complete within 24 hours.' Vague constraints will produce a vague analysis. After generating the output, validate the JSON structure programmatically. For high-risk deployments, a human security architect must review the risk_register and recommendation fields before this analysis is used to justify an architectural decision. Do not treat this prompt's output as a final security review; it is a structured starting point for a human-led decision process.

This prompt is designed to be called programmatically as part of an architecture review pipeline, not as a one-off chat interaction. The caller should provide a structured input object containing the system context, the two identity management approaches being compared, and the evaluation dimensions. The output is a structured trade-off memo that can be parsed, stored in a decision log, and reviewed by a human architect before it becomes an official Architecture Decision Record (ADR). The prompt itself is stateless; all context must be supplied in each request.

Wire the prompt behind a thin API endpoint or a CI/CD pipeline step that triggers on architecture review requests. Before calling the model, validate that all required input fields are present and non-empty: [SYSTEM_CONTEXT], [APPROACH_A], [APPROACH_B], and [EVALUATION_DIMENSIONS]. Reject incomplete requests with a 400-level error rather than letting the model hallucinate missing context. After receiving the model response, validate the output against the expected schema: it must contain a trade_off_matrix with at least one dimension scored for each approach, a failure_modes section listing at least two risks per approach, and a recommendation field with a stated confidence level. If schema validation fails, retry once with the same input and an explicit repair instruction appended to the prompt. If the second attempt also fails, escalate to a human review queue with the raw output and validation errors logged.

For production use, select a model with strong structured output capabilities and a context window large enough to hold the full input plus the expected output. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable. Enable structured output mode (JSON mode or function calling with a strict schema) to reduce parsing failures. Log every request and response, including the validated output, the model version, and the latency, to an observability platform. This creates an audit trail for governance reviews and helps detect prompt drift over time. If the system context contains sensitive information about internal system vulnerabilities, ensure the logging pipeline redacts or encrypts those fields before storage.

This prompt does not require tool use or retrieval-augmented generation (RAG) because the analysis is based entirely on the provided context and architectural reasoning. However, if your organization maintains a library of past ADRs or incident postmortems, consider adding a retrieval step before the prompt call to inject relevant historical decisions as additional context. This grounds the trade-off analysis in organizational precedent. Do not use this prompt for real-time authentication decisions or runtime policy enforcement; it is a design-time analysis tool only. The output must always be reviewed by a human architect before it becomes binding, especially when the recommendation involves changes to the authentication surface or authorization policy enforcement points.