This month, we wrapped up our annual summit in Denver: two days away from the day-to-day, working through the questions this community actually lives with.
The agenda is sometimes only the excuse. The main goal is bringing together people who do this work, face to face, with enough trust in each other to say what they'd never say on a webinar.
Across the main stage, roundtables and workshops, two things stood out: organizations are at very different stages yet grappling with strikingly similar challenges. And, executives and practitioners agreed on more than either side expected.
One theme ran through nearly every conversation. AI isn't just changing the threat landscape. It's changing how much time organizations have to address the risks they already know about.
“Brilliance at the basics” was the phrase that got borrowed from one of our members all week. Not “get the fundamentals right,” which everyone agreed on years ago, but run them to a standard high enough that nothing slips, because that’s what buys you the room to handle the advanced problems.
%20(1).jpg)
1. Your security backlog just became more urgent
For years, attacker economics offered a degree of protection to unresolved security risks. Reconnaissance took time, so attackers prioritized certain paths and overlooked others. Much of the backlog remained unaddressed not necessarily because the risks were low, but because exploiting them wasn't always worth the effort.
AI changes the economics of discovery. One session walked through a lab simulation of an AI-driven attack: give the agents a single instruction — take over the environment — and see what they do. The finding, as it was put on stage: "AI just finds everything you said you were going to fix at some point."
Which is why the remediation work practitioners described sounded so familiar: patch vulnerable services, get static secrets out of GitHub, clean up legacy encryption types, and eliminate weak authentication. As one participant put it, coverage has to be complete. A handful of exceptions can undermine the policy you're trying to enforce.
2. An agent should never inherit your access
.jpg)
This was one of the clearest points of agreement in Denver. Andrew Cameron, distinguished engineer for identity and cybersecurity at General Motors, made the case plainly: agents can use permissions in ways humans typically don't. People accumulate entitlements over years, then use a narrow slice out of habit. An agent may exercise the full scope of what it's granted.
As one member said: "Agents need an envelope of access that is down-scoped compared to the person they act on behalf of."
Assistive and autonomous agents require different authorization models. An assistive agent should operate within a reduced scope derived from the human it serves. An autonomous agent, by contrast, should have permissions defined by its specific function and purpose, rather than inherited from a person.
3. Govern at registration, not in the logs
One approach that came up repeatedly was comparing declared intent with observed behavior: what is an agent supposed to do, and is it actually doing that?
The challenge is that organizations lack a consistent way to define an agent's intended behavior, and agents can be created and retired too quickly to establish reliable behavioral baselines.
One of our members suggested: "When you define what the app does, that gives you scope and context. Same for an agent: declared intent, matched against where it's going. To work at scale, move the description to onboarding."
That makes the agent registry more than an inventory. It can become the foundation for enforcement: a record of what each agent is authorized to do, captured at creation rather than reconstructed from logs. We've seen the alternative with non-human identities, where establishing ownership after the fact is slow, difficult, and often unreliable.
4. If you can't reverse it, don't automate it
%20(1).jpg)
When the discussion turned to which identity security decisions AI should be allowed to automate, one principle gained broad support. One participant suggested evaluating actions against two criteria: can they be reversed, and how far could the damage spread if something goes wrong?
The implication is that autonomy shouldn’t be an all-or-nothing decision. Actions with limited impact and a clear path to reversal can be given greater autonomy. Irreversible decisions or those with a significant blast radius demand tighter controls and human oversight.
There was also clear agreement on kill switches: one may not be enough. Stopping an agent might require terminating the process, the workload, or even the underlying machine. And regardless of how authority is distributed, the ability to shut things down should remain with security.
5. Detection is never enough
Chris Linklater of Mandiant Consulting reminded us that AI doesn’t fundamentally change how security works, it compresses the timeframes. Traditionally, familiarity with a threat group’s techniques and established playbooks gave defenders an advantage. AI-driven attacks introduce a different challenge: agents can adapt their approach as an attack unfolds.
In a simulation shown at the event, agents scanned for exposed services, attempted password attacks, and shared findings with other agents operating in parallel. Some of their decisions appeared counterintuitive, including behavior that seemed designed to avoid triggering detection thresholds.
The conclusion drawn on stage was blunt. When attacks move this quickly, detection alone cannot be the control organizations rely on. By the time an alert is investigated, the attacker may already have moved several steps ahead. That puts greater emphasis on preventive controls and automated containment, rather than detection and response alone.
The thread underneath
For all the agreement in Denver, one question exposed a meaningful divide: accountability.
Practitioners approached it through specific failure scenarios and the responsibilities attached to them. Several executives challenged that framing, with one even suggesting that the traditional IAM model may need to be reconsidered entirely. It was less a disagreement about the need for governance than about how accountability should be structured as autonomous systems take on more authority.
AI didn’t hand identity teams a new problem. It took away the time they had to fix the old one.
.jpg)
Attack lifecycles that once took weeks or months can now unfold in days, while governance processes — quarterly committees, annual certifications, and risk reviews — still operate on much longer timelines. At the same time, organizations are introducing systems capable of acting independently, without always having clear answers about what those systems should be authorized to do.
What made the conversations valuable wasn't that everyone arrived with the answers. In fact, when the closing panel was asked how far along organizations really are, the answer was that many are still at "level minus one." Nobody seemed particularly surprised.
But there was a shared recognition of what needs to change. The challenge is no longer just defining better controls. It's making governance effective at the speed and scale at which modern systems now operate.
Nobody gets there alone. Some of the most useful moments in Denver happened off the agenda: between sessions, over dinner and at the roundtables, where people compared notes on problems they’d assumed were theirs to solve.
That’s what showing up in person gives you that a recording can’t. Practitioners heard how executives are actually weighing these decisions. Executives heard, unfiltered, what their teams are running into on the ground. And everyone left knowing who to call the next time the hard question lands on their desk.

