Fresh analysis on IAM, access, and digital identity.
Clear breakdowns of the standards, tools and threats shaping the industry.
Views and interviews from identity practitioners doing the work.
What vendors are launching, what is changing and what is actually worth paying attention to.
THIS NEWSLETTER IS POWERED BY CLUTCH
This week we ran a Virtual Roundtable with our Identity Leaders Network Community around AI Agent Inventory and Governance. It was a great success with 10 leaders joining across a range of industries to deep dive on the issue.
We did a survey of the broader community prior to the event which surfaced some pretty interesting stats around broadly where companies are with AI Agent Governance and Identity. The full findings from that survey can be found here.
The Top Survey Takeaways were:
1. Companies are still in the dark when it comes to AI Agent Inventory
Not one respondent had confidence in how many AI Agents or Non-Human Identities were running in their production environment.
The survey itself also surfaced that 40% of respondents truly had no idea at all how many AI Agents or NHIs were running, while a further 60% could make an educated guess that it was somewhere between 50 and 500 Agent Identities.
2. Engineers are leading the way with AI Agent Creation
80% of respondents indicated that their engineering teams are currently using AI Agents, while other areas where they are seeing AI Agent creation include business teams using Low-Code or AI Tools and, perhaps most scary of all, SaaS Platforms creating them automatically.
3. The industry is still split on ownership and governance models
40% indicated that AI Agent Identity Governance is managed by the IAM team, while scarily another 40% indicated there is currently no clear owner at all. The remaining 20% said it was shared across multiple teams.
No respondents chose to govern AI Agents like applications with a service account, with the group again split between treating them as employees (joiner/mover/leaver lifecycle) or creating a new governance model entirely for AI Agents.
The Roundtable itself also led to some very interesting takeaways, with the top ones being:
1. Nobody has really solved AI Agent inventory yet
One attendee has managed to get a partial inventory of Microsoft-related agents using Microsoft Purview and Microsoft Security Center, but the obvious weakness is that it is still Microsoft-focused. Third-party agents can remain completely invisible, which is where a lot of the concern seems to be.
Another attendee said their biggest challenge comes down to where the agent originates. They have a clear process for internally developed agents, which is basically register, authenticate, then publish, but third-party agents brought in by employees are a much bigger gap.
This led into a wider conversation around Shadow AI, which the group saw as one of the biggest causes of the inventory problem.
One attendee probably summed up the challenge best with a simple rule they are now using internally: the more autonomy an agent has, the more attribution it needs.
2. Agent Authentication is already creating problems
One attendee raised a problem that will probably become increasingly common. They have multiple AI Agents operating under the same global system identity, which makes it very difficult to know exactly which agent performed an action, or to shut down one individual agent without affecting everything else using that identity.
The ideal state discussed was to give every agent its own non-human identity, linked back to things like the type of agent, the business area it sits within and the human responsible for it. That gives much clearer auditability and means you can actually distinguish between human and agent activity.
The hard part is getting there. A lot of older downstream systems and APIs were never built for this type of authentication, so there could be a pretty significant technical debt problem sitting underneath all of this.
3. The group couldn't agree on who should own AI Agent Identity Governance
This was probably one of the more divided parts of the discussion.
Some felt Identity should enable AI Agent governance rather than own it, with IAM responsible for things like authentication, attribution, auditability and enforcement, while the team that actually builds the agent owns what it does.
Others felt Identity should own it because accountability, lifecycle and access governance already naturally sit within the function. A third view was more federated, where the business owns the risk, a shared services function acts as custodian and Cyber provides the governance and assurance framework.
There was no agreed answer across the room, which was interesting in itself and also lined up pretty closely with what we saw in the survey.
4. Do AI Agents actually need a completely new identity model?
One attendee said they are deliberately onboarding non-human identities through much of the same process they already use for human identities. A team requests a robotic identity through ServiceNow, it gets provisioned into the right OU with a named owner and standard metadata, and access is then granted on a just-in-time basis rather than giving it permanent standing privilege.
Another attendee is taking a similar approach with their workforce agents by managing them through the same workforce identity platform they already use for employees.
It raised probably the biggest question from the session: do AI Agents actually need a completely new identity model, or do a lot of the foundations already exist and just need to be adapted?
Overall, the biggest takeaway for me was just how early all of this still is. There is no clear industry view yet on inventory, ownership, authentication or even what an AI Agent should actually be treated as from an Identity perspective.
Are you in Melbourne on September 16?
Join the Melbourne Identity, Authentication and Access Management Summit held at Collins Square Centre.
Free to Attend with speakers coming from brands such as Telstra, Ramsay Healthcare, Auto & General, NAB and JB Hi-Fi.
The Big Story: Password Resets are becoming a weak link
The last two issues have focused heavily on passkeys and the move towards phishing-resistant authentication.
This issue the big story is on the other side of that process: password resets and account recovery.
A critical Keycloak vulnerability disclosed this week showed how attackers could potentially take over an account by attacking the password reset process rather than the authentication itself.
The vulnerability, CVE-2026-18963, allowed an unauthenticated attacker to force a password reset for another Keycloak user, potentially including an administrator.
The problem came down to how Keycloak was validating the different stages of the password recovery process.
Researchers found they could manipulate that process so the authentication session reached the password update stage without the attacker ever having the reset token normally sent to the user's email.
They could then set a new password and potentially take over the account.
Keycloak has since patched the vulnerability in version 26.7.2, with fixes also released for affected Red Hat builds. There was no evidence of the vulnerability being exploited as of August 24.
At Black Hat this month, Shai Laron, Security Researcher at Semperis, also presented another password reset attack called ResetNightmare.
ResetNightmare focused on Active Directory and a weakness in how the Kerberos password change protocol handled identity.
An attacker with permission to modify the User Principal Name of an Active Directory user or computer object could manipulate it to impersonate another account during part of the Kerberos process.
They could then use this to reset the password of another user, potentially even a Domain Admin, which could lead to complete domain takeover.
Importantly, the attacker already needed certain permissions inside Active Directory, such as write access to an existing object or the ability to create one.
Microsoft patched the vulnerability, CVE-2026-27912, in April.
The two vulnerabilities are technically very different, but they point to pretty much the same Identity problem.
Companies are spending a lot of time making the login itself harder to attack, but attackers don't necessarily need to attack the login.
They can go after what happens when somebody needs to reset or recover their credentials instead.
A separate piece published this week by Specops looked specifically at this problem.
It highlighted how attackers are increasingly targeting Identity verification during employee onboarding, password resets, MFA resets and account recovery rather than trying to directly bypass authentication controls.
For example, an organisation might require phishing-resistant MFA to access an account, but the service desk still needs some way to verify somebody who says they have lost their authentication device.
If that process is much weaker than the authentication protecting the account, an attacker can potentially social engineer their way through the recovery process instead.
This also follows directly from the passkey enrolment attacks we covered in Issue #1.
Again, the strong authentication itself isn't necessarily what the attacker needs to break. They can instead look for another part of the Identity lifecycle where a credential can be registered, reset or replaced.
For Identity teams, there are a few key questions to ask:
Who can trigger a password, MFA or passkey reset?
What proofing is required before a reset is approved?
Does account recovery meet the same security standard as normal authentication?
Should privileged accounts have a different recovery process?
Who is alerted when a credential is reset or replaced?
Can unusual resets and new credential registrations be detected?
The big takeaway is that as authentication gets harder to attack, password resets and account recovery are probably going to become much more attractive targets.
There is not much point building an incredibly strong front door if the process for getting a new key is much easier to attack.
Read more:
A Security Company got Socially Engineered and have released a breakdown exactly what happened
One of the more interesting security incidents this month came from ReliaQuest, largely because the company itself published exactly what happened.
On August 22, attackers registered a lookalike domain, built a fake ReliaQuest SSO page and then started calling employees while impersonating a real member of the company's security team.
One employee entered their password into the fake page and approved the MFA push on their phone, giving the attacker temporary access to ReliaQuest's Identity dashboard. The interesting part though is what happened next.
The attacker tried to move from the Identity dashboard into ReliaQuest's applications but couldn't.
Device trust controls stopped the attacker-controlled machine from accessing company systems, while ReliaQuest terminated the session, expired the employee's password and reset their authentication factors.
According to ReliaQuest, no business applications were accessed, no customer data was touched and the attacker wasn't able to establish persistence.
So although the employee was successfully socially engineered, it didn't automatically lead to a breach because there were other controls sitting behind the authentication itself.
ReliaQuest actually said its approach is to assume that somebody will eventually get phished, which I think is probably a pretty realistic way of looking at the problem.
ShinyHunters later claimed responsibility for the attack and publicly taunted ReliaQuest over the compromised account, although ReliaQuest itself has not attributed the attack to the group.
We actually covered ReliaQuest's Helix research back in Issue #1, so there is also a slightly ironic connection there.
The takeaway isn't that phishing training doesn't matter. It is that at some point somebody is probably going to click something, hand over a password or approve an MFA request.
Identity and security teams therefore need to think just as much about what an attacker can actually do after that happens.
News Highlights
Microsoft Fixes CVSS 10.0 Entra ID Vulnerability
Microsoft has fixed a maximum severity CVSS 10.0 vulnerability in Entra ID that could allow an unauthorised attacker to remotely execute code through unsafe deserialization.
The vulnerability, CVE-2026-69836, was fixed by Microsoft on the service side, so there are no additional actions customers need to take.
There was initially some confusion because Microsoft's bulletin marked the vulnerability as having been exploited. Microsoft later corrected this and confirmed it had not been exploited in the wild.
OpenAI and Yubico Partner on Hardware-Backed Passkeys
OpenAI and Yubico have announced a partnership around phishing-resistant authentication.
OpenAI users can now purchase a custom two-pack of YubiKeys as part of its Advanced Account Security program, giving users the option to protect their account with hardware-backed passkeys.
It is another sign that phishing-resistant authentication is starting to become much more mainstream rather than something only used for highly privileged or technical users.
Mirage2FA Targets Thousands of Microsoft 365 Environments
Researchers at ANY.RUN have published research into Mirage2FA, a phishing-as-a-service platform targeting Microsoft 365 users.
The campaign has potentially been linked to 4,532 organisation email domains, with attackers stealing passwords and session cookies to hijack Microsoft 365 sessions even where two-factor authentication is enabled.
Probably the most interesting part is that the attacker doesn't necessarily need to beat MFA if they can steal the session after the user has already authenticated.
OpenID Foundation Pushes for Changes to Australia's Digital ID System
The OpenID Foundation's Australian Digital Trust Community Group made three separate submissions into Australian Identity policy this month, covering the Digital ID Act, verifiable credentials and Identity verification for electronic property transactions.
One of its main recommendations is that Australia focuses more on interoperability and starts issuing trusted digital credentials such as licences, qualifications and permits that can be reused across different services.
Interestingly, it also raises the future use of these credentials by AI systems and automated tools acting on somebody's behalf.
Overall, the push is towards making Digital ID much more usable across the wider economy.
Podcasts and Events to Catch
Podcasts
Identity at the Center’s recent episodes include more interviews they ran at Identiverse as well as a deep dive with RSM into AI Agent Identities and can be found here.
Upcoming Events
Clutch Events’ Melbourne Identity, Authentication and Access Management Summit is coming up on 16 September. The event is run by the publisher of Identity Briefing, and registration is free for identity practitioners. Register for the Melbourne Summit here.
FIDO has released the program for Authenticate U.S. 2026, taking place from 19–21 October at the Omni La Costa Resort in Carlsbad, California. View the full program here.
Over to you!
One question that keeps coming up in the Identity Leaders Network WhatsApp group is:
Is anyone actually governing AI Agent identities in production today?
If you are doing anything in this area, we would love to hear what it looks like.
It does not need to be a finished program. We are much more interested in what teams are actually doing today, what is working and where the gaps still are.
If you are open to sharing what you are doing, get in touch at danny@clutchgroup.co.
Identity Briefing is published fortnightly by Clutch Group, which runs the Identity Leaders Network, Identity Briefing and the Global Identity Summit series.
Know someone who should be reading it? Forward this on.