HEAD-TO-HEAD

A gateway governs the calls that route through it. Much of the agent activity that matters never does. When a team builds an agent inside Salesforce Agentforce or Microsoft Copilot Studio, that agent reaches Salesforce, ServiceNow, Workday, and M365 through OAuth tokens and service accounts issued by the platform, not through an external AI gateway. Obsidian connects to those applications natively and reads the activity, permissions, and identity context inside them, so coverage does not depend on where the traffic was routed.

Both enforce at runtime. The difference is what each policy reads when it fires. Gateway-side runtime can control what an agent sends and receives at the model or tool-call level. Obsidian extends runtime decisioning with SaaS state, identity, and permissions, so policies can be more specific over time: for example, don't touch a file in OneDrive labeled sensitive, when the agent was built by a specific user, calling on behalf of a specific identity. That granularity comes from reading the receiving app's state and identity context, not just the traffic in flight.

Inventory is only the starting point. Obsidian shows who built the agent, who ran it, and what the service account inside the SaaS app is permissioned to do. That gives defenders the context to understand which agents create real business risk and align configuration to that risk.

You can, and the overlap is smaller than it is with agent-platform tools. Onyx sits on AI traffic. Obsidian sits inside the SaaS applications agents act on. The question worth asking is which layer your risk actually lands in. If the concern is what a model returns, gateway inspection helps. If the concern is what an agent did to records in Salesforce or Workday, that answer lives in the application.

No, and we don't claim to. Obsidian does not run simulated attacks against AI systems and does not filter prompt-level manipulation in the core platform. Obsidian's layer is what happens after an agent acts: which identity it used, what it was permissioned to reach, what it touched inside the connected application, and whether that action should have been allowed. Teams that want adversarial testing of model behavior should buy for that separately. Teams that need to know an agent's blast radius across their SaaS estate should evaluate Obsidian.

Posture detection tells you an agent looks risky. By the time a posture finding lands, the agent has often already executed. Runtime enforcement fires at the tool call, before the action completes. The remaining question is what each runtime can read: agent inputs and outputs alone, or also the SaaS state and identity context that decide whether the action is actually risky.

99.99% uptime over the last 12 months. Regional hosting across the US, Europe, Saudi Arabia, and Australia. Granular RBAC scoped per app. Production-safe connectors with bulk-API support. Obsidian connects to your most critical SaaS apps and collects activity data without disrupting them. Learn more about our certifications and attestations.

These come from real customer environments, including customers who have evaluated Onyx and Obsidian.

Most teams evaluating this category run three or four vendors side by side. We publish the same head-to-head breakdown for Zenity, Noma, Geordie, Harmonic, and the SaaS security platforms agents run on top of. The through-line is the same in every one: agent-layer tools read the agent, and Obsidian reads the application the agent acts on. Which matters more depends on where your risk actually lands.