Is this a video course?

No. This is an interactive, slide-based learning platform. Each lesson has rich text, animated diagrams, live code editors, and quizzes. You learn by reading, interacting, and doing, not by watching videos passively.

How long do I have access?

Forever. Both pricing tiers are one-time payments with lifetime access. This includes all current 766 lessons and any future content we add.

What level of experience do I need?

None. We start from absolute basics like 'What is latency?' and build up to distributed consensus protocols. The Foundation level assumes zero prior knowledge of system design.

How much does the system design course cost?

7.99 US dollars for lifetime access globally, or 499 Indian rupees for lifetime access in India. One-time payment, no subscription, no hidden fees. 11 lessons are free with no signup required.

What technologies are covered?

Everything from DNS and load balancers to Kubernetes, Kafka, distributed databases, consensus protocols, stream processing, security architecture, and observability. We cover principles and real-world implementations used at Netflix, Google, Amazon, Uber, Stripe, and more.

Is this useful for system design interview preparation?

Yes. The lessons are structured around the exact topics asked in system design interviews at FAANG and top-tier companies. Interactive diagrams help you practice whiteboard-style explanations. Covers everything from URL shortener design to distributed payment systems.

How is this different from ByteByteGo or Educative?

766 interactive lessons (4x more than most competitors), 16 different diagram types that build step by step, real production examples from Netflix, Google, Amazon, Uber, and Stripe, and lifetime access for a one-time payment of $7.99 instead of annual subscriptions costing 100 to 200 dollars per year.

When an agent acts, whose authority does it use?

It should act with the requesting user's authority, narrowed to the task in front of it, and never with authority of its own. Most first versions hand the agent one broad service key that becomes its standing authority, which means a single poisoned input runs with admin power instead of the narrow power of the person who asked.

What is the difference between authentication and authorization for an agent?

Authentication asks who is making the call and authorization asks what that caller is allowed to do, and proving a request came from a real user says nothing about whether its action is permitted. For an agent the right authority is the intersection of what the user may do and what the task needs, never the agent's own standing power.

How does OAuth 2.0 Token Exchange help secure agents?

OAuth 2.0 Token Exchange, defined in RFC 8693, lets the agent trade the user's token for a fresh, short-lived token scoped to just the current task, recording the user as the subject claim and the agent as the actor claim. It narrows authority instead of forwarding a full session, so a leaked token grants one scope on one resource, briefly. Microsoft Entra ID ships this as its on-behalf-of flow.

What is the aud claim and why does it matter for agents?

The audience claim names the exact resource a token was minted for. The client requests it with the resource parameter of RFC 8707, the authorization server stamps it into the token, and RFC 9068 requires each resource server to reject any token whose audience is not an identifier it accepts for itself. Because agents fan out across many services, audience binding stops a token leaked from one call from being replayed against another.

What is token passthrough and how is it a confused deputy?

Token passthrough is when a proxy forwards a token minted for one API straight to a second API. If the second service does not validate the audience, it accepts a credential that was never issued for it, so any component that can reach it can spend the wrong token. The fix is to perform a token exchange at each boundary that re-audiences the credential for the next hop, plus an audience check that fails closed.

What is the difference between delegation and impersonation?

RFC 8693 distinguishes them by whether the agent stays in the record. Delegation keeps both the user as subject and the agent as actor, so every downstream log can name the agent that acted and the user it acted for. Impersonation records only the user, so the token is indistinguishable from one the user minted themselves and an investigation cannot separate a real human action from an injected one. Prefer delegation for agents.

How do you stop one tenant reading another tenant's data in a multi-tenant agent?

You derive the tenant identifier from the verified token on the server, never from the request body or content the agent processes, so an injected instruction cannot point it at another tenant. In production you push this down to the database with row-level security keyed on the verified tenant, so even a query with a forgotten filter cannot cross the line.

How do you give an identity to an agent that has no user?

You issue a short-lived workload identity that the platform attests and services verify, such as a SPIFFE SVID from SPIRE or a cloud workload identity like AWS IRSA, GCP Workload Identity Federation, or Azure managed identities, instead of a shared secret in an environment variable. The identity auto-rotates and is carried between services over mutual TLS, so there is no standing password to steal.

An agent authenticates to the backend with a single admin-scoped service key so it works for any user. Why is this the core identity risk?

The agent acts with its own broad authority rather than the requesting user's narrow authority, so a single injected instruction runs with admin power over every tenant, Authentication succeeds, but the authority is wrong. The agent acts as itself with broad, ambient admin scope instead of as the user with narrow scope. Because the agent reads untrusted content every turn, an injected instruction inherits that admin power, and the blast radius is the whole backend for every customer rather than one user's own data.

What does OAuth 2.0 Token Exchange (RFC 8693) let an agent do that forwarding the user's token does not?

Trade the user's token for a fresh, short-lived token scoped to just the current task, recording both the user as the subject claim and the agent as the actor claim, Token exchange narrows authority instead of copying it. The agent exchanges the user's token for a new one with only the scope the task needs, a short expiry, and an audience pinned to the target resource. The minted token names both the user as subject and the agent as actor. Forwarding the raw user token hands over the full session with every scope, for as long as it is valid.

A token minted for the tickets API is leaked and replayed against the billing API. What single control makes the billing API reject it even though the token is still unexpired?

The billing API validates that the token's aud claim names the billing API, and it does not, The audience claim pins a token to one resource. The client requests it with the RFC 8707 resource parameter, the authorization server stamps it in, and RFC 9068 requires each resource server to reject any token whose aud is not an identifier it accepts for itself. A ticket-service token simply does not fit the billing service, valid or not.

A gateway forwards a user's token, minted for API A, unchanged to API B, and B accepts it because it does not check the audience. What is this, and what is the fix?

A confused deputy via token passthrough; fix it by exchanging the token at the boundary so it is re-audienced for B, and having B validate its own aud, Passthrough forwards a credential to a service it was never issued for, so any component that can reach B can spend A's token. The fix is token exchange at each hop, which re-audiences the credential for the next service, plus an aud check at B that fails closed. This is the token-passthrough variant of the confused deputy that the tool and sandbox lesson deferred to this lesson.

An autonomous agent runs as a scheduled job with no user to delegate from. What is the right way to give it an identity to call other services?

Issue a short-lived workload identity, a SPIFFE SVID from SPIRE or a cloud workload identity, that the platform attests and that services verify over mutual TLS, A workload with no user still needs a verifiable identity, and a shared secret in an env var never rotates and leaks easily. SPIFFE and SPIRE attest the workload and issue a short-lived, auto-rotating SVID, verified over mTLS. AWS IAM Roles for Service Accounts, GCP Workload Identity Federation, and Azure managed identities are the cloud equivalents. No standing secret is stored anywhere.

Agent Identity and Authorization: Whose Authority Is It?

Name: System Design Masterclass
Availability: InStock

in Security

This lesson is part of the AI Engineering course. Unlock the full course, a separate one-time payment, for lifetime access.

One-time payment. Lifetime access. No subscription.

Global

$20/lifetime

One-time payment via PayPal

Get Lifetime Access

5 Foundation lessons free, try before you buy

India Special

India

₹999/lifetime

One-time via UPI, cards, or net banking

Get Lifetime Access

5 Foundation lessons free, try before you buy

“The interactive diagrams alone are worth way more than the price.”

Anish K., Senior Engineer at a Bengaluru startup

Every ML Platform lesson, Foundation to Advanced

Real architecture diagrams with real tool logos

MLOps, LLMOps, and data engineering in depth

Quizzes with instant feedback

Built and reviewed by senior engineers

Lifetime access, all future content included

The first 5 Foundation lessons of this course are free, no payment needed. Try them now