Announcing Industry’s First Context-Aware Runtime Decision Engine to Enforce AI Agent Actions

❮ Back to blog
AI Security

From discovery to runtime enforcement: Obsidian expands AI Agent Security across your third-party apps

Discover more agents. Centralize policies. Enforce decisions where agents act.

Obsidian is expanding AI Agent Security with discovery and governance for agents built into your third-party apps, a new Runtime Policy Decision Engine, and enforcement across Codex, MCP connections and the gateways you already run.

Published:
November 10, 2026
Updated:
November 10, 2026
10 min read

AI agents are everywhere. Developers are building with Claude Code and Codex. Business teams are experimenting with Copilot Studio. And the third-party apps you've already approved are quietly introducing agents of their own.

For most security teams, the immediate priority has been discovery and governance. Find the agents, understand what they can access, and rein in unnecessary permissions. That's a good start. But with agents increasingly acting autonomously, knowing what they can do is only half the battle. Security teams also need to control what they actually do.

Obsidian already helps organizations discover and govern agents across Claude Code, Claude Cowork, Microsoft Copilot, Amazon Bedrock, Google Vertex AI and n8n. Today, we're building on that foundation, extending visibility to even more agents and introducing a new way to make and enforce security decisions at runtime.

The goal is simple: Give security teams the confidence to say yes to more AI, without giving up control of what agents do.

What’s new at a glance

Layer What’s new Read more
Discover and govern Discovery and governance for agents built into Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow and Workday; Codex discovery and risk analysis App-native AI agents
Decide Runtime Policy Decision Engine; customer-provided context; Policy Decision API Runtime Policy Decision Engine
Enforce Runtime enforcement for OpenAI Codex; MCP Security Proxy, with Cloudflare’s MCP Server Portal; enforcement through your own gateways and agent harnesses OpenAI Codex, Claude Code and Cowork, MCP Security Proxy

The AI agent security challenge is bigger than discovery

AI agents are changing how work gets done. They're also changing what it takes to secure the enterprise.

First, agents are showing up in places you may not be looking.

There are two sources of AI agents to worry about:

  • The ones employees connect to your apps through coding tools and AI platforms
  • The ones vendors are building directly into the applications you already use

The second group is particularly easy to miss. Salesforce, Snowflake, Databricks, ServiceNow and Workday are all introducing AI capabilities into their platforms. Your organization may have approved these applications years ago, but that doesn’t mean security has reviewed every new agent that comes with them.

Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025. That’s a lot of new agents potentially sitting next to your most sensitive business data.

Second, AI agent policies are fragmented, if they exist at all.

Finding an agent is one thing. Deciding what it should be allowed to do is another. An agent might legitimately need access to customer records without needing permission to export the entire customer database. But today, each agent platform, MCP connection and gateway comes with its own controls, if it has them at all.

Security teams end up recreating the same rules across different tools. And when those rules drift apart, an agent can reach the same sensitive data through a less-protected route.

Third, agents are built to finish the job, not necessarily follow your rules.

Unlike traditional software, AI agents don’t always follow a predictable script. They’re designed to accomplish a goal, and when one path doesn’t work, they may try another. That makes instructions written into prompts a weak security boundary.

In February 2026, an OpenClaw agent reportedly ignored an instruction to wait for approval before cleaning an inbox. After losing that instruction during context compaction, it proceeded to delete hundreds of emails.

The lesson? You can’t rely on an agent to enforce the rules it’s supposed to follow. Controls need to sit at the point where an agent’s action reaches your applications.

Finally, stopping the wrong action requires more than knowing the agent.

An agent can have valid credentials, use an approved tool and still do something disastrous:

  • Delete a production table
  • Export sensitive customer records
  • Grant administrative access to the wrong person

To make the right decision, security needs context:

  • Who is behind the agent?
  • Are they an employee or contractor?
  • What permissions does the agent have?
  • Which application is it accessing?
  • How sensitive is the data?
  • What’s the potential impact of the action?

This is where Obsidian’s years of investment in third-party application security make a difference. With 250+ third-party app connectors and a Knowledge Graph that maps identities, permissions, integrations, tokens, agents and activity, Obsidian understands the full chain of authority behind an action. And because that context is continuously updated, a decision can account for changes in employment status, permissions and application access, not just whether a session is valid.

That’s why we’re excited about what we’re announcing today. We’re bringing together our investments in agent discovery, governance, third-party application intelligence and runtime enforcement to help security teams move from simply knowing their agents to controlling what those agents do.

What's new: From discovering agents to controlling their actions

Today, we’re introducing new capabilities across three critical layers of AI Agent Security:

  • Discover and govern agents
  • Decide what actions are allowed
  • Enforce those decisions at runtime

Together, they give security teams a consistent way to secure AI agents across coding environments, AI platforms, MCP connections, third-party applications and their own infrastructure.

Context from your apps, identity systems and your own labels feeds one Policy Decision Engine; each enforcement point applies its decision before the agent’s action reaches the app.

Discovery and governance

Find the agents you didn’t know you had

You can’t secure an agent you don’t know exists. And increasingly, those agents aren’t just coming from your employees. They’re arriving inside the applications your business already trusts. We’re expanding Obsidian’s existing AI agent discovery and governance coverage with two major additions.

Discovery and governance for agents built into third-party apps. Obsidian now discovers AI agents built into Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow and Workday. For each agent, security teams can see:

  • Who’s behind it
  • What applications, tools and data it can reach
  • Which configurations create unnecessary risk

That includes agents introduced by vendors as well as agents employees build inside those applications, often without a separate security review.

Codex discovery and risk analysis. We’re extending our existing coverage of Claude Code, Claude Cowork, Microsoft Copilot, Amazon Bedrock, Google Vertex AI and n8n to include OpenAI’s Codex. Security teams can discover Codex agents, understand their access and identify risky configurations, just as they can with other supported AI platforms.

The result is broader visibility across both sides of the AI agent landscape: agents employees bring into the business and agents that arrive through third-party applications.

Read more: Obsidian now discovers and governs the AI agents built into your third-party apps

Policy decisions

One set of policies. Thousands of agents. Across your agent platforms.

Discovery tells you what an agent can reach. Governance helps limit that access. But what happens when an agent with legitimate access attempts something it shouldn’t? That’s where our biggest announcement comes in.

Runtime Policy Decision Engine. The first of its kind in the market, the runtime policy decision engine gives your security teams a central decision layer for AI agent actions across third-party applications. Instead of rebuilding rules for every agent platform, you can now define your policies in Obsidian. When an agent attempts an action, the engine evaluates it against those policies using context from the Obsidian Knowledge Graph.

It considers:

  • The person behind the agent
  • Their permissions
  • The applications involved
  • The requested action
  • The sensitivity of the data

It then returns a decision: allow, block or require approval where supported, along with the reason. For example:

  • An agent may be allowed to query a Snowflake table but blocked from deleting it.
  • A contractor’s agent may be prevented from exporting sensitive customer records, even when its credentials are valid.

Every decision is logged, giving security teams a record of which actions were evaluated and which policies were applied.

Customer-provided context. What counts as sensitive is defined by your business, and no enforcing tool knows that on its own. You can now add your own context, such as data classification labels, and use it to build agent policies specific to your business. A policy such as “block Highly Sensitive files for agents acting for anyone outside the Executive team” then follows your own definition of sensitive data.

Policy Decision API. Already running your own AI gateways, MCP gateways, agent harnesses or workflows? Keep them. With the new Policy Decision API, your existing infrastructure can send agent actions to Obsidian’s Runtime Policy Decision Engine and apply the decisions it returns. Your platform team keeps the tools and infrastructure it has built. Your security team gets consistent policies across them, including for agents without a native Obsidian connector.

Read more: Introducing the Runtime Policy Decision Engine: control thousands of AI agents with one set of policies

Runtime enforcement

Stop risky actions before they reach your apps

A policy is only useful if it can be enforced. AI agents won’t all run on the same platform, and enterprises shouldn’t have to standardize on one tool to secure them. That’s why we’re expanding runtime enforcement across coding agents, MCP connections and the gateways your teams already operate. Each enforcement point uses decisions from the same Runtime Policy Decision Engine.

Enforcement point Where agents run How it enforces
Endpoint sidecar Claude Code, Cowork and Codex Checks each tool call before it runs
Platform webhook Microsoft Copilot Studio Copilot Studio asks the engine before an agent acts
MCP Security Proxy Any MCP client, including traffic through Cloudflare’s MCP Server Portal Checks each tool call before forwarding it to supported apps
Your gateways and harnesses Customer-managed gateways, agent harnesses and workflows Sends each agent action to the engine through the Policy Decision API

Runtime enforcement for OpenAI Codex. Building on existing enforcement for Claude Code and Claude Cowork, Obsidian now brings runtime policy enforcement to Codex. A lightweight sidecar checks tool calls before they execute, allowing security teams to block risky actions without disrupting legitimate development.

Whether an agent attempts to:

  • Delete a production table
  • Access secrets outside its project
  • Perform an unauthorized operation

Obsidian can evaluate the action against enterprise policy before it runs. Developers keep using their preferred tools. Security keeps control over what those tools can do.

Read more: Obsidian now enforces runtime policy for OpenAI Codex and Runtime policy for Claude Code and Cowork

MCP Security Proxy. MCP makes it easy for your AI agents to connect to applications like Salesforce, Snowflake, Slack and Google Drive. But those connections can also give agents powerful access to business data. Obsidian’s new MCP Security Proxy introduces a governed checkpoint between AI clients and supported applications. It evaluates tool calls against enterprise policies before forwarding them, with context about:

  • The user
  • The application tenant behind each session
  • The requested action

Today, supported services include Atlassian, Context7, Databricks, GitLab, Google Drive, Notion, Salesforce, Sentry, Slack and Snowflake. But the reality is any MCP client can use it. Cloudflare has been our design partner. With this partnership, our joint customers can extend these controls to agent traffic routed through Cloudflare’s MCP Server Portal, so customers can apply the same policies across more of their MCP infrastructure.

Read more: Introducing the MCP Security Proxy: control what AI agents do in your third-party apps through MCP

Enforcement through your own gateways and agent harnesses. Not every agent action flows through a tool Obsidian directly integrates with. With the Policy Decision API, your platform team’s existing gateways and agent harnesses can enforce Obsidian’s policy decisions too. No need to duplicate policies or rebuild infrastructure. The same rules follow agent actions across supported enforcement points.

See it in action: one Claude Code agent, from discovery to decision

Here’s what that looks like in practice.

  1. Discover. Your data team is using Claude Code agents connected to Snowflake. Obsidian discovers those agents and maps what they can access. It also identifies an unapproved MCP server and flags an agent with access to cloud credentials.
  2. Govern. Governance helps the team remove the unnecessary access and block the unsanctioned connection.
  3. Decide. Later, a contractor’s Claude Code agent attempts to drop a business-critical Snowflake table. The agent has valid credentials. The tool call is legitimate. But the action violates your organization’s policy. Before the action executes, Obsidian’s runtime enforcement checks with the Policy Decision Engine. Using identity context and your organization’s data classification labels, the engine recognizes that the user is a contractor and the table is critical.
  4. Enforce. The action is blocked before it reaches Snowflake. The developer sees the policy decision, the rest of the agent’s legitimate work continues, and security has a record of what was stopped and why.

That’s the difference between knowing an agent has access and controlling what it does with that access.

Read more: Runtime policy for Claude Code and Cowork

Find your AI agents, then decide what they can do

AI agents are already at work across your third-party apps, often in more places than anyone has mapped. And they’re only going to become more capable, more connected and more autonomous.

If you’re looking to find your AI agents, know what they can reach and control what they can do, you’ve come to the right place.

If you’ve gotten this far, then Request a Demo. We’ll make it worth your time.

Frequently Asked Questions (FAQs)