Obsidian Security and AI agent monitoring expose auth gaps

At a glance

What this is: This is WorkOS’s comparison of Obsidian Security’s AI agent monitoring to foundational authentication infrastructure, with the core finding that behavioural visibility only works after access is already granted.

Why it matters: IAM, PAM, and NHI teams need to separate post-authentication observability from the identity controls that issue, scope, and govern access for AI agents in production.

Context

AI agent monitoring is useful only after an identity has already crossed the authentication boundary. In production environments, that means observability can tell you what an agent did inside SaaS applications, but it cannot by itself prevent excessive privileges, weak federation, or missing lifecycle controls at issuance time.

This article uses Obsidian Security as the comparison point and WorkOS as the authentication baseline to show a broader governance problem: teams are treating runtime monitoring as if it were identity control. For AI agents, the control plane has to include authentication, authorisation, and auditability before behavioural detection can add value.

Key questions

Q: What breaks when AI agent monitoring is treated as an authentication control?

A: Access governance breaks because the organisation learns what the agent did, but not whether the agent should have been able to enter in the first place. Monitoring can support detection and investigation, but it cannot narrow delegated scope, enforce identity proofing, or prevent over-permissioned access from existing.

Q: Why do AI agents increase risk in SaaS environments?

A: AI agents increase risk because they can operate through existing application permissions and continue using them as tasks change. That turns delegated access into a broader governance problem, especially when the permissions were never reviewed for non-human use. The result is a larger blast radius from the same underlying grant.

Q: How should security teams measure whether AI is helping rather than hiding risk?

A: Security teams should measure AI using outcome metrics that include access scope, session length, revocation speed, and auditability. Productivity alone can look positive while identity risk grows underneath it. A useful scorecard ties AI output to the controls that bound its privilege and prove who or what acted at runtime.

Q: What is the difference between agent observability and agent authorisation?

A: Agent observability shows what an identity did after access began, while authorisation decides whether that identity should have had access and how much. In production, authorisation is the preventive control and observability is the detective one. They solve related problems, but they are not interchangeable.

Technical breakdown

Why post-authentication monitoring cannot enforce agent access boundaries

Behavioural monitoring records what an AI agent does after login, but it does not determine whether the agent should have been able to log in, what scope it should receive, or whether its permissions are appropriate for the task. In identity terms, that is observability, not authorisation. For AI agents in SaaS environments, the risk is that excessive scope is already present before anomaly detection ever sees activity. Monitoring can flag misuse, but it cannot shrink the original trust envelope that was granted at authentication time.

Practical implication: Treat agent monitoring as a detection layer, not as a substitute for access issuance controls.

How OAuth, SSO, and directory sync shape agent identity governance

AI agents that operate through SaaS platforms inherit the same federation and provisioning dependencies as enterprise users, but at machine speed and often with broader automation scopes. SSO establishes the trust relationship, directory sync governs account lifecycle, and OAuth or OpenID Connect determine how delegated access is minted and refreshed. If those layers are weak, monitoring simply observes a flawed identity model in motion. The architectural issue is not that agents are invisible, but that they are already trusted before runtime analysis begins.

Practical implication: Align agent deployment with federation and lifecycle controls before layering on behavioural tooling.

The observability and authorisation boundary is now the governance seam

The article’s central architectural lesson is that SaaS security for AI agents splits into two distinct control domains: who can obtain access, and what that access can do once active. Obsidian Security sits in the second domain. WorkOS represents the first. Organisations that blur those layers will overestimate their protection because they can see suspicious behaviour without being able to prevent the underlying entitlement from existing. That creates a governance seam where agent privilege can outrun policy.

Practical implication: Map every agent control to either issuance governance or runtime detection, and close the gap between the two.

Threat narrative

Attacker objective: The objective is to obtain and abuse agent-level SaaS access in a way that blends into legitimate activity while bypassing meaningful access governance.

1. Entry occurs when an AI agent is granted SaaS access through federation or delegated credentials that are already too broad for its task.
2. Escalation follows when the agent inherits or accumulates permissions across SaaS systems faster than teams can review or constrain them.
3. Impact emerges when the agent reaches sensitive data, downloads large volumes, or behaves anomalously inside business systems without preventive identity controls.

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 and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication and observability are different control planes, and conflating them weakens both. Behavioural monitoring can improve visibility, but it does not issue trust, narrow scope, or govern access lifecycles. For AI agents, the control that matters first is whether the identity boundary was safe enough to permit access at all. Practitioners should treat runtime visibility as supplementary rather than foundational.

AI agent identity inherits the same federation risks as human identity, but at a faster operational tempo. SSO, MFA, directory sync, and delegated authorisation all still matter, yet agents can execute, mutate state, and access data before a human review cycle ever catches up. That makes the access issuance model itself the real governance problem. Teams need to recognise that SaaS-visible behaviour is downstream of identity trust.

Obsidian Security exposes a monitoring layer, not a complete agent governance model. That distinction is important because many programmes buy detection to compensate for unfinished identity architecture. In an AI agent context, the missing capability is not more telemetry but tighter control over how trust is established, scoped, and revoked. The implication is that enterprises must stop treating post-login detection as a surrogate for authorisation design.

Runtime anomaly detection cannot correct over-permissioned delegation. If an agent is allowed to enter with excessive scope, the monitoring platform can only tell you that the mistake happened. The real security boundary is the delegated entitlement itself, especially where SaaS integrations and OAuth grants are involved. Security teams should reframe the problem as access governance for non-human actors, not visibility into their behaviour alone.

Identity blast radius is now the better metric than visibility coverage. The article points to a named concept that many teams miss: the gap between what an AI agent can authenticate into and what it should be allowed to touch. Once that blast radius is large, monitoring may help investigations, but it does not meaningfully reduce initial exposure. Practitioners should govern agent access scope before they optimise for detection fidelity.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Authorisation Guide

What this signals

Identity blast radius: AI agent programmes fail when teams can watch behaviour but still cannot constrain delegated scope at issuance time. That is why the governance question is no longer whether agents are visible, but whether their initial trust envelope is small enough to be defensible.

The strongest programmes will separate detection from decision-making. Runtime monitoring helps with anomaly response, but the access model, lifecycle model, and authorisation design still have to stand on their own before any agent is allowed into production systems.

For practitioners

• Define the agent authentication boundary Separate the systems that mint access from the systems that observe usage, and assign ownership for both. If an AI agent can enter SaaS applications before its scope is explicitly reviewed, the problem is identity governance, not monitoring coverage.
• Constrain delegated SaaS permissions Review OAuth grants, app scopes, and integration tokens for every AI agent and remove any access that exceeds the minimum task requirement. Behavioural tools should then validate whether those scopes are being used as intended.
• Add lifecycle controls for machine identities Put AI agents into the same joiner-mover-leaver discipline used for other non-human identities so access is revoked when the workload, workflow, or owner changes. Directory sync and provisioning need explicit offboarding paths.
• Use observability for detection, not approval Keep SaaS monitoring in place for anomaly detection, but do not let it stand in for authorisation review, entitlement design, or identity proofing. The platform should confirm behaviour after access, not justify access itself.
• Instrument high-risk integrations first Prioritise the AI agents and SaaS integrations that can touch finance, customer data, or admin controls, then baseline those identities before expanding to lower-risk workflows. That sequencing reduces the likelihood of discovering overreach only after impact.

Key takeaways

• AI agent monitoring improves SaaS visibility, but it does not replace authentication or authorisation controls that define what the agent can reach.
• The main risk is over-granted delegated access, because observability only detects misuse after the identity boundary has already been crossed.
• Practitioners should govern AI agents through issuance controls, lifecycle management, and scoped federation before relying on behavioural detection.

Key terms

• Agent observability: Agent observability is the collection and correlation of traces, logs, metrics, and evaluations across an AI agent’s execution path. It explains what happened during model calls, tool use, handoffs, and downstream effects, but it does not itself authorize, deny, or revoke access.
• Authentication boundary: The point in an application where identity is checked and access decisions begin to matter. In practice, this boundary may sit in the browser, middleware, or server. The safer design is usually the one that keeps enforcement closest to the protected resource.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 building or maturing an IAM programme, it is worth exploring.