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

AI Agent Security

Let AI agents move fast. Keep their actions in check.

Discover what’s running across your enterprise, see what it can access, and enforce policy before it acts.

Request a demo
Watch Video

Trusted By

AI agents act as people with authority. Not every action should go through.

They work with an employee’s access, so one wrong move can expose sensitive data, escalate privileges, or disrupt critical systems.

Without Obsidian

With Obsidian

Your agent doesn’t ask permission

A developer tells a coding agent to “clean up the test database.” It runs DROP TABLE, and no one signs off.

Block one door, and the agent finds another

You stop Copilot from reading salary data. The same person’s coding agent pulls it through a Workday MCP connection.

The session is valid. The person isn’t.

A gateway waves the request through. It doesn’t know the user was off-boarded yesterday or is a contractor.

Supported actions are checked against your policies before they reach the app.

Write each policy once. Enforce it across every application.

Every decision weighs available identity, HR, and app context, plus your own data labels.

Limit what AI agents can reach and what they do with that access.

Discover agents
Govern access
Decide at runtime
Prove control

Know which AI agents exist and what they can reach

Obsidian finds the agents employees run on Codex, Claude Code, Cowork, Cursor, Microsoft Copilot, Amazon Bedrock, Google Vertex, and n8n, and maps each to its owner, tools, MCP servers, models, and apps.
Agents built into Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow, and Workday
Shadow agents surfaced through platform connections and browser detections
Each agent tied to the person who built it and the person running it, including orphaned agents

Trim agent permissions to what the workflow needs

Excessive access, oversharing, and hardcoded secrets surface automatically. Each agent is scored against risk factors when it’s published or changed, so you know what to fix first.
Findings for agents with admin privileges in production apps
Policies built on your own data classification labels

Stop risky actions before they run

Obsidian’s Runtime Policy Decision Engine uses available identity, employment, and app context, plus your own data labels, to evaluate what each agent does against policy and explain every decision.
Policies that combine your own Highly Sensitive label with HR context, such as a person’s department in Workday
Flag mode to test a policy on real agent traffic before it blocks anything

Answer “what did the agents do?” with evidence

Each decision is logged with the person behind it, the outcome, the reason, and the matching policy. Paired with the inventory, that’s a record you can hand to auditors.
Which agents exist, who owns them, and what data and apps they can reach
Your active runtime policies, as evidence of the controls you run

Make context-aware policy decisions before agents act

Obsidian evaluates supported agent actions against your policies, using the context behind each request to decide what runs, what gets blocked, and why.

An agent calls a tool

The request carries the agent ID, the invoking user or account, the tool, and its arguments.

The enforcement point asks

A sidecar, platform webhook, the MCP Security Proxy, or your gateway pauses the action and sends it to the engine.

The Obsidian engine decides

It evaluates your policy with available Knowledge Graph context and your own labels, then returns a decision and the reason.

The decision is applied

The action proceeds, waits for approval where supported, or stops, and the decision is logged.

Enforce where your teams’ agents actually run

Different teams use different agent tools. Obsidian applies the same policies across supported enforcement points, so security stays consistent without slowing teams down.

Coding Agents

Intercept tool calls from Claude Code, Cowork, and Codex with a lightweight sidecar that blocks risky actions before execution.

Agent Platforms

Use native platform integrations to evaluate agent actions against your policies before they execute.

MCP Security Proxy

Put a policy checkpoint between agents and MCP tools to permit or block requests before they reach connected apps.

Your Own Gateway

Bring Obsidian's context-aware policy decisions into your existing gateways through a simple API integration.

Cloudflare Partnership

Obsidian works with the Cloudflare MCP Server Portal to apply context-aware policies to AI agent access into third-party apps, through the Obsidian MCP Security Proxy.
Read about the partnership →

Additional resources

Third-party app context for AI agent runtime decisions

Read the launch blog

The CISO Playbook for Securing AI Agents

Get the playbook

Runtime Governance of the Invisible AI Workforce

Read whitepaper

Control AI agent tool calls to apps through MCP

Visit the MCP Security Proxy page

Frequently asked questions

How is Obsidian different from tools that catalog agents?

Knowing an agent exists isn’t knowing what it can do. Obsidian connects each agent to the service accounts it runs as, the MCP servers it connects through, the permissions it holds in each app, and the person behind it, and uses available context in its runtime decisions.

Does Obsidian enforce runtime policy on all agent platforms?

No. Runtime enforcement applies at supported enforcement points: Claude Code, Cowork, and Codex through a sidecar, Microsoft Copilot Studio through a webhook, supported apps through the MCP Security Proxy, and your own gateways through the Policy Decision API. Platforms such as Salesforce Agentforce, Amazon Bedrock, and n8n are covered by discovery and governance.

What outcomes can a policy return?

Flag, require approval, or block. Flag records a match without acting, and an action that matches no policy proceeds. Require approval is available where the enforcement point supports it, which today means Claude Code policies that run before an operation.

Does the Policy Decision API block actions itself?

No. The API returns a decision and its reason, and your gateway, agent harness, or workflow applies it. You keep the gateways you already run.

Will securing AI agents slow down my employees?

A policy acts only on the actions that match its conditions, and actions that match no policy proceed. Flag mode lets you see what a policy would catch before it affects anyone.

How does Obsidian fit with the security tools we already run?

It works alongside them. Your EDR covers agents running on devices, network gateways inspect AI traffic, cloud security covers the infrastructure under your AI, and your identity provider gives agents their logins. Obsidian covers what agents can reach and do inside your third-party apps, and the Policy Decision API lets the gateways you already run enforce its decisions.

Where should we start?

Most teams start with discovery, because they don’t yet have a reliable inventory of the agents in their environment. Governance then narrows each agent’s access, and runtime policies run in Flag mode before they block anything.