Agents and apps are identities too, and this week showed why that matters

In SMEs, Microsoft 365 security work is usually about people. MFA for users, Conditional Access for users, phishing training for users. That work matters, but two things that happened this week are a reminder that a growing share of the access in a tenant belongs to something else: apps, automations and now AI agents.

Entra is starting to let users create agents by default

On 4 November, Microsoft started rolling out a change in Entra ID: users without any admin role can create agent identity blueprints, the templates that new agents are built from. The rollout should reach every tenant by late November.

The control is a new switch called Users can create agent blueprints, under Entra ID > Users > User settings. It is on unless you turn it off. It is also separate from the older Users can register applications setting, so a tenant that locked down app registrations years ago is not covered by that decision.

Two details are worth knowing. Whoever creates a blueprint becomes its owner and can create agent identities from it without any Agent ID role. And turning the switch off later does not remove anything that already exists.

If nobody in your organisation is meant to build agents yet, set it to No now and give the Agent ID Developer role to the people who actually need it. That takes five minutes, and it is much easier than cleaning up later.

Stolen app credentials, real access

The same week, Todyl researchers described a campaign that started on 1 November and used valid, stolen Entra ID application credentials to sign in as trusted apps. According to their findings, it targeted about 45 app registrations and reached at least 27 organisations, including downstream customers of managed service providers. Files and mailbox items were accessed through Microsoft Graph and SharePoint.

No Microsoft vulnerability was involved. The attacker simply had working credentials for apps that were allowed to do things.

This is the part I want SME IT teams to take seriously: Conditional Access policies written for users do not stop an app signing in with its own secret. Microsoft does offer Conditional Access for workload identities, but it needs Workload Identities Premium licences and covers only single-tenant service principals. Many SME tenants have neither the licence nor an up-to-date list of which apps hold secrets.

Governance tooling exists, but start with the basics

On 3 November, Microsoft highlighted Agent 365, its platform for discovering and governing agents, after Gartner named it a leader in a new agent management category. It is useful, but it comes with Microsoft 365 E7 or as an add-on to E5. A 30-person company on Business Premium will not have it next week.

The same idea shows up outside Microsoft. PagerDuty launched an incident agent on 3 November that runs either with a human approving each fix or autonomously only for well-understood cases. Traficom's guidance on AI agent security makes the same point: least privilege, and human approval for critical actions.

You do not need a new platform to apply that principle. You need an inventory.

What I would do this week

1. Check the Users can create agent blueprints setting and decide on purpose.
2. Review Users can register applications and user consent at the same time.
3. List every app registration that holds a secret or certificate, and who owns it.
4. Look at service principal sign-ins for apps that have suddenly become active.
5. Remove credentials nobody can explain, and rotate the rest.

For step 3, this gives a quick starting list with Microsoft Graph PowerShell. It only reads data, and it needs an admin account because Application.Read.All requires admin consent. Uncomment the first line if the module is not installed yet:

# Install-Module Microsoft.Graph.Applications -Scope CurrentUser
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgApplication -All -Property DisplayName,PasswordCredentials,KeyCredentials |
  Where-Object { $_.PasswordCredentials -or $_.KeyCredentials } |
  Select-Object DisplayName,
    @{ n = 'Secrets'; e = { @($_.PasswordCredentials).Count } },
    @{ n = 'Certificates'; e = { @($_.KeyCredentials).Count } },
    @{ n = 'NextExpiry'; e = { (@($_.PasswordCredentials) + @($_.KeyCredentials) |
        Sort-Object EndDateTime | Select-Object -First 1).EndDateTime } }

Every row is an identity that can sign in without a person, and NextExpiry shows its soonest credential expiry. Each one should have an owner, a reason to exist and a known expiry date. I treat those three things as part of the definition of done for any automation, because an app nobody owns is the easiest one to abuse.

The list covers app registrations only. Credentials added directly to enterprise apps, such as SAML signing certificates, are not included.

Want a second pair of eyes on the apps and agents in your tenant? Get in touch.

Sources

MC1506733: Review who can create agents in Microsoft Entra (Microsoft 365 Message Center, via mc.merill.net)

Delegate app registration permissions: restrict who can create applications and agents (Microsoft Learn)

Microsoft Entra lets users create agent blueprints by default (LazyAdmin)

Attacker abuses Microsoft Entra ID to target downstream MSP clients (Cybersecurity Dive)

Conditional Access for workload identities (Microsoft Learn)

Microsoft named a Leader in the 2026 Gartner Magic Quadrant for AI Agent Management Platforms (Microsoft Security Blog)

PagerDuty unveils Paige, an SRE agent, and the PD Reliability Platform (PagerDuty)

Tekoälyagenttien kyberturvallisuus (Traficom)