Free-roaming AI agents are exposing identity control assumptions

At a glance

What this is: This blog argues that free-roaming AI agents can reveal identity control gaps that static configuration checks miss, especially where SSO is treated as enforced when it is only available.

Why it matters: It matters because IAM teams need to validate how authentication actually behaves across SaaS boundaries, not just whether controls appear enabled in one system.

Context

The core problem is not a missing identity control, but an assumption that enforcement is consistent across systems when it often is not. In large SaaS estates, SSO, MFA, fallback login paths, and transitional states can combine into behaviour that looks compliant in configuration but is not compliant in practice.

For identity governance, that means the real control boundary is the interaction between the identity provider and each service provider. When authentication semantics differ by application, human review and point-in-time checks can miss the gap entirely; behavioural validation becomes the more reliable way to test whether the programme matches operational reality.

Key questions

Q: How should security teams validate that SSO is truly enforced?

A: Validate SSO at the relying application, not only in the identity provider. Check for local login, password fallback, test modes, and mixed-auth states, then correlate application audit logs with IdP sign-ins. If a user can authenticate without the IdP being involved, SSO is available but not enforced.

Q: Why do identity control assumptions fail in multi-SaaS environments?

A: Because authentication is often split across systems that do not share the same enforcement rules. An identity provider can require MFA and issue assertions, but the application may still allow alternate login methods. That gap creates security risk without violating any single system’s documented setting.

Q: What are the signs that authentication is drifting away from the security model?

A: Look for mismatches between intended SSO membership, identity-provider sign-ins, and native application login events. If users who should authenticate through the IdP are absent from IdP logs but active in the application’s audit trail, enforcement is probably not consistent.

Q: How can teams reduce blind spots created by distributed authentication?

A: Use behavioural validation to compare expected access patterns with actual authentication events across systems. The goal is not to review more settings, but to prove that the same identity policy produces the same runtime outcome in every application that matters.

Technical breakdown

Why SSO behaves like a contract, not a hard control

Single Sign-On only enforces security when the service provider requires it. The identity provider can issue MFA-backed assertions and conditional access decisions, but the application still controls whether local passwords, legacy credentials, or alternate paths remain valid. That makes SSO a distributed agreement between systems, not a single switch that guarantees authentication flow. In practice, this means control strength depends on both sides of the trust relationship and on whether fallback behaviour has been disabled.

Practical implication: validate enforcement on the application side, not just in the identity provider.

How unknown-unknowns appear in authentication telemetry

Unknown-unknowns are gaps that produce no policy violation, no failed login, and no obvious alert because the expected evidence simply never appears. In the article’s example, users were present in the intended SSO group but absent from identity-provider sign-in logs, then visible in the application’s own audit trail. That cross-system mismatch is the signal. The technical lesson is that the absence of an expected event can be more important than a noisy denial event when authentication is split across vendors.

Practical implication: correlate identity-provider logs with application audit logs to find silent authentication bypass paths.

Why behavioural validation outperforms configuration checks

Configuration checks answer whether a setting exists. Behavioural validation answers whether the setting changes runtime identity behaviour. For identity systems that span multiple SaaS applications, the second question matters more because enforcement can be optional, transitional, or application-specific. Free-roaming AI agents are useful here because they can compare expected authentication patterns with observed ones across systems and surface contradictions that static policy review would miss.

Practical implication: test actual login behaviour across systems rather than relying on documented configuration state.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity control failures increasingly arise from broken assumptions, not broken settings. The article is a reminder that IAM teams often inherit a false equivalence between configuration and enforcement. When authentication is distributed across an identity provider and a service provider, the control boundary is behavioural, not administrative. Practitioners should treat assumption drift as a first-class identity risk, because the weakest point is often the place where two systems disagree about what should happen.

Free-roaming AI agents are most valuable when the security question is observational, not prescriptive. They are not simply another automation layer. Their value is in moving across trust boundaries, comparing expected and actual authentication behaviour, and surfacing contradictions that no single console exposes. That makes them especially relevant for NHI governance where control evidence is fragmented across products and logs.

Unknown-unknowns create a distinct governance problem that traditional access reviews do not solve. Access reviews certify who should have access, but they do not prove how that access is actually exercised across SaaS applications. The named concept here is identity control assumptions: security teams often assume that enabling SSO in one place means SSO is enforced everywhere. That assumption fails when the application still allows alternate authentication paths, and the implication is that governance must shift from declarative configuration to observed identity behaviour.

Cross-system authentication drift becomes the more accurate risk model than misconfiguration. The article shows that a system can appear correct inside its own console while producing insecure behaviour elsewhere. That makes the operational question not whether a setting exists, but whether the security outcome survives interaction with downstream applications. Practitioners should reframe identity assurance around end-to-end behaviour, not isolated control ownership.

Runtime identity verification is becoming a programme requirement, not an optimisation. Large SaaS estates accumulate transitional states, legacy paths, and application-specific exceptions that static controls cannot fully model. The field needs a stronger discipline around continuous behavioural validation across identity boundaries. The implication for practitioners is to re-evaluate where evidence comes from, because the most dangerous gaps are often invisible to the system that owns the control.

From our research library:

• Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
• Read next: Agentic AI Security Guide

What this signals

Cross-system authentication drift: programmes that rely on a single control plane will keep missing behaviour that only appears when identity events are compared across providers. The operational fix is not another dashboard, but a stronger evidence model that tests whether authentication outcomes survive application-level exceptions.

As SaaS estates expand, behavioural validation becomes the practical response to identity systems that can look compliant in one console and permissive in another. That shifts the practitioner focus from settings management to evidence correlation, especially where fallback paths and transitional states still exist.

For practitioners

• Validate SSO enforcement in the application console Confirm that each critical SaaS application actually blocks local passwords and alternate login paths, rather than assuming identity-provider configuration is sufficient.
• Correlate sign-in and application audit logs Compare identity-provider sign-in activity with native application login events to detect cases where expected SSO activity never appears.
• Test fallback authentication paths directly Probe for password-based login, legacy credentials, transitional test states, and temporary bypass modes that can persist after SSO rollout.
• Deploy behavioural validation for identity assumptions Use automated exploration to check whether authentication outcomes match the security model across vendor boundaries and release changes.

Key takeaways

• The article’s central finding is that identity risk can hide in control assumptions even when SSO and MFA appear to be configured correctly.
• The most important evidence is the mismatch between intended SSO use and actual application-side login behaviour across systems.
• Practitioners need to validate enforcement through observed authentication behaviour, because configuration state alone does not prove security outcome.

Key terms

• Identity Control Assumptions: The expectations security teams hold about how authentication and access should behave across systems. In practice, these assumptions often sit above the actual enforcement points, so a programme can look correct while users still follow alternate paths that weaken the intended control.
• Unknown Unknowns: Applications or identity flows that exist in the environment but remain outside security visibility. They are more dangerous than known gaps because they bypass inventory, review, and monitoring processes, leaving no reliable basis for governance or remediation.
• Behavioral validation: A security method that compares intended access policy with actual system behaviour. Rather than checking whether a setting exists, it correlates logs, events, and application states to prove that access happens the way the organisation believes it does.
• Cross-System Authentication Drift: The situation where authentication behaves differently from one platform to another even though the organisation believes a single policy applies. This often happens when identity provider settings and application-side enforcement are not aligned, creating silent exceptions that are hard to detect.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.