Somewhere between the third "let's circle back" and an endless Slack thread, you started skimming business news instead of actually understanding it. Can't blame you—most of it reads like a lifeless shareholder memo.

Sound familiar? Morning Brew fixes that. Inflation, global trade, the weird stuff happening in business—we cover it like a smart friend explaining the news, minus the boring parts. Plenty of puns, plenty of sense.

Business news doesn't have to be boring. Join over 4 million professionals who found the loophole.

Try it for free

-THE WIRE  THIS WEEK IN IDENTITY

N°01 · DISCLOSURE

IBM's Cost of a Data Breach research landed on a number that should stop you cold. Among the organizations that reported AI-related breaches, 97% said they lacked proper access controls. Not a majority. Not most. Nearly all of them. Read that next to the Verizon DBIR finding that shadow AI use tripled to 45% of employees, and the shape of the problem gets clear. Unsanctioned agents are spreading faster than anyone is governing them, and when one of them gets breached, the access controls that should have contained it were not there. The credential column in your inventory is where that gap lives. This week is about closing it.

→ IBM Cost of a Data Breach · Verizon DBIR

You went through the inventory. You found the agents, including the ones nobody knew existed. You assigned owners. And now you are looking at the credential column.

Most of it says API key. Some of it says static token. A fair amount says service account password, last rotated when it was created. A few entries have no credential field at all because the person who set it up stored the key in a Slack message and nobody documented it.

This is the normal result of a real inventory exercise. It is also the list that has more exploitable surface area than anything else in your environment. The reason is simple: a long-lived API key is a standing promise with no expiration date. It says this bearer can act as this agent forever. Nobody meant to make that promise. They just needed the integration to work by Thursday.

The shift to short-lived credentials is the highest-leverage security change an organization can make after the inventory, and it is chronically underdone. Not because people disagree with the principle. The principle is uncontroversial. It is underdone because the operational path is not well-documented, the scope feels overwhelming, and the first few rotations break things people did not know were depending on them. So the change gets deferred, the keys stay static, and the blast radius grows quietly every quarter.

The way to make this tractable is to treat it as a migration with a sequencing logic, not a big-bang credential reset.

The first thing to establish is which of your agents are candidates for short-lived credentials versus which ones need a different approach. Workload identity federation is the right answer for agents running inside a managed compute environment: a cloud VM, a Kubernetes pod, a GitHub Actions runner. These environments can issue OIDC tokens that assert this workload is running in this environment at this time. The receiving service verifies the token, checks the assertion, and grants access for a bounded window, typically minutes. The credential cannot be stolen and replayed later because by the time someone extracts it, it has already expired. SPIFFE and SPIRE extend this model across multi-cloud and on-premise environments using the same core principle. This is the ideal path for any agent with a stable compute home.

JIT access is the answer for agents that require elevated privileges on a scheduled or triggered basis rather than continuously. Instead of holding a standing credential with broad rights, the agent requests access at the point of need, the system issues a credential scoped to exactly the rights required for that task, and the credential disappears when the task completes. The agent that runs your quarterly compliance export does not need write access to your audit logs on a Tuesday afternoon. JIT ensures it does not have it.

OAuth dynamic client registration covers the remaining category: agents that authenticate to external SaaS APIs where you cannot control token issuance on the receiving end but can control how your side manages the OAuth flow. Dynamic registration lets an agent obtain a client credential at runtime rather than holding a long-lived client secret baked into configuration.

Three patterns. The migration question is which agents go to which pattern, and in what order.

The sequencing logic that works is blast radius first, not alphabetical and not by team. Take the inventory you built in Issue 13 and sort it by two criteria: privilege level and external reach. The agents with write access to production systems or data stores, and the agents that call external services where a compromised credential could result in exfiltration or manipulation, are your first cohort. They represent the highest consequence if a static key is extracted. They go through the migration first, regardless of which team owns them.

The second cohort is any agent holding a credential that has not been rotated in more than a year. Staleness is a proxy for drift: the longer a key has been live, the higher the probability that access has expanded beyond its original scope, the original owner has moved on, and the credential exists in more places than the one system you documented.

The third cohort is everything else. Read-only, low-privilege, internal-facing agents with recently-issued credentials. These migrate last, and for some of them the timeline stretches beyond a year. That is acceptable as long as they are in the inventory, owned, and scoped correctly.

Now the part that breaks things. When you start rotating credentials, you will discover dependencies you did not know existed. The agent that authenticates to your data warehouse also has its credential hard-coded into a reporting script that runs on a different server, owned by a different team, that was never in the inventory because it is technically a script and not an agent. When you rotate, the script breaks and someone calls the helpdesk.

The way to catch this before it causes an incident is to run the rotation in a non-production environment first, and to query your authentication logs for the credential before touching it. Any system that has logged a successful authentication using that credential in the last 90 days is a dependency. Find the owners of those systems before you rotate, not after. This step feels slow. It is the difference between a clean migration and a Saturday-morning war room.

The operational investment in short-lived credentials pays forward into everything that comes next. An audit trail for an agent using OIDC tokens carries identity context at each step automatically. An access review for an agent running on JIT has a built-in proof of scope at each access event. The credential migration is load-bearing infrastructure for the next three issues in this arc.

-WHO ACTUALLY MAPS THE VENDORS  FOR KNIGHT MEMBERS

The sequencing decision is straightforward in principle and hard in practice, because your environment has context the framework does not. The Identity Value Matrix breaks down which vendors cover workload identity federation, JIT access, and dynamic client registration, and which ones are bundling capabilities versus building purpose-built solutions at each layer. That breakdown is behind the Knight tier at $49 a month.

→ Get the Identity Value Matrix · $49/mo

-THE IDENTITY 50  A LIVING WATCHLIST

Okta closed its acquisition of Permiso Security on August 26, pulling identity threat detection and response for human, non-human, and AI-agent identities inside the platform. Watch what that signals for the credential problem this issue is about. The market is deciding that agent identity threat detection belongs next to the identity provider, not bolted on beside it, and the biggest players are buying rather than building to get there. When you sequence your own credential migration, assume the tooling under it is going to keep consolidating.

→ Okta · Permiso · See the Identity 50

Think a vendor belongs on it? Reply to this email and tell me who.

Every time I walk into an environment and see a service account with a password from 2021 still in rotation, I know what conversation is coming. It is not malice. It is operational debt nobody had time to touch because there was always something more urgent. Static credentials accumulate the same way technical debt does: one sensible shortcut at a time, until the list is too long to look at directly.

The framing shift that has worked for me is to stop thinking about credential rotation as a security task. Treat it as infrastructure. You would not run a production system on a TLS certificate that expired two years ago. A long-lived API key is the same category of problem with worse tooling and a longer cultural habit behind it. When you build the migration into your identity program infrastructure, with owners and timelines and a sequencing queue, it stops being a project and starts being a maintenance cycle.

That cycle is the difference between a credential that expires because you planned it to, and one that gets revoked because someone else forced your hand.

How many API keys in your environment would still grant access to production systems if someone extracted them today and tried to use them six months from now? Hit reply and tell me. I read every one.

See ya next week.