Chapter 3 — Identity and Access in a World of Synthetic Faces

“Identity is the new perimeter.” — security-industry adage, attributed across the IAM field since the dissolution of the network edge

“I am the good shepherd. I know my own and my own know me.” — John 10:14 (ESV)

Why This Matters

For thirty years the security story was a wall. There was an inside and an outside, a firewall at the boundary, and the job was to keep the bad people out there and the good people in here. You administered the wall.

The wall is gone. Your users are at home, in coffee shops, on phones; your servers are in three clouds and a closet; your most sensitive data is reached by an API call from a laptop you’ve never touched. There is no edge left to defend. So the industry said the quiet part out loud: identity is the new perimeter. The thing you defend now is not a location — it is the answer to a single question asked thousands of times a second. Is this really who it claims to be, and is it allowed to do this? Every login, every token, every privileged command is that question being asked again. Identity and access management — IAM — is the discipline of answering it correctly, at scale, without slowing the business to a crawl.

And the question got harder this year than it has ever been. Both of this book’s AI threads run straight through the middle of it.

AI is the tool you wield. No human watches the authentication stream. Tens of thousands of logins a day, across time zones, from devices and service accounts and now AI agents — a person cannot triage that. So the modern shop runs the stream through machine learning. User and Entity Behavior Analytics (UEBA) learns what normal looks like for each identity and flags the deviation: the admin who suddenly logs in at 3 a.m. from a new country, the account that authenticates in Chicago and then in Lagos eleven minutes later (you cannot fly that fast — “impossible travel”), the service account that has read four files a day for a year and just read four thousand. The machine is tireless and it sees patterns you can’t. It is also confidently, expensively wrong on a schedule, and the false positive has a real cost — every alert that locks out a real user during a real deadline teaches the business to turn the alarm down. You own that tradeoff.

AI is the workload — and this week, the threat. The factor authentication has leaned on for a century is recognition. I know your voice. I recognize your face on the video call. That factor is now dead, and an administrator who doesn’t internalize that will sign a wire transfer to a criminal. In January 2024 a finance worker at the engineering firm Arup, in Hong Kong, paid out roughly US$25.6 million across about fifteen transfers — after a video conference in which every other “colleague,” including the CFO, was a real-time deepfake (reported by CNN and CFO.com). He recognized the faces. He recognized the voices. He was robbed anyway. Voice cloning now defeats caller-ID and voice-biometric “voiceprint” logins trivially; AI-written spear-phishing matches the effectiveness of a human expert; and “deepfake-as-a-service” is, as of 2026, mainstream. The synthetic face is the central fact of this chapter.

So the week’s apologetic question is not decoration — it is the engineering problem stated in older words: what does it mean to be truly known, and to guard against the impostor? The Good Shepherd of John 10 says “I know my own and my own know me” — a knowing that a synthetic face cannot counterfeit, because it is not based on appearance at all. Hold that next to Matthew 7:23 — “I never knew you; depart from me” — said to those who looked the part, did the works, used the right name, and were impostors all along. Recognition is not knowing. We are going to build authentication systems on exactly that distinction.

3.1 — Authentication vs. Authorization: The Two Questions

Beginners blur them; architects never do. They are two different questions, answered by two different systems, and most real breaches live in the gap between them.

• Authentication (AuthN) — who are you? Proving the claimed identity. Password, passkey, certificate, biometric, token. The output is an established principal: this is user dlitman.
• Authorization (AuthZ) — what are you allowed to do? Given an established identity, deciding whether this action on this resource is permitted. The output is allow or deny.

You authenticate once (or once per session); you authorize on every request. A perfect login that hands out god-rights is a catastrophe; a humble login wired to least privilege contains its own blast radius. The classic factor taxonomy still frames AuthN:

Coach’s Note — Write this on the wall: authentication is a one-time claim; authorization is a per-request decision. Ninety percent of the privilege-escalation findings you’ll ever write come from a team that authenticated carefully and then authorized carelessly — handed a correctly-identified user a role far larger than the task needed. Identity is the door. Authorization is what you’re allowed to touch once you’re inside. Guard both.

3.2 — Directories, SSO, and the Shape of Modern Identity

Identity has to live somewhere authoritative. That somewhere is a directory. On-premises, the incumbent is Active Directory (AD) — domains, the LDAP/Kerberos machinery, Group Policy. In the cloud, the authority is a cloud identity provider; in the Microsoft world that is Microsoft Entra ID (the service formerly named Azure Active Directory). Most enterprises run a hybrid: AD on the ground, Entra ID in the cloud, synchronized.

On top of the directory sits Single Sign-On (SSO): authenticate once to an identity provider (IdP), receive a token, and present it to every downstream app without re-entering credentials. The protocols you must know by name:

• SAML 2.0 — XML assertions; the workhorse of enterprise web SSO.
• OAuth 2.0 / OIDC — OAuth 2.0 is authorization (delegated access — “let this app read my calendar”); OpenID Connect layers authentication on top of it and issues an ID token. People say “OAuth login” and mean OIDC; you must not confuse the two — OAuth alone authenticates nothing.

SSO is a force multiplier in both directions. It is the user’s relief (one strong login, not forty weak ones) and the attacker’s jackpot (one stolen session, forty apps). That is why the strength of the primary authentication — and the conditional access policy gating it — is the whole game.

   ┌──────────┐   1. access app        ┌─────────────┐
   │   User   │ ─────────────────────▶ │  App (SP)   │
   └──────────┘                        └─────────────┘
        │  2. redirect to IdP                 ▲
        ▼                                     │ 5. present token
   ┌──────────────────────────┐               │
   │  Identity Provider (IdP) │ ──────────────┘
   │  Entra ID / AD FS / Okta │  3. authN (+ MFA, conditional access)
   └──────────────────────────┘  4. issue SAML assertion / OIDC ID token

3.3 — Authorization Done Right: RBAC and Least Privilege

Once you know who, you decide what. The dominant model is Role-Based Access Control (RBAC): permissions attach to roles, roles attach to identities. You don’t grant dlitman thirty individual rights; you grant the role HelpdeskTier1, and the role carries the rights. Newer shops layer ABAC (attribute-based — decisions from attributes like department, device posture, data sensitivity) for fine-grained, context-aware control. Either way, one principle governs.

Least privilege: every identity gets the minimum access required to do its job, and nothing more. Not because people are bad, but because every credential is a potential compromise, and you are sizing the blast radius before the breach, not after.

Least privilege has a time dimension too. Standing admin rights are a liability that sits there 24/7 waiting to be stolen. The modern answer is just-in-time (JIT) privileged access: you hold no standing admin role; you request elevation for a bounded window, with approval and full audit, and it expires. In the Microsoft world this is Privileged Identity Management (PIM).

And here is the 2026 wrinkle that this chapter forces onto your radar: AI agents are now identities too. An agent that reads your tickets, queries your database, and files PRs needs an identity, a credential, and a permission scope — and it is a non-human principal that never sleeps and can be hijacked by a prompt injection (you’ll meet that attack in Chapter 8 and Chapter 10). Least privilege for agents is least privilege for the most over-eager intern you have ever hired. Microsoft’s Agent 365 (GA May 1, 2026, roughly $15/user/month as of 2026) exists precisely to inventory, govern, and secure these agent identities across Entra/Defender/Intune — it can even import agents from AWS Bedrock and Google’s Gemini Enterprise into one inventory. Govern the agent as an identity, or it governs you.

Coach’s Note — When you provision an AI agent, ask the exact question you’d ask for a new hire on day one: what is the smallest set of permissions this principal needs to do its one job? An agent with broad write access plus the ability to read untrusted content plus a way to reach the internet is the “lethal trifecta” of Chapter 8 wearing a service-account badge. Scope it down before you turn it on.

3.4 — The Identity Lifecycle: Joiner, Mover, Leaver

Identity is not a moment; it is a lifecycle, and the unglamorous middle of it is where breaches hide. The discipline is JML — Joiner, Mover, Leaver:

• Joiner — provision the account, assign role-appropriate access, enroll MFA. Done badly: copy-paste another employee’s permissions (“make them like Sarah”) and silently clone Sarah’s accumulated over-access.
• Mover — someone changes departments. The cardinal sin of IAM is privilege creep: the mover gets the new role’s access and keeps the old role’s access forever. After three internal moves, an identity can touch everything — a single compromise becomes total.
• Leaver — deprovision immediately and completely. The orphaned account of a departed contractor, still active six months later, is one of the most reliable breach roots in the field.

The control that catches the rot is the access review (attestation): periodically, a manager must affirmatively confirm each report still needs each access, and stale grants are revoked. This is dull, continuous stewardship — and it is exactly the kind of high-volume drudgery where AI now assists, surfacing “this person has access nobody on their team uses” for human sign-off. The AI surfaces the candidate. The human signs the revocation. That division of labor is the spine of this entire book.

3.5 — The Synthetic Face: AI as the Threat to Authentication

Now the hard turn. Everything above assumes the factors mean something. AI is busy emptying two of them.

Deepfake video. Real-time face-and-voice synthesis is good enough, as of 2026, to populate a live video call with fake colleagues. The Arup case is the one to know cold: ~US$25.6M paid out across ~15 transfers, authorized by an employee who joined a video call full of deepfaked coworkers — including a fake CFO — and recognized every one of them. (CNN; CFO.com.) The defense is not a better camera. It is a process that does not treat “I recognized them” as authentication at all.

Voice cloning. A few seconds of audio — a conference talk, a voicemail, a podcast — is enough to clone a voice convincingly. This defeats caller-ID-plus-voice as an authentication scheme outright. Any bank, helpdesk, or wire-approval flow that authenticates a human by “they sounded like the boss and called from his number” is, in 2026, already compromised; it just hasn’t been billed yet.

Synthetic identities. AI fabricates whole personas — generated faces (the people don’t exist), fabricated histories, documents — to pass onboarding KYC and create fraudulent accounts at scale. The joiner pipeline of §3.4 is now under machine-speed attack.

AI-crafted spear-phishing. The grammatically-broken phishing email is a museum piece. AI writes fluent, context-aware, individually-targeted lures, in volume, that match human-expert effectiveness — feeding the credential-theft that SSO then amplifies.

The lesson is brutal and clarifying: inherence has collapsed as a remote factor. “Something you are,” delivered down a wire the attacker can synthesize, proves nothing. Which is why the next two sections matter more than they did three years ago.

Coach’s Note — Burn this in: “I recognized the voice / I recognized the face” is no longer an authentication factor. It is a feeling. The entire defense against deepfake fraud is to replace that feeling with a procedure the attacker cannot fake: an out-of-band callback to a known number, a shared code word, dual approval for any wire above a threshold. Don’t argue with a deepfake. Hang up and call back on a number you already trust.

3.6 — Phishing-Resistant Auth: FIDO2 and Passkeys

If recognition is dead and SMS codes are phishable, what’s left that an attacker on the wire cannot replay? Public-key authentication bound to the origin — FIDO2 / WebAuthn, the technology behind passkeys.

The mechanics, briefly: at registration, your device (a security key, your phone, your laptop’s TPM) generates a key pair, keeps the private key locked in hardware, and hands the public key to the service. To log in, the service sends a random challenge; your device signs it with the private key, and the signature is cryptographically bound to the website’s origin. Two consequences make this the gold standard:

1. The private key never leaves the device and is never transmitted. There is no shared secret to phish, breach, or replay.
2. Origin binding kills the phishing site. A passkey registered for bank.com will not sign a challenge from bank-secure-login.com. The user can be fooled by the fake page; the cryptography cannot. This is the property SMS, TOTP, and push notifications lack — those are all “shared secret entered by a human,” and a human can be tricked into entering them on the wrong site (or fatigued into approving a push they didn’t initiate — MFA fatigue).

The administrator’s job is not “turn on MFA.” It is “drive the org toward phishing-resistant MFA” — passkeys and FIDO2 keys for every privileged account first, then everyone — and to recognize that not all MFA is equal. A shop that checked the “MFA enabled” box with SMS has bought far less safety than its compliance report claims.

3.7 — AI as the Tool: UEBA and Anomaly Detection

Now the defensive AI thread, in full. You cannot watch the authentication stream by hand, so you teach a machine the shape of normal and let it flag strange. This is UEBA — User and Entity Behavior Analytics — and as of 2026 it has moved from static thresholds to deep-learning, per-identity and per-device baselines that flag anomalous sequences of actions, not just single bad events.

What it catches, and the simple math underneath:

• Impossible travel — two authentications too far apart in space for the time between them. The detector is geometry, not magic: if distance(geo₁, geo₂) / hours_between > ~900 km/h, no commercial flight covers it; flag it.
• Off-hours privileged access — an admin account active at 3 a.m. when its yearlong baseline is 9-to-5.
• Brute-force / password-spray — many failures across many accounts from one source, or one account hammered.
• Privilege escalation & lateral movement — an identity that suddenly assumes roles, accesses systems, or reads volumes far outside its learned pattern — the signature of an attacker after the initial compromise.

A classic, transparent way to score the simplest case is a z-score: how many standard deviations is today’s behavior from this identity’s own baseline? If dlitman reads ~20 files a day (σ ≈ 5) and today reads 400, that’s z = (400 − 20) / 5 = 76 — not a blip, a flare. Tree-based methods like isolation forest generalize this to many dimensions at once. Vendor platforms wrap this for ops at scale — Datadog Watchdog’s ML anomaly engine, BigPanda and PagerDuty AIOps for correlation, and on the security side Microsoft Security Copilot as an analyst-assist layer. A 2026 theme worth naming: UEBA is being extended to AI agents themselves as non-human identities — the same anomaly math, pointed at your service principals.

A worked example you can read in the starter logs:

# Flag any user whose successful logins span an impossible-travel gap.
# Input: auth.log (ts,user,event,result,country,ip,lat,lon) — see code/auth_events.csv
python3 code/impossible_travel.py code/auth_events.csv --threshold-kmh 900
# → ALERT  user=mcompton  Chicago->Lagos  gap=11min  implied=52404 km/h  (>900)

See code/impossible_travel.py and code/auth_events.csv. Run it before you read this section twice.

3.8 — The False-Positive Tax (and Why It’s a Judgment Call, Not a Knob)

Here is where the senior administrator earns the title. The detector of §3.7 has a dial, and every position on it costs you something.

Turn sensitivity up, and you catch more real attacks — and bury your analysts in false alarms. The traveling VP, the on-call engineer paged at 3 a.m., the batch job that runs once a quarter — all flagged, all triaged, all fine. Cry wolf often enough and the business does the rational thing: it stops listening. Alert fatigue is not a personal failing; it is the predictable consequence of a badly tuned detector, and it is how the real intrusion sails through unread. Turn sensitivity down to keep the queue sane, and you raise your false-negative rate — you miss the actual breach. There is no setting that is free.

The mature answer is risk-based / step-up authentication: don’t binary-block on a single anomaly — raise the cost of being wrong. A mildly unusual login doesn’t get denied; it gets challenged for a passkey tap. High risk plus high-value action gets blocked and reviewed. You are buying down false-negative risk without paying the full false-positive tax, by making the response proportional to the confidence. No model picks that proportion for you. You decide what an anomaly costs — a locked-out surgeon mid-shift versus a leaked patient database — and tune accordingly. That is judgment, and it is precisely the thing this book refuses to hand to the machine.

Coach’s Note — When a vendor demos “99.9% detection accuracy,” ask the only question that matters: at what false-positive rate, on what base rate? On a stream where genuine attacks are one in a million, a 99.9%-accurate detector firing on every 0.1% still drowns you in a thousand false alarms for every real one. Accuracy is the marketing number. Precision at your base rate is the operational one. Make them show you that.

3.x — Interactive Lab: Auth Anomaly Explorer

Below this chapter on the site is an interactive panel called the Auth Anomaly Explorer. Open it now and put §3.7 and §3.8 under your hands.

The Explorer streams a window of authentication events at you — logins, MFA challenges, privileged actions — each with a user, a timestamp, a location, an IP, and a result. Your job is the analyst’s job: flag the suspicious ones. Hidden in the normal traffic are the patterns you just learned — an impossible-travel pair, an off-hours admin session, a brute-force / password-spray burst, and a privilege-escalation sequence where an ordinary account suddenly assumes rights it has never held. Click the events you believe are hostile; the Explorer scores your flags against ground truth and shows you what you caught, what you missed (false negatives), and what you cried wolf on (false positives).

That last column is the whole lesson. Run it once aggressively — flag everything that looks even slightly odd — and watch your false-positive count explode; that is the analyst’s drowned inbox from §3.8 made visible. Then run it again with restraint and watch a real attack slip past as a false negative. Somewhere between the two is the tuning a human has to choose, and the Explorer lets you feel the tradeoff instead of just reading about it. Do at least three passes, and write down the precision/recall you’d actually ship if every false positive locked out a real user mid-deadline. Bring that number to the project.

3.9 — The Shepherd and the Impostor

The week’s question is what does it mean to be truly known — and to guard against the impostor? This chapter has been one long answer to it, told in protocols.

Notice what failed. The faces failed. The voices failed. The man at Arup recognized everyone in the room and was robbed precisely because recognition — appearance, familiarity, the feeling of “I know this person” — turned out to be the weakest factor of all, the one a synthetic face counterfeits perfectly. Authentication built on seeming collapses the moment seeming can be manufactured.

The Good Shepherd says something stranger and stronger: “I know my own and my own know me” (John 10:14, ESV). It is a knowing that does not run on appearance. Set it against Matthew 7:23 — “I never knew you; depart from me” — spoken to people who had the right name on their lips and impressive works in their hands and were impostors all along. They looked like His own. They were not known. Scripture draws the exact line this chapter draws in silicon: likeness is not identity, and recognition is not knowing. The impostor’s whole craft is to look the part, and the shepherd’s whole defense is a knowing that looks past the part to the thing the part cannot fake.

That is not a sermon bolted onto a security lecture; it is the engineering principle in older and more honest words. The phishing-resistant passkey of §3.6 works because it refuses to authenticate on appearance — it does not care that the page looks like bank.com; it answers only to the cryptographic origin it was bound to, the way the shepherd answers only to the sheep that are actually his. The out-of-band callback of §3.5 works for the same reason: it relocates the proof from “they seem like the CFO” to a channel the impostor cannot inhabit. Good IAM is, in the end, the engineering of true knowing in a world of convincing seeming — and there is an older Name for the one who is never deceived by the convincing seeming, who knows His own and is not robbed.

Your vocation as an administrator is a small, faithful echo of that. You stand at the gate (the watchman of Chapter 5, the steward of Chapter 1) and you guard a flock that is not yours, against an enemy whose entire art is disguise. Build systems that know their own by something deeper than appearance — and never, ever let the machine’s confident “I recognize this” stand in for the knowing only you are accountable for.

3.10 — Common Pitfalls

Pitfall: Treating all MFA as equal — checking the “MFA enabled” compliance box with SMS. Example: A shop enforces SMS one-time codes and reports “100% MFA coverage,” then loses an executive account to a SIM-swap plus a real-time phishing relay that captured the code. Fix: Classify MFA by phishing-resistance. Drive privileged accounts to FIDO2 / passkeys first; treat SMS as a deprecated fallback, not a control you rely on.

Pitfall: Authenticating well and authorizing carelessly — strong login, god-mode role. Example: Every new hire is provisioned by cloning a senior admin’s permissions (“make them like Sarah”), silently inheriting standing Domain Admin nobody audits. Fix: Role-based provisioning to the minimum role, just-in-time elevation (PIM) for admin actions, and quarterly access reviews to revoke creep.

Pitfall: Believing a recognized face or voice on a video/phone call is authentication. Example: Finance approves a wire because the CFO appeared on the call and “sounded exactly like himself” — see Arup, ~US$25.6M. Fix: Out-of-band verification for high-value actions: callback to a known number, a shared code word, and dual approval above a dollar threshold. “I recognized them” is never the control.

Pitfall: Cranking anomaly-detection sensitivity to maximum because “we can’t afford to miss anything.” Example: The SOC gets 4,000 alerts a day, 99% benign; analysts mute the channel; the one real lateral-movement alert dies unread in the noise. Fix: Tune to precision at your base rate, use risk-based step-up (challenge, don’t block, on low-confidence anomalies), and measure analyst alert load as a first-class metric.

Pitfall: Forgetting the Leaver — orphaned accounts that outlive the human. Example: A contractor’s account stays active and over-permissioned six months after the engagement ended; it becomes the breach root. Fix: Automated deprovisioning wired to the HR/identity source of truth (immediate disable on offboarding), plus periodic orphaned-account sweeps.

Pitfall: Standing up an AI agent without treating it as a governed identity. Example: An ops “assistant” agent is given a broad service-account token with write access and internet reach; an indirect prompt injection turns it into an exfiltration tool. Fix: Provision agents under least privilege with scoped, short-lived credentials; inventory and monitor them as non-human identities (e.g., Agent 365-class governance); apply UEBA to their behavior too.

3.11 — Reps

The reps for this week are in the exercises. The keyboard is the gym — reading about impossible travel is not the same as computing it. A preview:

• Rep 1 — Compute an impossible-travel velocity by hand from two log lines, then verify against code/impossible_travel.py. Predict before you measure.
• Rep 3 — Classify a mixed pile of MFA methods by phishing-resistance and justify each call.
• Rep 5 — Compute a z-score anomaly score for a file-access burst and decide whether you’d page on it.
• Rep 8 — Trace the Arup deepfake fraud and design the out-of-band process that stops it cold.
• Rep 10 — Build a precision/recall confusion matrix from your Auth Anomaly Explorer run and defend a tuning choice.

AI policy for the reps (Phase 1): you do each by hand first, then — where a rep says so — you may bring AI in to interpret a log or draft a policy, and your job is to critique it. Note where the AI was confidently wrong. Every rep ends with a one-line honest “AI usage” note. The human owns the verdict. A short Check Your Reps quiz is embedded on this page — take it before you move on.

3.12 — This Week’s Project

Your project is P3 — Catch the Impostor, specified in Project 3.

You’ll build an anomaly-detection pipeline over a realistic authentication log: parse the events, implement impossible-travel and off-hours/brute-force/privilege-escalation detectors, and tune them against a labeled ground truth so you can report real precision and recall — not a vibe. The Normal tier gets the detectors working and scored. Medium adds risk-based step-up logic (challenge vs. block vs. allow) and an honest false-positive analysis. Hard is the judgment the machine can’t make: a one-page memo to a CISO recommending where to set the sensitivity for a named organization with named stakes — a hospital at 3 a.m. versus a trading desk — and a deepfake-fraud playbook with the out-of-band controls that would have stopped Arup. The code is the craft; the memo is the architecture, and it’s where the human-in-the-loop thesis gets graded.

3.13 — Coach’s Final Word for Week 3

This week the perimeter finished dissolving and identity took its place as the thing you defend. You separated the two questions — who are you (authenticate once) and what may you do (authorize every time) — and learned that most breaches live in the gap. You met the directory, SSO, RBAC, least privilege, just-in-time access, and the joiner-mover-leaver lifecycle where privilege quietly creeps. Then you watched AI come at authentication from both sides: as the threat that killed recognition — deepfakes, voice clones, synthetic identities, fluent phishing — and as the tool, UEBA and anomaly detection that watch a stream no human can, at the price of a false-positive tax that only your judgment can set.

The throughline is one sentence: inherence collapsed as a remote factor, so we moved the proof to something the impostor cannot synthesize — an origin-bound passkey, an out-of-band callback, a knowing that doesn’t run on appearance. Recognition is dead; cryptographic and procedural knowing is what’s left, and it’s stronger.

The man at Arup recognized every face in the room and lost twenty-five million dollars to faces. The Good Shepherd knows His own by something no synthetic face can counterfeit, and says to the convincing impostor with the right name on his lips, “I never knew you.” Build authentication on that distinction — likeness is not identity, recognition is not knowing — and you will not be robbed by a face. Guard the flock that isn’t yours against an enemy whose whole art is disguise. That is the vocation. Now go do the reps until impossible travel is arithmetic you do in your head.

See you next week.

Up next: Read the exercises and complete every rep, then open Project 3 and catch the impostor. Use the Auth Anomaly Explorer on this page, and see Appendix A for the lab environment, Appendix B for running a local or cloud AI to assist your log triage, and Appendix C for the rules on letting an agent touch identity systems. After that, Chapter 4 — storage administration and the weight of data, where the logs you triaged this week become an estate you must size, govern, and keep.

Previously: Chapter 2 — the operating system underneath, where you learned to read the process table and the kernel log the same way you learned to read the auth stream here.