179 questions
No questions match those filters.
How should authentication and authorization work when a...
This is one of the questions in the full AI/ML interview bank. Pro unlocks all 1789 questions; Premium includes the same bank plus the highest daily Practice limit.
See plansAuthentication and authorization in MCP aren’t one problem — they’re three, and each needs a different mechanism.
- API key — the simplest option, passed with the request. It’s appropriate for a tool the agent itself owns outright (an internal search index, say), and wrong for any tool that reaches into a specific user’s private data, because a key by itself carries no notion of whose data is being accessed.
- OAuth 2.0 with user-delegated scopes — the right mechanism whenever a tool acts on a specific person’s account: reading their Gmail, writing to their Drive, updating their CRM record. The token is scoped to that user specifically and expires, rather than handing the agent standing, undifferentiated access to every user’s data at once.
- mTLS or a cloud-native service identity (a GCP service account, an AWS IAM role) — fits agent-to-agent or agent-to-infrastructure calls, where there’s no individual human to delegate on behalf of and the agent is really acting as its own principal.
Authorization on top of authentication follows least privilege: a research agent gets read-only access to a knowledge base; a billing agent gets read access to customer data plus create-invoice, not full account access; anything higher-risk requires additional human-in-the-loop approval regardless of which auth mechanism granted the base access.
Where this actually breaks in production is cross-tenant isolation. When one agent process serves many users, every tool call made “on behalf of User A” has to carry and validate a token scoped specifically to User A — never a shared service credential that happens to have broad access. Without that per-call validation, a bug, a race condition, or an injected instruction can reach into another tenant’s data purely because both users’ requests are being served by the same underlying agent instance. This is precisely the failure mode behind real cross-tenant MCP breaches, not a hypothetical edge case.