What happened
Obsidian Security has launched a Runtime Policy Decision Engine designed to let enterprises control what AI agents do inside business applications before an action executes. The announcement expands the company’s agent-security platform with an MCP Security Proxy, a Policy Decision API, and additional coverage for coding tools and agents embedded in third-party software.
Obsidian’s announcement covers both employee-operated agents and agents arriving inside software the enterprise already uses.
Its expanded discovery and governance capabilities include Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow, and Workday.
The company also added runtime policy support for OpenAI Codex alongside its existing coding-agent controls.
Its announcement identifies risks such as destructive commands, credential exposure, and reads outside a project’s intended scope—actions that can occur during an otherwise legitimate development session.
Customers can add their own context, including classification labels. A policy can therefore distinguish an ordinary file from one the business designates highly sensitive, rather than relying solely on a security vendor’s generic definition of confidential data.
Why it matters
The launch addresses a problem that ordinary access controls do not fully resolve: an agent can hold valid credentials and use an approved application while still attempting an inappropriate action. Permission to read customer records, for example, does not necessarily mean permission to export them to an external destination. Obsidian’s approach is to evaluate the proposed action against centrally managed policies, using the person behind the agent, their employment and permissions, the application involved, and customer-supplied data classifications.
The launch addresses a problem that ordinary access controls do not fully resolve: an agent can hold valid credentials and use an approved application while still attempting an inappropriate action.
Obsidian’s approach is to evaluate the proposed action against centrally managed policies, using the person behind the agent, their employment and permissions, the application involved, and customer-supplied data classifications.
The company’s Knowledge Graph architecture connects people, accounts, applications, tokens, entitlements, and their relationships.
The architecture separates deciding from acting. In Obsidian’s runtime-engine explanation, an enforcement point pauses a proposed operation, submits its details for evaluation, and applies the returned decision and reason.
Decision records capture the agent, invoking person, tool, arguments, outcome, and matching policy, giving security teams a way to investigate why an action was allowed or stopped.
Interactive Mechanism: How It Actually Works
Explore the underlying technology behind this development interactively.
crm_get_transaction(id='4092').An agent must create a draft calendar event for Tuesday at 2 p.m. Which evidence would establish the requested result?
What to watch next
The new Policy Decision API extends that model to customer-operated gateways, agent harnesses, and workflows. An enterprise can retain its existing infrastructure while asking Obsidian for a context-aware verdict. The customer’s enforcement component must then apply that verdict before the operation proceeds.
The new Policy Decision API extends that model to customer-operated gateways, agent harnesses, and workflows.
An enterprise can retain its existing infrastructure while asking Obsidian for a context-aware verdict.
The customer’s enforcement component must then apply that verdict before the operation proceeds.
Approval support is narrower than the overall allow-or-block architecture.
The MCP Security Proxy governs connections between AI clients and supported business applications.