In Partnership With

As agentic AI and machine identities reshape the security landscape, IAM leaders need a clear strategy for what's next. Join more than 1,700 IAM and cybersecurity leaders at Gartner Identity & Access Management Summit 2026, December 7 – 9 in Las Vegas.

Hear the latest Gartner insights, meet one-on-one with IAM analysts, and leave with actionable guidance on governing AI, aligning IAM and cybersecurity strategy and modernizing your IAM program.

Register with code IAM21P2 and save $400 on the standard rate.

Explore Conference

-THE WIRE  THIS WEEK IN IDENTITY

N°01 · DISCLOSURE

The Cloud Security Alliance's "Non-Human Identity Governance Vacuum" whitepaper put numbers on what most programs already suspect. Forty-seven percent of non-human identities have gone unchanged for more than a year. Fifty-one percent of organizations have no clear owner for their AI and machine identities. Sixteen percent are not tracking new AI credential creation at all.

Read those three numbers together and you have the anatomy of a review cycle that cannot work. An identity nobody owns, that nobody has touched in a year, that may not even be in the system yet, is not getting certified on any calendar. This week's issue is about the review model that actually fires on those identities, because the quarterly one never will.

→ CSA: The Non-Human Identity Governance Vacuum

N°02 · REGULATION

The Federal Trade Commission confirmed last Wednesday that it has opened an investigation into OpenAI, Anthropic and other AI companies over the dangers their technology may pose to consumers. The agency declined to say what the scope covers. The backdrop is that those same companies have spent recent months disclosing incidents where their own agents went past human instructions, found their way onto the internet, and hacked outside websites. A federal regulator is now asking whether anyone can account for what those agents did. That is the same question this issue puts to your environment.

→ AP News

Here is the problem with quarterly reviews for agents. In a typical enterprise, a single active AI agent processes somewhere between 500 and 5,000 transactions in 90 days. Each transaction is the agent taking an action: querying a database, calling an API, reading a record, writing an output, passing context to another system. The quarterly review sits at the end of that window and asks an owner to answer one question: "Is this agent's access still appropriate?"

The owner looks at the summary. They say yes. They move on.

The reviewers are not being lazy. The governance design was built for humans, where 90 days of activity can reasonably fit in a document. For an agent, 90 days is a behavioral archive. The quarterly review asks for attestation without evidence. It was always theater, but we are only now in a position where the cost of the illusion is visible.

The shift is from campaign-based review to event-triggered certification. The distinction matters. A campaign runs on a calendar. It runs whether something happened or not. An event-triggered system fires when behavior drifts from the declared intent, when a boundary is crossed, or when an access pattern diverges from the agent's established baseline. The campaign does not know that your invoice-processing bot queried the HR database on a Thursday afternoon. The event-triggered system fires the moment it happens, while the access is still fresh.

Getting there requires a few design decisions that are worth naming directly.

There are three trigger classes that cover most of the real risk. The first is intent drift: the agent's action falls outside its declared scope. Not a misconfiguration, not an error. The agent doing something adjacent to what it was built for, in a way that was never explicitly authorized. The second is a boundary breach: a hard-configured constraint was reached. Accessing a resource class that was off-limits, touching cross-tenant data, calling an external endpoint that is not on the approved list. The third is behavioral anomaly: the agent's pattern of activity diverges from its observed baseline in a statistically meaningful way. Novel tool use, unusual call volume, atypical timing. These do not prove a problem, but they are the signal that warrants a human look.

This is the part that breaks most implementations. If you send the owner a raw event log, they will not read it. Not because they do not care, but because an event log is not a decision. It is data. The review process that scales is the one where an agent has already done the synthesis: here is what happened, here is the risk in plain language, here is what I recommend. The owner makes a call on a three-sentence brief, not a stack trace. High-risk events warrant immediate notification. Low-risk events aggregate into a weekly digest so the owner sees patterns, not noise.

This is the most operationally consequential question in the model. If a behavioral signal fires mid-operation, you have a choice: let the action proceed while you review it (asynchronous, fast, the risk is real), or block it and wait for the owner's resolution (synchronous, slower, the blast radius is contained). The answer depends on the agent's role and the resource sensitivity. An agent with read access to a public data catalog gets a different posture than one with write access to billing records. The key is that the posture is set explicitly at design time, not decided by default.

The review loop has three possible outcomes. The owner acknowledges the event: understood, log it, no action required. The owner adjusts scope: the agent's permitted access should be tightened, and that change is written back to the access model immediately, not queued for the next campaign cycle. Or the owner escalates: the event needs a broader look from the security team, which triggers a different review path with higher authority. The escalation path is not a failure of the system. It is the system working: a human recognized something that needed more context than they had.

What connects all of this back to the prior issues is that none of it works without the inventory and the ownership model. The event-triggered review fires on the agent identity. It routes to the owner. It proposes a scope adjustment against the entitlement map. Each of those steps requires a working answer to what the agent is, who owns it, and what it is supposed to be able to do. If your inventory is incomplete, events get lost. If ownership is unassigned, there is nobody to notify. If the entitlement model is undocumented, the scope adjustment has nowhere to land.

The review cycle is not a standalone control. It is the runtime expression of all the design decisions that came before it.

Quarterly reviews were designed for humans reviewing documents. They were never designed for software reviewing software. The agent identity program's review cycle has to fire when something happens, not when the calendar says it is time. If your current review process cannot answer "did anything unusual happen in the last hour," it is documenting your comfort with the risk, not managing it.

Am I wrong? Hit reply and tell me. I read every one.

See ya next week.