Identity: whose keys your AI holds

Your AI acts with the keys you hand it

The instinct is to start the security review at the model and ask how far you can trust it, but the model never logs into anything. Every action your feature takes, reading a calendar, querying a record, sending an email, runs with an identity you supplied. (Auth, who you are vs. what you can do covers the basics if these are new.)

Your AI never acts as itself. It acts with whatever keys you hand it, so the keys, not the model, set the blast radius.

The action surface: every tool is delegated authority made this argument for tools; behind every tool is an identity, and behind every identity is a scope. The action tells you what happened, the identity tells you who the audit log will blame, and the scope tells you how bad the worst case gets. Most teams can recite the first link and have never written down the other two.

The keys come in three kinds, and each fails differently:

• A user's session. The feature can do whatever that person can do, so the damage stays inside one account and that whole account is exposed.
• Your integration's OAuth grant. The feature acts as your product inside the customer's systems, holding whatever scopes the consent screen listed, often across every seat the customer has.
• A service account. You minted a fresh identity and chose its powers, and under deadline pressure the role that makes errors stop is usually the broad one, which is how a calendar assistant ends up holding mail.

Forgotten keys count double. In January 2024, Microsoft disclosed that attackers had guessed their way into a dormant test account, pivoted through a legacy test OAuth application that still held elevated corporate access, and read senior leadership mail. It was no product anyone watched, just a key minted years earlier that nobody took back.

Least privilege: the smallest key that does the job

Security teams call the fix least privilege: every key opens the fewest doors the job allows. We write a scope sentence for every key an AI feature holds before it ships, and a few moves carry the discipline.

• Scope to the unit of work, not the platform. An assistant drafting replies for one support inbox gets that inbox, not mail across the workspace; an agent filing contracts gets one folder, not the drive; a feature answering questions about one customer gets that customer's rows, not the table.
• Time-box every grant. A key that expires forces a renewal decision; a key that lives forever waits for an attacker on its own schedule, and an expiry date set decades out is a promise to whoever finds the key. The supply chain you didn't build dissects a famous over-scoped, far-future token from the inside.
• Separate read from write. A leaked read-only key costs you privacy, while a key that can also write or send lets an attacker act in your name. Issue them separately so the dangerous one stays rare.

The consent screen is part of your product, because enterprise buyers read it: a tight scope list shortens security review, while an app that asks to read and modify everything is an objection you wrote yourself.

The confused deputy: your key, used for someone else

Scope discipline carries extra weight for AI features because of an attack with a decades-old name, the confused deputy. The attacker never steals your key; they put instructions in front of the key's holder, in an email, a web page, or a pasted document, and the agent that reads them ends up using its legitimate authority on the attacker's behalf. How that text gets in, and which defenses hold, is the work of Injection: the input is the attack surface. What matters here is the arithmetic: the attacker inherits exactly the scope the deputy carries, so an agent that reads untrusted input should never hold a key whose misuse you could not absorb.

A stolen-token breach at seven hundred companies

In August 2025 this stopped being theory. Attackers compromised Drift, an AI chat product owned by Salesloft, whose integration connects website chat to Salesforce so conversations land in the CRM. They did not break the model and did not breach Salesforce; they stole the integration's OAuth and refresh tokens and used them to export data from the Salesforce environments of more than seven hundred organizations, major security companies among them. Every victim had simply approved a chat integration and accepted its scopes. For the attackers, the keys were the product.

What they did with the exports shows why:

• They mined the stolen records for AWS keys, passwords, and other credentials pasted into support cases and CRM fields over the years, each one a fresh borrowed key for the next system.
• The same move ran in April 2022, when OAuth tokens stolen from Heroku and Travis CI, two developer tools wired into GitHub, were used to download private repositories from dozens of organizations, including npm, and mine them for secrets.

The ending carries the lesson: Salesforce and Salesloft revoked the tokens, and the campaign stopped at once, because a revoked token opens nothing. Companies that could see what the token had touched, and rotate every credential it exposed, were handling an incident with an end date.

Revocation speed separates the two outcomes: a key you cannot revoke in minutes is a breach waiting for its date.

Rotation and revocation are features you rehearse

If revocation turns a breach into an incident, it cannot live as an untested wiki page. Treat taking a key back as a product capability with the same standing as the feature the key powers: it needs an owner, a path, and a clock.

• Build the kill switch before the incident. For every key, know the exact screen, API call, or command that revokes it, and make sure at least two people can run it without waking whoever set it up.
• Rotate on a schedule, not after a headline. When CircleCI was breached in January 2023 through malware on one engineer's laptop, the company asked every customer to rotate every secret stored on the platform. Customers who knew where each secret lived moved at once; everyone else discovered their inventory under fire.
• Prefer keys that expire on their own. Short-lived tokens that renew automatically beat long-lived ones guarded by a calendar reminder, because expiry is the one revocation that runs even when everyone forgets.

Try it now

The drill takes about fifteen minutes and runs on your own AI feature, shipped or still in build.

List every key the feature holds. Gather them from your integration settings, secrets manager, and environment config: tokens, OAuth grants, API keys, service accounts, anything that lets the feature touch another system. If the feature lives in a repo, Claude Code can sweep it for every credential the code loads.

Write one scope sentence per key. Use one form: this key can take these actions, in this system, on whose data, until this date. Any key whose sentence you cannot finish from your own documentation is your first finding.

Flag the mismatches. Compare each sentence with the job the feature performs and mark every key that exceeds it: broader data than the feature reads, write access where read would do, or no expiry at all.

Time a revocation rehearsal on the riskiest key. Pick the key whose theft would hurt most and walk the real path: name who can revoke it, find the screen or command, and stop just before the final confirmation. Write down the minutes; if revoking needs a vendor ticket or has no clear owner, that is this week's fix.

Chapter Summary

• An AI feature never acts as itself. Every action runs with a key you handed it: a user's session, an OAuth grant, or a service account.
• The keys, not the model, set the blast radius, so audit what the keys can reach before you debate what the model might produce.
• Scope every key to the unit of work, the one inbox, the one folder, the one customer, never the whole platform.
• Time-box every grant and keep read separate from write, because a key that never expires waits for an attacker on its own schedule.
• The confused deputy is the attack to plan for: the attacker never steals the key, they feed your agent input that steers it into using the key for them, and they inherit exactly the scope you granted.
• The Salesloft Drift breach ran on borrowed keys at full scale: stolen integration tokens exported data from Salesforce environments at more than seven hundred organizations, and the exports were mined for still more credentials.
• Revocation ended that campaign in one stroke. A key you can revoke in minutes is an incident, and a key you cannot is a breach.
• Rehearse rotation and revocation the way you rehearse restoring from backup: an owner, a tested path, a measured clock, and an end date on every grant.
• Keys are how attackers get in, and data is what they carry out, which is the side we cover next in Data: what flows in and what leaks out.

Sources

• Google Threat Intelligence Group and Salesloft disclosures, with industry press reporting, on the theft of Drift OAuth and refresh tokens and the export of data from Salesforce environments at more than seven hundred organizations (August 2025, with investigation updates September 2025).
• GitHub security disclosures and press reporting on stolen OAuth tokens issued to Heroku and Travis CI, used to download data from dozens of organizations including npm (April 2022).
• CircleCI incident report on the January 4, 2023 compromise and the platform-wide customer secret rotation (January 2023).
• Microsoft Security Response Center on the Midnight Blizzard intrusion: password spray of a legacy test tenant and abuse of a legacy OAuth application to reach senior leadership mailboxes (January 2024).
• BleepingComputer reporting on the Internet Archive's second breach of October 2024 through unrotated support-platform API tokens (October 2024).
• Norm Hardy, The Confused Deputy, ACM SIGOPS Operating Systems Review (1988), the original description of the attack.