The 8-hour workday is becoming a 4-hour workday for people who know how to use AI.

Everyone else is still catching up.

This AI work playbook shows you exactly how to cut your work hours in half using AI.

Sign up for Superhuman AI and get:

Claim your AI playbook

-THE WIRE  THIS WEEK IN IDENTITY

N°01 · DISCLOSURE

The Hugging Face breach report from last month keeps coming back to me. Not the part about the attack path, which was technically interesting. The part that stuck was quieter. The credentials the agent lifted off that node were real, live, standing grants that nobody had looked at in a while. They were not stolen from a vault. They were sitting on a machine, doing their job, owned by a system that had not had a human on the hook for them in a meaningful sense for some time. That is not a Hugging Face problem. That is a program design problem. And according to the Cloud Security Alliance, half of all organizations have it.

→ Hugging Face

Last week we talked about how to build an inventory that does not rot the second you finish it. If you ran that exercise, you now have a list. Maybe it is 200 items. Maybe it is 400. And somewhere around item 30 or 40, you hit the same wall everyone hits: the owner field is a name that no longer works at the company, a team alias that auto-forwards to a distribution list that nobody monitors, or it is simply blank.

That is a design problem, not a data-quality one. You built ownership around deployers, and deployers leave.

Here is the distinction that matters more than any other in this issue. The person who deployed an agent integration and the person who is currently accountable for what that agent can access are different people more often than you think. The engineer who stood up the OAuth grant to your data warehouse in 2024 may be gone. The integration is still running. The access it holds has not changed. But the human being responsible for deciding whether that access is still appropriate does not exist in your system. You recorded the deployer. You never recorded the owner.

So before you build the ownership model, get this straight: deployer is a historical fact. Owner is an ongoing responsibility. They are not the same field.

The second thing most programs get wrong is treating ownership as a person instead of a role. When you put a name in the owner field, that name has a limited shelf life. Reorganizations happen. People leave. Teams get renamed and merged and spun back out. A name that was accurate when you wrote it becomes a dead link six months later, and a dead link in your ownership model is the same as no link at all. The owner needs to be a named human, somebody who actually gets paged when the agent does something unexpected, but the structure holding that name together has to be role-based, not person-based at the leaf level. Which specific individual currently holds the function of "accountable for this agent's access scope" is what you are actually tracking.

The third mistake is thinking ownership means one thing. In practice, there are three distinct ownership responsibilities for any agent identity of consequence, and collapsing them into a single field is how you end up with an IAM engineer signing off on business risk they have no visibility into.

The technical owner knows what the agent does. They understand the integration, the dependency graph, what breaks if the access changes. They are the person you call when you need to understand the blast radius of a proposed scope change.

The business owner controls the data or the process the agent is touching. They are the one who should be answering whether a standing grant of write access to the CRM is still appropriate, because they understand what that access actually means in business terms. Most IAM programs do not have a business owner field at all, which means business risk decisions are getting made by people who do not have the context to make them.

The security owner is responsible for reviewing access changes, approving elevated grants, and ensuring the agent shows up in the right periodic review cadence. In smaller organizations this is often the same person as one of the other two. In larger ones it needs to be distinct.

When you have one owner field and you put the tech lead in it, you have captured one third of the coverage and called it done. The other two thirds are where the interesting failures happen.

Now the part that determines whether any of this matters. The ownership model has to be machine-enforced, not decorative. If changing an agent's access scope does not require a sign-off from the relevant owner by default, if it is possible to quietly update a credential, extend a grant, or add a new integration without the ownership chain being notified, then the owner field is a documentation artifact. It documents who you intended to hold responsible. It does not actually hold them responsible.

Access scope changes trigger an owner review. New agent identities require an owner assignment before they go live. If neither of those is true in your environment, the ownership model you built is a museum exhibit.

One last thing, because it connects directly to what comes next in this program. The review cadence lives with the owner, not with a shared calendar that nobody owns. High-blast-radius agents with standing privileged access get reviewed quarterly. Read-only bots that pull a public API can wait a year. The owner sets the cadence because the owner understands the risk. If the owner does not exist, the review never happens, and six months from now you will have a credential that looks exactly like the one sitting on that Hugging Face node. Live, standing, and watched by nobody.

-THE IDENTITY 50  A LIVING WATCHLIST

Every vendor selling agent governance 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 ownership question above into your shortlist and ask which ones each vendor actually enforces at the moment of change. Plenty of them store an owner field and call it governance.

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.

→ See the Identity 50

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

The inventory told you what exists. Ownership tells you who is responsible when it does something wrong. If you cannot answer the second question for every agent on your list, the first question was a warmup exercise. An orphaned identity is a standing grant with no human on the hook. Those are the ones that show up in breach reports.

If you pulled your agent inventory today and filtered for "owner = blank or former employee," how many rows would you see? Hit reply and tell me. I read every one.

See ya next week.