TL;DR: Obsidian Security’s AI agent monitoring adds behavioural visibility to SaaS environments, but its own framing shows that observability after authentication cannot replace the identity controls agents need in production, according to WorkOS. The real issue is the gap between access granting and access governance, where AI agents inherit SaaS permissions before security teams can meaningfully constrain or verify them.
NHIMG editorial — based on content published by WorkOS: Obsidian Security for AI Agent Security: Features, Pricing, and Alternatives
By the numbers:
- The platform's free plan supports up to 1,000 users and the advanced plan requires a custom quote.
- WorkOS offers a 99.99% uptime SLA, dedicated support channels, and white-glove onboarding.
Questions worth separating out
Q: How should security teams govern AI agent access in SaaS environments?
A: They should treat AI agents as non-human identities with explicit ownership, narrow permissions, and lifecycle control.
Q: Why do AI agents change the identity risk model for SaaS applications?
A: AI agents can access data and invoke actions at machine speed, which makes delayed review cycles less effective.
Q: What do teams get wrong about AI agent monitoring?
A: They often confuse visibility with control.
Practitioner guidance
- Separate detection from entitlement control Use behavioural monitoring for anomaly detection, but keep access issuance, revocation, and session termination inside a governed identity plane with clear ownership.
- Map every AI agent to an identity owner Assign a named owner for each agent credential, integration, and SaaS permission set so audit, recertification, and offboarding are not ambiguous.
- Review SaaS permissions before adding monitoring Verify the minimum access needed for each agent, then remove broad scopes such as unnecessary read access to shared mail, files, and CRM records.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- A side-by-side feature comparison of Obsidian Security and WorkOS across SSO, SCIM, audit logging, and agent monitoring.
- Implementation discussion of how agentless SaaS monitoring fits into enterprise identity architecture.
- Pricing and packaging details for Obsidian's free and advanced plans, including procurement implications.
- Product-level commentary on where observability ends and authentication infrastructure begins.
👉 Read WorkOS's analysis of Obsidian Security and AI agent identity risk →
AI agent monitoring and the authentication gap teams miss?
Explore further
Observability after authentication is not identity governance. Obsidian Security’s model is built to watch behaviour once access already exists, which is useful but structurally incomplete for agent security. The central governance issue is that access can be granted too broadly before monitoring ever starts. For agentic programmes, this means the control plane must be owned by identity teams, not just by security telemetry teams.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
A question worth separating out:
Q: What is the difference between authentication infrastructure and agent observability?
A: Authentication infrastructure establishes identity, sessions, and permissions. Agent observability records and analyses what happens after access is already in place. For production AI systems, observability is useful for detection, but authentication infrastructure is the control that determines whether the agent should have had access at all.
👉 Read our full editorial: Obsidian Security and AI agent monitoring expose auth gaps