Obsidian Security, the industry leader in third-party application and AI security, today announced its Runtime Policy Decision Engine, giving security teams centralized control over AI agent actions before they run. Building on Obsidian’s extensive AI agent discovery and governance coverage, the engine uses context about who is behind an agent, its access and the third-party applications involved to allow or block actions, or require human approval where supported.

Enterprises face agent risk from employees using platforms to write code and initiate workflows, and third-party vendors themselves embedding agents directly into their products. Obsidian’s discovery and governance capabilities span both, covering platforms such as Codex, Claude Code and Cowork, Cursor, Microsoft Copilot, Amazon Bedrock, Google Vertex, n8n, alongside agents built into Snowflake, Databricks, ServiceNow, Workday and other applications. Security teams can identify agents, understand their access and address risky configurations. Putting an agent to work often means accepting some access risk. An agent may legitimately need access to customer records while still needing limits on how it uses them.

Obsidian’s Runtime Policy Decision Engine provides those mitigating controls at the moment an agent acts. It evaluates allowed actions against centrally managed policies, using available identity, employment and application context alongside customer-provided context such as data classification labels. Connected enforcement points allow, block or, mandate human approval for the action where supported. The new MCP Security Proxy checks agent tool calls before they reach business applications, while the new Policy Decision API extends Obsidian’s decision to customer-operated gateways and custom agent tools.

“AI agents have changed the economics of security. An agent can hold valid credentials, use an approved tool and still take an action that costs the business millions,” says Hasan Imam, CEO of Obsidian Security. “We’ve spent years mapping the full chain of authority across the third-party estate. That gives security teams the context whether an agent’s action should proceed based on who is behind it, what third-party applications it can reach and what the data is worth. With Obsidian, policies are defined once and enforced at the moment of action. Defense gets cheaper, mistakes stay contained, and enterprises can move faster on AI.”

New and expanded capabilities

Runtime policy for coding agents now covers OpenAI Codex, joining Claude Code and Cowork. Developers are adopting coding agents faster than guardrails can be put in place, often across several vendors at once. Those agents run with the developer’s access to source code, databases and production systems, and the risky moments happen mid-session: a destructive command, a secret pasted into context, a file read far outside the project. Obsidian’s runtime policy enforcement now extends to OpenAI Codex, so security teams can apply the same policies to Codex, Claude Code and Cowork, and Microsoft Copilot from one console. Developers can continue using their preferred coding tools without friction while security teams maintain oversight across multiple vendors and platforms in one Obsidian console.

Discovery and Governance for agents built into Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow and Workday. The applications enterprises depend on are shipping agents of their own. AI features often arrive switched on, vendors add their own agents, and users can build agents directly in the app — frequently without a security review. Those agents sit closest to the most sensitive data: business data in Snowflake and Databricks, people data in Workday, and operational workflows in ServiceNow. Obsidian now helps security teams identify these in-app agents, maps the identities, tools and data they can reach, and flags risky configurations.

“Most enterprise agents don’t live in one place. They act across SaaS applications, data platforms and developer tools, often built by different vendors. Security teams need a single policy layer that follows agents into each of them, and Obsidian’s coverage of platforms like Workday, ServiceNow, Snowflake and Databricks addresses a real gap.” – Avivah Litan, Former Distinguished Gartner Analyst.

MCP Security Proxy checks every agent tool call before it reaches the app. Agents increasingly reach apps like Salesforce, Slack, Google Drive and Snowflake through MCP servers. Some even hand the AI client an app token directly. Obsidian’s new MCP Security Proxy gives employees and agents a governed layer between the AI client and supported apps. It identifies the user, routes to the correct tenant, keeps the app’s token out of the AI client, and checks each tool call against policy before it runs. Teams can let routine calls through and stop or hold the ones that carry risk, using the same policies that apply elsewhere in Obsidian, with no separate rule set for MCP traffic. Obsidian is partnering with Cloudflare and their MCP Server Portal to provide contextualized and effective policies for agentic access into downstream third-party applications through the Obsidian MCP Proxy.

Customer-provided context makes every decision more precise. What counts as sensitive is defined by each business, and no enforcing tool knows those definitions on its own. Security teams can now supply their own context, such as data classification labels, and Obsidian evaluates it alongside identity, HR and application data. A single policy such as “block Highly Sensitive files for agents acting for anyone outside the Executive team” follows the company’s own definition of sensitive wherever it is enforced. Policies fire only when they should, so the business isn’t blocked and the damaging action isn’t missed.

Context-aware decisions for the custom gateways and harnesses customers already run. Many enterprises route agent traffic through API, AI and MCP gateways. A gateway sees the request, but not who is behind it or what the data is worth, so its rules either block too much or miss the action that does damage. Rebuilding every policy in every gateway’s own format produces copies that drift apart. With the new Policy Decision API, a customer-managed gateway, agent harness or workflow sends each agent action to Obsidian’s Runtime Decision Engine and enforces the decision it receives, along with the reason. Decisions draw on identity, HR, application permission and data context, including labels customers add themselves.

“Enterprises are connecting AI agents to business-critical applications faster than they can write rules for each new tool. Cloudflare sits in the path of that traffic, and the gateway is the right place to enforce policy. But a gateway sees only part of the picture. By connecting Cloudflare to Obsidian’s Policy Decision API, our customers can apply decisions informed by who is behind an agent, what access it holds and what data is involved, at the point where agent traffic already flows. That means stronger control over agent activity without rebuilding the infrastructure they rely on.” — Kenny Johnson, Principal Product Manager, Security, Cloudflare.

Additional resources

Blog post: obsidiansecurity.com/blog/discovery-to-runtime-ai-agent-security.

Explainer video: https://www.youtube.com/watch?v=sEsvlJBAk1c

About Obsidian Security

Obsidian Security secures the AI-first enterprise, governing data, AI and agents inside third-party applications. Trusted by Fortune 1000 and Global 2000 enterprises, Obsidian gives security teams visibility into what’s connected, controls to enforce what’s allowed, and the runtime context to govern AI and agent activity before it causes damage inside critical business systems. Headquartered in Palo Alto, California, Obsidian is backed by Crescent Cove Advisors, Menlo Ventures, Norwest Venture Partners, IVP, Greylock, GV, and Wing. For more information, visit www.obsidiansecurity.com.

Media gallery

About The Author
Business Wire