Design a **secure API for an enterprise AI copilot product**. The product serves many independent organizations (tenants). Authenticated end users send prompts, retrieve model responses, and may optionally invoke organization-specific tools or retrieve from tenant-private knowledge sources. The interviewer is explicitly focused on **security** — treat the API design, authentication, authorization, token lifecycle, abuse prevention, and the security/reliability concerns that emerge at scale as the core of the conversation, not an afterthought. Walk through the design end to end: - The high-level API surface and the main components behind it. - How **users** and **internal services** should authenticate. - How **authorization** works across tenants, users, tools, and retrieved documents. - How access tokens are **issued, signed, validated, rotated, and revoked**. - How to prevent misuse: prompt/tool abuse, token theft, replay attacks, excessive usage and cost blow-ups, and cross-tenant data leakage. - What additional **security and reliability** concerns appear once the system handles a very large request volume across regions. Your design should deliver normal product functionality while being **secure by default** — least privilege, strong tenant isolation, and fail-closed behavior. ```hint Where to start Lead with a **threat model**, not endpoints. Name the assets (tenant data, tools, signing keys), the adversaries (stolen token, malicious tenant, prompt-injected model), and the trust boundaries — then let that drive every later decision. ``` ```hint Tenant identity is the spine The single most important invariant: tenant identity flows from **trusted token claims**, never from a user-controlled request field, and is re-checked at **every** downstream hop (retrieval, tools, storage). Think about how you propagate and re-verify it rather than trusting the gateway once. ``` ```hint Token lifecycle trade-off The hard part of "issue / sign / validate / rotate / revoke" is the tension between **stateless local validation** (JWT + JWKS, scales) and **instant revocation** (opaque token + introspection, or a `jti` denylist). Reach for short TTLs + asymmetric signing + a `kid`-keyed JWKS, and have an answer for the revocation gap. ``` ```hint Misuse is multi-layer Separate the categories: **identity** misuse (token theft/replay → DPoP/PoP, short TTL, replay nonce), **volume** misuse (rate limits, per-tenant quotas, cost caps), and **content/tool** misuse (tool allowlists, sandboxing, SSRF defense, prompt-injection handling for untrusted retrieved text). ``` ### Constraints & Assumptions - **Multi-tenant**: many organizations share the platform; strict isolation between them is a hard requirement. - **Interactive latency**: chat is user-facing, so per-request auth/policy checks must be cheap (favor local/cached validation over a synchronous central call on the hot path). - **Enterprise identity**: tenants bring their own IdPs (SSO via OIDC/SAML); you do not own the user directory. - **Privileged side effects**: tools may take real actions (deploys, data writes, external calls), so tool invocation is more sensitive than chat. - **Compliance & auditability**: enterprise customers expect tamper-resistant audit logs and data-handling controls (retention, training opt-out, residency). - Assume cloud infrastructure with a managed KMS/HSM, a service mesh or workload identity, and a distributed cache (e.g. Redis) are available. ### Clarifying Questions to Ask - What identity providers must we federate with, and is it OIDC, SAML, or both? Do we need per-tenant IdP configuration? - Are tools/connectors first-party only, or can tenants register their own (which widens the SSRF/sandboxing surface)? - What are the data-residency and retention requirements — can prompts/outputs be logged or used for training, and must data stay in-region? - What is the expected scale (requests/sec, tenants, regions), and is there a latency SLO for the chat endpoint? - Is there a single shared model backend, or do some compliance-sensitive tenants require isolated deployments? - Who are the privileged personas (tenant admin, platform operator, auditor) and what can each do? ### What a Strong Answer Covers - **Threat model first**: explicitly enumerates assets, adversaries, and trust boundaries before drawing boxes, and ties later choices back to them. - **Clean component decomposition**: client → gateway/WAF → authN → policy/authZ engine → orchestrator → tenant-scoped retrieval → sandboxed tool layer → model gateway, plus audit and key-management as first-class components. - **AuthN done right**: OIDC/OAuth2 SSO with short-lived user tokens; mTLS / workload identity (not static API keys) for service-to-service. - **Layered authZ**: RBAC for coarse roles + ABAC/scopes for tenant, classification, region, and tool sensitivity; tenant membership and tool permission checked **per request**, retrieval tenant- and document-scoped. - **Full token lifecycle**: claim set, asymmetric signing in KMS/HSM, `kid` + JWKS distribution, local validation of signature/iss/aud/exp/nbf/tenant/scope, overlapping-key rotation, and a credible revocation story (short TTL + refresh revocation + `jti` denylist). - **Misuse prevention across layers**: rate limits/quotas/cost caps, replay and token-theft defenses (DPoP/PoP, nonce), tool allowlists + sandboxing + SSRF/RCE defense, prompt-injection handling, and tenant-isolation/data-leakage controls (row/document-level access, log redaction, encryption). - **Scale & reliability**: stateless cached token validation, distributed tenant-aware rate limiting, cached-but-correctly-invalidated policy decisions, multi-region routing/key replication, observability of security signals, and **fail-closed** defaults on auth/policy failure. - **Explicit trade-offs**: JWT vs opaque token, centralized vs cached authZ, shared vs isolated model deployments. ### Follow-up Questions - A user's token is stolen and replayed from a new IP within its TTL. Walk through exactly which of your controls detect, contain, and revoke it, and how big the exposure window is. - The central policy engine has a latency spike during peak traffic. How do you keep chat available without weakening authorization, and how do you avoid serving a stale "allow" after a permission was revoked? - A tenant's retrieved document contains injected instructions telling the model to call a deployment tool and exfiltrate another tenant's data. Which boundaries stop this, and which are the model's responsibility vs the platform's? - A compliance-sensitive customer demands their data never share infrastructure with other tenants and never leave their region. How does your design accommodate that, and what does it cost you operationally?