Authentication Boundary Triage Prompt

This prompt acts as a middleware triage step for classifying API requests and user sessions that have already reached an authentication boundary. Its job is to inspect a provided session token or credential payload and produce a structured decision: proceed, escalate for re-authentication, or reject. Platform engineers should use this when they need a clear, auditable auth decision paired with a user-facing message, not just a binary pass/fail from an identity provider. The ideal user is an infrastructure or platform engineer building an AI gateway, an agent harness, or a tool-dispatch layer where downstream models and data stores must not receive requests with missing, expired, or insufficient credentials.

This prompt assumes you already have a credential payload to inspect. It does not perform cryptographic validation, issue tokens, or manage login flows—those responsibilities belong in your identity provider (IdP) and token service. The prompt's value is in interpreting the state of a credential (e.g., expired, missing scopes, anonymous session) and mapping that state to a routing decision and a user-facing message. For example, an expired access token might trigger an escalate decision with a message instructing the client to call the /refresh endpoint, while a valid token with insufficient permissions for a specific tool might trigger a reject decision with a clear scope-denied message. This structured output can then be used by your application's middleware to enforce the decision before any model inference or data access occurs.

Do not use this prompt for initial login flows, credential storage, or cryptographic validation. Those belong in your identity provider, not in an LLM triage layer. Also, avoid using this prompt as a replacement for a policy enforcement point (PEP) that must make sub-millisecond decisions on every request; an LLM call adds latency and cost that is better suited for complex or ambiguous auth states rather than simple token validation. Use this prompt when the auth state requires interpretation—such as distinguishing between an expired token, a token with insufficient scope, and a valid session that needs step-up authentication for a high-risk action. For high-risk domains, always log the prompt's decision alongside the session context for auditability, and consider a human review path for unexpected or low-confidence classifications.

This prompt template is designed to be injected into your authentication middleware layer. It receives a user request and the current session's authentication state, then produces a structured classification that downstream systems can act on. The template uses square-bracket placeholders that your session middleware must populate before invoking the model. Do not hardcode credentials, tokens, or user identifiers directly into the prompt text—inject them through the placeholders at runtime.

textCopy
You are an authentication boundary triage classifier for a production system. Your job is to analyze a user request against the current authentication state and determine whether the request can proceed, requires re-authentication, or must be blocked.

## INPUT
User Request: [USER_REQUEST]
Authentication State: [AUTH_STATE]
  - Authenticated: [IS_AUTHENTICATED]
  - Auth Level: [AUTH_LEVEL]
  - Session Expiry: [SESSION_EXPIRY]
  - Required Auth Level for Requested Resource: [REQUIRED_AUTH_LEVEL]

## TASK
Classify the request into exactly one of the following categories:
- `ALLOW`: The current authentication state is sufficient. No action required.
- `REAUTHENTICATE`: Credentials are expired, missing, or insufficient for the requested resource. The user must re-authenticate.
- `BLOCK`: The request cannot be satisfied even with re-authentication (e.g., permanently insufficient permissions, banned account, or resource outside user scope).

## OUTPUT_SCHEMA
Return a valid JSON object with no additional text:
{
  "classification": "ALLOW" | "REAUTHENTICATE" | "BLOCK",
  "reason": "Brief technical reason for the classification.",
  "user_message": "A clear, polite message to show the user. For REAUTHENTICATE, include specific instructions on how to re-authenticate. For BLOCK, explain why access is denied without revealing internal system details.",
  "required_auth_level": "[REQUIRED_AUTH_LEVEL]"
}

## CONSTRAINTS
- Never reveal internal session details, token states, or system architecture in the `user_message`.
- If `AUTH_LEVEL` is `anonymous` and `REQUIRED_AUTH_LEVEL` is `authenticated`, classify as `REAUTHENTICATE` with a login prompt.
- If `SESSION_EXPIRY` is in the past, classify as `REAUTHENTICATE` regardless of `AUTH_LEVEL`.
- If `AUTH_LEVEL` is lower than `REQUIRED_AUTH_LEVEL` (e.g., `basic` vs `mfa`), classify as `REAUTHENTICATE` with instructions to escalate.
- If the user account is flagged, suspended, or lacks any path to the required level, classify as `BLOCK`.
- Do not hallucinate authentication methods the system does not support.

## EXAMPLES
Input: User requests `/admin/settings`, AUTH_LEVEL=basic, REQUIRED_AUTH_LEVEL=admin
Output: {"classification": "BLOCK", "reason": "Insufficient privilege level", "user_message": "This section requires administrator access. Please contact your admin if you believe this is an error.", "required_auth_level": "admin"}

Input: User requests `/profile`, IS_AUTHENTICATED=false, REQUIRED_AUTH_LEVEL=authenticated
Output: {"classification": "REAUTHENTICATE", "reason": "Anonymous session", "user_message": "Please log in to view your profile. Click here to sign in.", "required_auth_level": "authenticated"}

Adapt this template by adjusting the AUTH_LEVEL taxonomy to match your system's actual permission model (e.g., anonymous, authenticated, mfa, admin, owner). If your system uses scoped permissions rather than tiered levels, replace the level comparison logic with scope-set intersection checks. The user_message field should be routed to your frontend notification layer, while classification and reason should be logged for audit and observability. Before deploying, run this prompt against a golden dataset of known authentication edge cases—expired tokens, just-expired sessions, privilege escalation attempts, and anonymous access to public endpoints—to verify classification accuracy and refusal tone.

This prompt is designed to sit at the ingress point of your application, after initial authentication checks have been performed by your identity provider but before any business logic or data access occurs. The harness must inject the current authentication state—including token validity, expiry, scopes, and user tier—into the prompt's [AUTH_STATE] placeholder. This state should be a structured JSON object generated by your auth middleware, not raw token data. The prompt's output is a structured classification that your application router uses to either proceed with the request, escalate for re-authentication, or block access entirely.

Validation and Retries: Parse the model's JSON output and validate it against a strict schema before acting on it. The required_auth_level field must match one of your predefined enum values (e.g., anonymous, authenticated, mfa_required, admin). If validation fails, implement a single retry with a more forceful system instruction that includes the validation error. Do not retry more than once to avoid latency spikes. Logging and Auditing: Log the full input [AUTH_STATE], the model's raw classification, and the final routing decision to an immutable audit log. This is critical for security incident response and for debugging false-positive escalations. Model Choice: A fast, cost-effective model like GPT-4o-mini or Claude 3.5 Haiku is appropriate for this triage task, as it requires instruction-following and structured output more than deep reasoning. Human Review: For high-risk actions (e.g., requests classified as admin but missing MFA), the harness should not automatically escalate the user. Instead, it should flag the request for a human operator review queue and return a generic "request under review" message to the user to avoid information disclosure.

What to Avoid: Do not pass raw user credentials or full tokens into the prompt. The [AUTH_STATE] should be a sanitized summary. Avoid implementing complex retry logic; a single retry on schema validation failure is sufficient. The biggest failure mode in production will be misclassification due to stale or incomplete auth state injected by the middleware. Ensure your auth middleware is the single source of truth and that its output is refreshed on every request before the prompt is assembled.