Katkat
Back

Design a Secure Copilot API

MicrosoftSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question evaluates proficiency in designing secure, multi-tenant API systems with emphasis on authentication and authorization models, token lifecycle management, threat mitigation (such as replay attacks, token theft, and misuse), access control across tenants and tools, and scalability and reliability concerns.

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.

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?

Hints

Hint 1

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 2

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 3

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 4

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).

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?