Obsidian Becomes Runtime Gatekeeper
Obsidian Security
This shifts Obsidian from seeing agent behavior to deciding whether work actually happens. Once a security product sits in the live action path, it can block a Copilot or Claude agent before it sends data, changes permissions, or triggers a destructive workflow. That makes Obsidian part control plane, part gatekeeper, which raises product value because every protected action becomes a place to sell policy, approvals, and deeper governance.
-
The product surface gets much bigger at runtime. Discovery tells a security team which agents exist and what apps they can reach. Enforcement adds the ability to stop an agent mid task, which is the difference between logging a risky Salesforce export and preventing it from going through.
-
The clearest comparable is the jump from testing tools to operational controls. Promptfoo points toward always on guardrails, but Obsidian is already live in production enforcement for Claude and Microsoft Copilot. That puts it closer to the budget owners that buy email security gateways or identity policy engines, not just monitoring dashboards.
-
Coverage breadth matters because the transaction base is fragmented across agent stacks. Obsidian already claims discovery across Bedrock, Vertex, Agentforce, ChatGPT, n8n, and others, while Salesforce and AWS are each building their own agent execution layers. The winning independent vendor is the one that can apply one policy fabric across all of them.
The next step is turning runtime security into default infrastructure for enterprise agents. As agent counts rise and EU AI Act enforcement now requires stronger records and controls, the vendor that can inventory agents, show ownership, and prove why a live action was allowed or blocked will move from optional monitoring spend to mandatory operating software.