This website uses cookies

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

In Partnership With

Questions on governing AI securely? Gartner IAM Summit has answers.

GenAI is evolving at warp speed. AI agents are everywhere. Identity is now your #1 attack surface. Is your organization prepared? Instead of spending months researching new AI risks, get the insights you need in just 3 days at Gartner Identity & Access Management Summit 2026, December 7 – 9 in Las Vegas.

Hear from top cybersecurity and IAM analysts, trade strategies with 1,700+ peers, and learn about governing agentic AI, machine identities, aligning IAM and cybersecurity strategy, and more. Register before October 9 to save $400 on the standard rate.

-THE WIRE  THIS WEEK IN IDENTITY

N°01 · DISCLOSURE

OWASP just published the control checklist your vendor's "agentic-ready" page hopes you never open.

On September 1, 2026, the OWASP GenAI Security Project adopted the Agent Control Standard, ACS v0.1, a runtime control-plane spec for AI agents. It names the controls a system actually has to implement: agent identity, agent capability, tool authorization, MCP access, memory provenance, execution policy, human authorization, telemetry, and incident containment. It draws a hard line between controlling an agent's authority at runtime and merely watching it after the fact.

That list is a buyer's checklist. Hold a vendor's "agentic identity governance" page against those control pillars and the gap between architecture and campaign shows up fast. A form with a new dropdown does not implement tool authorization or incident containment. This week's issue is about asking the questions that surface which one you are actually looking at.

Hey {{first_name|Jedi}},

By Q4 2026, every IAM vendor has a product page with the words "agentic AI" on it. The pages are not lying. They are describing real features. A workflow, a dashboard, a governance module, a discovery scan. Real engineers wrote real code, and the product shipped. The lie is structural, not intentional. The page says "agentic identity governance" and what it means is "we added a field for agent type to a form that was designed for a human." The form still exists. It just has a new dropdown.

Incumbents don't rebuild. They add.

Marcus has been through this before. He has seen DLP vendors discover data governance, SIEM vendors discover identity, and identity vendors discover zero trust, all in the same year, all with the same product page. There is a pattern to how an incumbent platform gets caught flat-footed by a category shift and what it does about it. It does not rebuild from the architecture. It adds. It adds an agent type. It adds a machine identity section. It ships a report. It runs a campaign that says "agentic-ready." The underlying model, the one that assumes a human is the principal, the one that routes decisions through a ticket, the one that measures governance by how many forms got completed. That model does not change. The form just got a new dropdown.

This is not cynicism. It is a structural observation. Enterprise platforms earn their right to exist by being stable under load for a decade. The same quality that makes them trustworthy on day 1000 is what makes them slow on day 1. They cannot rebuild the access model from scratch to serve a non-human principal. Their customers would not let them. The integration surface is too large, the upgrade risk too high, the compliance dependencies too deep. So they add. They add as fast as they can, they ship it before it is ready, and the product page reflects ambition rather than architecture.

The vendors who bet on the machine as the principal

Marcus's job is not to be cynical about this. His job is to tell the difference. Because there are vendors who have been building for this problem since before it was called "agentic identity." Who started from the assumption that a machine is the principal, not an afterthought in the principal model. Who designed their access graph, their credential model, their workflow engine, and their audit trail for a world where most of the identities in the stack are not human. Those vendors exist. They are not always the loudest. But a thirty-minute demo call with the right questions surfaces them in the first ten minutes.

Five questions the vendor isn't expecting

The questions that matter are not the ones on the vendor's discovery guide. They are the ones the vendor is not expecting. Here are five.

1. Show me the agent's principal in your graph

Not what it looks like in the UI. The graph. The data model. How does the system represent an AI agent differently from a human, and what properties does it carry? Does it have an intent baseline, a scope definition, a credential type, a behavioral profile? Or does it have a display name, a department field, and a manager. The display name, department, and manager are fine for a human. For an agent, they tell you nothing about what the agent is allowed to do, what it normally does, or how to detect when it has drifted. If the vendor cannot show you a principal model that was designed for a non-human actor, the rest of the demo is theater.

❝

A vendor who has not made that bet is selling you a form with a new dropdown.

2. How do you handle ephemeral agents today?

Not how they plan to handle it. How they handle it today. Ephemeral agents, the ones that exist for a single task and dissolve, are a fundamental problem for any governance system that was built around persistent identity. A human employee has a persistent record. An agent that spins up to answer a question and disappears has a lifecycle measured in seconds. If the vendor's governance model requires a provisioning ticket, an approval workflow, a manager assignment, and a 48-hour SLA to get an agent into the system, they have not solved ephemeral. They have built a process that works for the long-lived agents and quietly ignores the short-lived ones, which in a lot of environments are the majority. Ask them directly. Watch whether the answer is a roadmap item or a live demo.

3. Show me the audit trail for one tool-call chain

Not the access log. The audit trail. Tell them you want to see what a specific agent did from the moment it received a trigger to the moment it completed the task, including every tool it called, every resource it touched, every credential it presented, and every decision the model made. Ask them to show you that in a single view, correlated by session, with timestamps that are synchronized across all five planes: the gateway, the LLM provider, the tools, the identity system, the observability layer. That correlation problem is hard. It requires a session ID that persists across planes and a log architecture that was designed to stitch them together. If the vendor gives you five separate log exports and a suggestion to use a SIEM to correlate them, they have not solved the audit trail problem. They have told you it is your problem.

4. What happens when an agent acts outside its scope?

Not what the policy says will happen. What the system does. Does it block the action? Log it? Send an alert? How long until the alert reaches the owner? Does the alert contain enough context for the owner to make a decision, meaning what the agent tried to do, why the system flagged it, and what the risk was, or is it a raw log entry with a severity score? The difference between a vendor who has thought about behavioral monitoring and one who has not is whether the answer is a policy configuration screen or a governance workflow. The policy screen tells you that governance is the human's problem. The governance workflow tells you the system has a theory of what to do when the agent goes wrong.

5. Describe your credential model for a short-lived agent

Specifically: how does an agent that spins up at 9am, does its work, and terminates at 9:03am receive a credential that is scoped to exactly the work it needs to do, expires when the work is done, and leaves no persistent secret in any system? That is the SPIFFE/OIDC workload identity pattern. It is not exotic. It is the right answer. If the vendor's answer involves generating an API key, storing it somewhere, and rotating it on a schedule, they are solving the human-identity-management problem, not the machine-identity problem. Rotating an API key is better than a static one. It is not the same thing as short-lived, workload-bound credentials that cannot be exfiltrated because they do not persist. That distinction tells you more about a vendor's architecture than any product page.

You already know enough to ask these

None of these questions require deep technical expertise. They require knowing what the problem actually is. And knowing what the problem actually is is exactly what the last sixteen issues of this newsletter have been about. You don’t need to be a cryptographer to ask what the agent's principal looks like in the data model. You need to know that the principal model is where the architectural bet is made.

So before the budget conversation in the next issue, here is the work this week. Pull up the product page of the two or three vendors on your shortlist. Read it with these five questions in mind. Then book a demo and ask them. You will know in the first thirty minutes whether the page reflects an architecture or a campaign. That thirty minutes is worth every meeting you will have over the next quarter trying to evaluate something you can't evaluate without seeing the data model.

The Last Word

Now more than ever, we need clarity in this industry. It’s a fast-moving space, and everyone is running, trying to solve a problem, but as a practitioner, you need to solve your problem, and sometimes those aren’t the same thing.

If you sat one of your shortlisted vendors down tomorrow and asked to see the agent's principal in their graph, are you confident they could show you anything but a form with a new dropdown? 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