Machine and Agent Identity
Last reviewed
AdvancedWhat you'll learn
~20 min- Apply the assert-don't-store rule to every workload connection
- Stand up OAuth/SaaS-integration governance - the lesson of the 2025 token-theft wave
- Govern AI agents as first-class identities: owner, scopes, lifecycle, audit
The census nobody runs
Count Meridian’s identities honestly: ~1,400 humans — and several thousand machines. Pipelines, service accounts, app registrations, OAuth grants, scheduled jobs, and now AI agents. Modules’ worth of effort hardens the human 30%; in most estates the machine 70% still authenticates like it’s 2019: long-lived secrets in config, tokens that never expire, integrations nobody inventoried. Zero Trust that stops at humans isn’t Zero Trust; it’s a hardened front door on a house with no back wall.
The rule, and where it’s already taught
The governing principle for every machine connection: identity is asserted and verified, never stored and presented. Pipelines federate via OIDC (the CI run proves “repo X, branch main” and exchanges that claim for minutes-lived credentials — nothing stored, nothing to steal); apps reach databases and vaults through managed identities; cluster workloads get platform-issued identities. If you took the Cloud Modernization training, its Machine Identity lesson builds that migration end-to-end — inventory, federate, revoke-at-the-provider, guard against regression — and this lesson won’t re-teach it. Here we take the rule to the two frontiers it hadn’t covered: third-party grants, and agents.
Frontier one: the OAuth grants you forgot you made
The marquee identity breach of the AI era — the Salesloft Drift incident, August 2025 — involved no phishing and no malware: attackers stole OAuth tokens from one SaaS chatbot integration and used them to walk into seven hundred+ organizations’ CRM tenants, harvesting the credentials people had pasted into support tickets. Every victim had MFA. None of it mattered — the tokens were already on the inside of it, delegated months earlier to a vendor whose compromise nobody’s threat model included.
The governance that closes this class of hole:
Audit every OAuth/SaaS integration in this tenant:1. INVENTORY: all app registrations + consented grants - vendor, scopes, consent date, consenting user, last token use2. RANK by blast radius: write scopes > broad read > narrow read; flag anything with directory-wide or mail/files read3. KILL: unused 90+ days => revoke; consented-by-departed-employee => review4. GATE the future: user consent OFF for unverified apps; admin-consent workflow with scope justification (a one-line reason per scope, and a "NOT requested" section for broader scopes considered and rejected)5. SHORTEN: token lifetimes and refresh policies per app tier6. BAN secrets-in-tickets: DLP rule + the support-workflow fix it forcesThe “NOT requested” section in step 4 is a small pattern with outsized value (it comes from a real least-privilege runbook): forcing every integration request to name the broader scopes it declined turns scope-minimization from a review argument into a habit.
Frontier two: agents are identities now
2026’s genuinely new problem: AI agents that act — reading mailboxes, filing tickets, running deployments — at machine speed, on human-ish scopes. Nearly every organization now runs some; almost none can answer “list every agent, its owner, and what it can touch.” The governance answer is not a new framework — it’s recognizing that an agent is an identity and refusing it any exemption from the machinery this module already built:
| Question | Same answer as for humans/workloads |
|---|---|
| Who is it? | A directory identity per agent — named, not a shared “bot” account |
| Who answers for it? | An owner team (the fleet-registry discipline), reviewed quarterly |
| What can it reach? | Least-privilege scopes with the justification + NOT-requested list |
| How does it authenticate? | Asserted identity, sender-constrained tokens where supported — never an API key in a prompt file |
| When does it die? | Lifecycle rule: owner departs or 90 days idle → suspended, alarmed |
| What did it do? | Full audit trail, queryable — agents make great log citizens |
The activation-gate logic from Lesson 2.3 extends naturally: an agent that needs elevated scope for a task should request it JIT, not hold it standing. If your platform supports agent-specific conditional access, the agent gets baseline policies like everyone else. The mistake to refuse: treating agents as a special magical category outside identity governance — that’s how the next Drift-shaped breach arrives wearing an agent badge.
The 2026 state of token binding, honestly: mTLS-bound and DPoP-style sender-constrained tokens (the token only works from the client that proved a key) are standardized, recommended in the newest agent protocols, and still thinly deployed among mainstream issuers. Teach the direction — bearer tokens are the new passwords and binding them is where the industry is going — but build today’s defenses on what ships now: short lifetimes, narrow scopes, federation over storage, and revocation you have rehearsed.
Meridian's ops team wants an AI agent that reads outage tickets and drafts customer notifications. The vendor's quickstart says: 'Create a service account, grant it Mail.ReadWrite and Tickets.ReadWrite.All, and paste its API key into the agent config.' What does this module require instead?
Key takeaway
Machines outnumber people and get the same three questions: who are you (asserted, never stored), what may you touch (minimal, with the scopes you declined on record), and who answers for you (owner, lifecycle, audit). Govern the OAuth grants you forgot, and welcome agents as the newest identity class rather than a magical exception — the Drift breach was the tuition; the governance is the lesson. Identity pillar complete. Next: the devices those identities sign in from.