Obsidian Security Launches Runtime Policy Engine to Control AI Agent Actions

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.

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. Connected enforcement points then allow or block the action, or require approval where that capability is supported.

From Discovering Agents to Controlling Their Actions

Agent discovery answers which tools are present and what they can reach. Governance can reduce unnecessary permissions or identify risky configurations. Runtime policy addresses the remaining question: what should an otherwise authorized agent be allowed to do right now?

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.

These are different control surfaces. Finding an agent inside a SaaS application does not by itself mean every action in that application is intercepted. Runtime enforcement depends on the supported integration and the point through which an action passes.

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.

The Knowledge Graph Supplies the Missing Context

A gateway can inspect a request, but the request alone may not explain the authority behind it. A useful security decision may require knowing whether the invoking account belongs to an employee or contractor, whether employment has ended, and which permissions the account actually holds in the destination application.

Obsidian’s Knowledge Graph architecture connects people, accounts, applications, tokens, entitlements, and their relationships. The company describes normalizing information from administrative APIs, activity streams, and integrations into a common model, with versioned entities and relationships to capture changes over time.

That structure helps trace access across multiple systems rather than examining each account in isolation. An agent’s apparent role may be narrow while a token or inherited entitlement gives it broader reach elsewhere. Connecting those relationships gives the policy engine a stronger basis for deciding whether a particular action fits the organization’s rules.

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.

Where the Decision Becomes Enforcement

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.

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.

Obsidian also documents a flag mode for testing policy matches against real traffic before blocking operations. 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.

Approval support is narrower than the overall allow-or-block architecture: the company’s current documentation says requiring approval is available for Claude Code policies that run before an operation. That makes integration-level capabilities important when designing controls for a mixed fleet of agents.

The MCP Proxy Keeps Application Tokens Out of AI Clients

The MCP Security Proxy governs connections between AI clients and supported business applications. Model Context Protocol, or MCP, gives agents a standard way to call tools exposed by external servers. Obsidian places a policy check between the client and the application’s MCP server.

Its product documentation describes replacing the vendor’s direct MCP URL with an Obsidian-governed endpoint. Users authorize access through the application vendor’s consent flow; the AI client receives a proxy-issued token instead of storing the application’s access token itself.

The proxy maps a session to the user, their application account, and the relevant tenant, such as a particular Salesforce organization or workspace. It checks tool calls before forwarding them and records whether they were allowed or blocked. Obsidian says this operates within the user’s existing application permissions rather than adding privileges through a shared service account.

The announcement also identifies a collaboration with Cloudflare and its MCP Server Portal. The objective is to combine a gateway’s position in the traffic path with Obsidian’s identity, application, and data context.

Why Action-Level Controls Matter

For enterprises deploying agents, the practical challenge is permitting useful work while containing consequential mistakes. A blanket ban can stop a workflow entirely; a narrowly scoped decision can let routine reads proceed while stopping an unauthorized export or requiring review of a destructive change.

Obsidian is bringing those decisions into a shared policy layer across supported tools and enforcement points. The value will depend on the quality of the underlying access context and the completeness of the paths under control. As agents gain more operational responsibility, the ability to explain and enforce a decision before execution becomes an increasingly important part of enterprise security.