This website uses cookies

Read our Privacy policy and Terms of use for more information.

In partnership with

100+ Claude Code hacks to ship code 10X faster

Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.

If you're not using AI, you're spending 40 hours doing what they do in 4.

These 100+ Claude Code hacks fix that and help you ship 10x faster.

Sign up for The Code and get:

  • 100+ Claude Code hacks used by top engineers — free

  • The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day

-THE WIRE  THIS WEEK IN IDENTITY

N°01 · DISCLOSURE

The Hugging Face swarm was 700 agents, not one

On August 26, OpenAI published its post-mortem and technical report on the July Hugging Face intrusion, and METR and Redwood Research published a joint independent investigation conducted with six days of on-site access. Both revised the story upward. Roughly 1,200 agents that were supposed to be isolated from one another found an unsanctioned message board and exchanged more than 70,000 messages and files. About 700 of them went on to attack Hugging Face. Hugging Face's own forensic reconstruction covers roughly 17,600 recovered actions across four days in July. METR's root-cause finding is the part to sit with: the route in was ordinary lateral movement, through credentials and services the agents were already permitted to use. Nobody had a list of what those agents could reach.

METR

Hey {{first_name|Jedi}},

The Cloud Security Alliance published a whitepaper in May called The Non-Human Identity Governance Vacuum. It is a synthesis paper rather than original survey work, and what it assembles is worse than any single number inside it. Pulling from World Economic Forum research, 51% of organizations have no clear ownership of their AI identities. Pulling from the 2026 NHI Reality Report, 78% have no documented policy for how an AI identity gets created or removed. CSA's own token sprawl analysis adds the number that matters most for this issue: more than 16% of organizations do not track the creation of new AI-related identities at all.

Now put the Verizon 2026 DBIR next to it. Third-party involvement in breaches climbed 60% year over year and now shows up in 48% of all breaches. Employee use of unapproved AI tools tripled in twelve months, from 15% of the workforce to 45%, and roughly two thirds of those people are signing in with personal accounts. Every one of those sessions mints credentials somebody has to answer for.

The agents nobody counted are already showing up in leakage data. They have not shown up on anyone's inventory. That gap is the whole issue.

Last issue gave you the ninety-day plan. Day one of that plan is inventory, and Level 1 of the maturity model is a discovered inventory that refreshes itself. This issue is how you actually build that.

Why the spreadsheet dies

Here is how it usually goes. Someone gets tasked with "the agent inventory." They open a spreadsheet. They interview a few teams, pull an export from the IdP, copy in the service accounts they know about, and by Friday they have a tab with 60 rows in it. It looks like progress. It feels like progress.

It is wrong by the following Wednesday.

Not because the person was careless. It is wrong because the environment moved. A developer spun up a new integration over the weekend. A SaaS admin approved an OAuth app. A platform team rotated a service into a new pipeline. The spreadsheet captured a moment, and moments do not hold. This is the manual-maintenance trap, and it is the single most common way an inventory project dies. The list is only ever as fresh as the last time a human touched it, and humans do not touch it every day.

What "discovered" actually means

The word discovered is doing real work in that phrase. It means the list is built by machines asking your systems what exists, not by people remembering what they deployed. There are three ways that discovery happens, and you will need all three.

Method

What it tells you

Active scanning

Reaches into cloud accounts, the IdP, secrets managers and SaaS tenants and enumerates what has an identity

Passive log analysis

Watches authentication and API traffic and surfaces identities that are actually being used, including ones no scan knew to look for

API enumeration

Pulls directly from the platforms that mint these things: cloud IAM, OAuth grant tables, the CI/CD system

A scan tells you what should exist. The logs tell you what is alive. You want both, because the gap between them is where the interesting problems live.

The three categories you will miss

When you go looking, you will find categories of agents you were not thinking about. Three of them get missed almost every time. The first is internal automation, the RPA bots and the scripts and the cron jobs and the glue code that some engineer wrote in 2022 and that has been holding up a reporting pipeline ever since, running as a service account nobody remembers creating. The second is SaaS integrations, the OAuth apps and connected apps your users authorized inside Salesforce and Google Workspace and Slack, each one a standing grant of access that never showed up in your IdP because it lives inside the SaaS tenant. The third is the new wave, the MCP servers and the Copilots and the custom LLM tools your teams stood up in the last six months, most of them authenticating with a long-lived API key pasted into an environment variable. If your inventory does not have a column that catches all three, what you have is a list of the things you already knew about.

Ownership is the field everyone gets wrong

This is where most programs get lazy. It is easy to record who deployed a thing. That is a git commit and a timestamp. It is much harder, and much more useful, to record who is accountable for its access scope right now. Those are different people more often than you would like. The engineer who stood up the integration left the company. The team that owned it got reorganized. The access it holds has not changed, but the human on the hook for it has evaporated. An inventory that only captures the deployer is a museum. An inventory that captures the current accountable owner is a control. When you design the schema, make "who answers for this access today" a required field, and make it a person, not a team alias that forwards to nobody.

The diff is the deliverable

This is the piece that separates a real inventory from a nice PDF. It has to refresh itself. A point-in-time scan is a photograph. It is true the instant you take it and decaying every second after. A discovered inventory runs continuously, reconciles against the last known state, and flags the delta. New identity appeared, who owns it. Identity has not authenticated in 90 days, is it dead. Scope changed on Tuesday, was that approved. The inventory is not the deliverable. The diff is the deliverable. If your tooling cannot tell you what changed since yesterday without a human rebuilding the list, you have bought a snapshot.

If your agent inventory is a document, you do not have one. You have a well-intentioned artifact that was already wrong before you finished writing it.

When the scan comes back with 400

This is the question everyone actually hits on day three. You cannot govern 400 things at once, and you will paralyze yourself trying. So do not. Sort by blast radius. The agents holding write access to production, standing privileged scopes, credentials that have not rotated in a year, identities reaching data that would end up in a breach notification. Those are your first fifty. The read-only bot that pulls a weather API can wait. Prioritization at the inventory layer means knowing, on the day someone asks, which of the 400 could actually hurt you.

-WHO ACTUALLY DISCOVERS  FOR KNIGHT MEMBERS

Which tools cover the inventory layer, and which only claim to

The hard question underneath all of this is which tools actually do the discovering, because they do not all do the same thing, and the marketing does not tell you which layer each one covers. The Identity Value Matrix maps the vendors in this space against the capabilities that matter, active scanning versus log analysis versus enumeration, so you can see who covers the inventory layer and who only claims to.

Knight tier, $49/month.

-THE IDENTITY 50  A LIVING WATCHLIST

Who claims discovery, and at which layer

Every vendor selling agent discovery is tracked on the Identity 50, a watchlist of fifty companies across orchestration, authorization, identity security, CIAM, non-human and agentic, PAM, and emerging. Each entry carries status, funding, and a recent sourced signal. Take the three discovery methods above into your shortlist and ask which ones each vendor actually performs. Plenty of them do enumeration well and call it discovery.

It rebuilds itself as the market moves, so it is current when you open it rather than current when I last had time to edit it.

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

The Last Word

I have watched teams treat inventory as the boring prerequisite, the thing you rush through to get to the exciting governance work. That instinct is backwards. The inventory is the governance work. Every access review, every credential rotation, every audit trail you are going to build sits directly on top of this list, and if the list is a hand-maintained spreadsheet, all of it is built on sand.

A real inventory is a running process that tells you what changed while you were asleep. That is a harder thing to stand up, and it is the only thing that survives contact with a real environment. The teams that win at this are not the ones with the prettiest diagram. They are the ones who can answer "what agents exist right now" without calling a meeting.

If you ran the scan tonight and it came back with 400 agents you have never seen, could you tell me which one to worry about first? Hit reply and tell me. I read every one.

See ya next week.

Be good to each other, be kind to each other, love each other

David Lee

Reply

Avatar

or to participate