Your tenant is full of app registrations and service principals. Some you created, some a vendor created, some have been there since a migration nobody documented, and more and more of them now sit behind the AI agents and automations your teams are building. They authenticate, they hold Graph permissions, and most are secured with a client secret because that was the fastest path at the time.

This session goes after the uncomfortable part. A client secret can be added to a service principal through the Graph API and never appear in the Entra admin center. We do it live, look at the object from the portal and Graph side by side, and work out what your audit trail does and does not tell you afterwards.

Then we build the controls, in the order they were rolled out in real tenants. App Management Policies at tenant and per-application scope, with the same Graph call failing once the policy holds, plus the exclusion behaviour that decides whether it holds at all. Federated credentials and managed identities as the default for anything that can use them, and what you do for the vendor integrations that cannot. Conditional Access for Workload Identities as the layer controlling where a service principal may authenticate from.

Rollout experience included: what breaks when you enable App Management Policies in a tenant that has been running for years, how to find out what will break before it does, and the conversations with application owners that come with it. We close on detection, and which signals are actually worth alerting on.

For identity architects and security engineers who own an Entra tenant and want controls they can apply in production the same week, before the next wave of agents adds another hundred service principals.