Class 13 taught you to send a request and read a response. Now comes the question every service asks before it answers: who is calling, and are they allowed to do this? Get this distinction right and the rest of Class 14 — keys, OAuth, agent boundaries — falls into place.

Think of an office building. Your badge photo says who you are. The magnetic strip decides which doors open. Losing your badge is one problem. Having a badge that opens the server room, the safe, and the CEO's office when you only clean the lobby is a different, larger problem. Software works the same way.

Authentication answers "who are you?"

Authentication (authN) is the identity check. The service verifies that the caller is who they claim to be — a logged-in person, a registered app, a server holding a valid credential.

Familiar examples: typing a password, approving a phone prompt, presenting an API key with a request. In each case the service is asking one question: can you prove your identity?

Authorization answers "what may you do?"

Authorization (authZ) happens after identity is established. Now the service checks permissions: given who you are, which data and actions are allowed?

This is where roles and scopes live. A role is a named bundle of permissions — "viewer," "editor," "billing admin." A scope is a narrower named permission — "read calendar," "publish post," "list invoices." The rule that ties them together is least privilege: give each identity only the permissions its job requires, nothing more.

Least privilege is not paranoia. It is damage control. Every permission you grant is a mistake an agent — or an attacker holding a leaked credential — can make on your behalf.

401 means "I don't know you." 403 means "not for you."

You met these status codes in Class 13. Now they carry their full meaning:

A 401 sends you to the key drawer. A 403 sends you to the permission list. Confusing the two wastes hours — developers retry a valid-but-underpowered credential as if it were broken, or "fix" a permission problem by generating ever more keys.

Two kinds of identity: people and machines

A user identity belongs to a person: you signing into Google, approving a consent screen, clicking "Connect Calendar." It carries human context — consent, revocability, an account that can complain.

A machine identity belongs to software: a server, a deployment, or your coding agent presenting an API key or token. It has no judgment. It uses exactly what it was given, at machine speed, as many times as it is asked.

This is why agents deserve special care. A person with excessive access makes one mistake at a time. An agent with excessive access makes them in a loop, at 3 a.m., without noticing. The calendar example makes this concrete.

The calendar agent: read is not delete is not billing

Imagine you give an agent access to your calendar to "help with scheduling":

• Read events lets it find free time and summarize your week. Low risk, exactly what the job needs.
• Create and edit events lets it book meetings for you. Useful — but now a confused prompt can double-book clients or spam attendees.
• Delete all events lets it wipe years of history in one call. Almost never needed for scheduling help.
• Change billing or sharing settings has nothing to do with scheduling at all. There is no reason a scheduling agent should hold it.

Same identity, four different authorizations, four different blast radii. The beginner move is to grant everything "so it just works." The builder move is to start with read-only, confirm the agent behaves, then widen one scope at a time.

Who are you? (authentication)        What may you do? (authorization)
─────────────────────────────        ─────────────────────────────────
Badge photo / login / API key   →    Which doors open / role / scopes
Proven once per session         →    Checked on every single request
401 when it fails                →    403 when it fails

Practical exercise: draw three small permission maps

Finish line: a half-page note listing three agents, each with allowed permissions and one explicitly denied permission.

1. Research assistant. It reads public filings and summarizes them. Give it: read access to one data source, permission to write draft files in one folder. Explicitly deny: permission to send email, publish, or spend money. 2. Customer-support draft assistant. It drafts replies for human review. Give it: read access to the ticket queue, permission to save drafts. Explicitly deny: permission to send replies directly or refund orders. 3. Deployment helper. It inspects preview builds. Give it: read access to deployment logs and preview URLs. Explicitly deny: permission to promote to production or change environment variables.

Verify: for each agent, ask "if this credential leaked today, what is the worst one automated call could do?" If the answer frightens you, narrow a scope. Common failure mode: granting "editor" or "admin" because it was the default — defaults serve the vendor's onboarding, not your risk.

Check your understanding

1. In one sentence each, what do authentication and authorization establish? 2. You call an API and get 401. What do you check first? What about 403? 3. What is the difference between a user identity and a machine identity, and why does it matter for agents? 4. What do roles and scopes each describe, and what does least privilege require? 5. Your scheduling agent only needs to find free time. Which calendar scope does it need, and which two should it not have?

Toward the machine's password

Identity and permission are the ideas. API keys are the mechanism most beginners meet first: the machine's password, stored in the environment, capable of spending money and reading private data. Lesson 14.2 shows how to hold one safely — and what to do when one escapes.