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

AI agents now work inside the third-party apps that hold a company's most sensitive data, with the access of the people who run them. Security teams are expected to let those agents work and stop the actions that should not run, without a consistent way to apply policy across the tools agents use. This post covers why agent policy has been so hard to get right, what the Runtime Policy Decision Engine does about it, how it works, and how its decisions differ from other approaches.

AI agent policies are missing or disjointed, and the risk keeps growing

Each team adopts AI agents on the platform that suits its work, and each platform brings its own controls, or none. Agent policy ends up rebuilt tool by tool or missing entirely, and each copy sees only the request in front of it, without the person behind the agent or what that person can reach across other apps.

That gap matters because agents act in seconds. A finding reviewed the next morning arrives after the data has left or the table is gone, and a rule that sees only the request either blocks too much, so the business routes around it, or misses the action that does the damage. The consequences land in the third-party apps where company data lives:

• Sensitive data leaves. An agent sends customer records to an outside address through an MCP tool no one reviewed.
• Records are destroyed. An agent drops a production table or deletes records that cannot be recovered.
• Access outlives the person. An employee is terminated in Workday, and the coding agent sessions running on their credentials keep acting until someone revokes each one by hand.
• Admin access spreads. An agent running on admin credentials gives admin reach to everyone who can invoke it.

The operational cost compounds the risk. Security teams spend time rewriting the same rule in each tool's format, and those copies drift apart as policies change. When the board or an auditor asks which agent actions the company's policy stopped, there is no single record to answer from. Without a better option, the fallback is to slow AI adoption, which puts security at odds with the business.

AI agent adoption is outpacing its controls

Analyst data shows the gap widening from both sides, which is why decisions on agent actions at runtime have become a near-term requirement for security teams:

• Agents are arriving inside the apps companies already run. Gartner predicts that 40% of enterprise apps will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. Each of those apps becomes another place where an agent acts on company data, often switched on by the vendor without a security review.
• More decisions happen without a person in the loop. Gartner predicts that at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from none in 2024. A control that depends on someone reviewing findings later falls further behind as that share grows.
• Weak risk controls are already ending projects. In the same release, Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. When security cannot govern what agents do, projects stall.

Security vendors have responded, and many that started with agent discovery now advertise runtime enforcement as well. Finding agents is now expected. What separates one approach from another is the context behind each decision, and whether that decision holds consistently across the tools agents use.

Meet the decision layer for AI agent actions

Obsidian is introducing the Runtime Policy Decision Engine, the decision layer for AI agent actions in third-party apps. It gives security teams one place to set policy for thousands of AI agents, and a decision on each action those agents take, made with the context of the person, the app, and the data before the action reaches the app.

When an agent tries to act, the enforcement point it runs through pauses the action and asks the Policy Decision Engine. The engine checks the action against the company's policies, draws on Obsidian Knowledge Graph context and the company's own labels, and returns allow, require approval, or block with a reason. The command to drop a production table waits for a person. A terminated employee's agent stops. The rest of the work carries on.

That decision reaches agents where teams already run them: coding agents such as Claude Code, Cowork, and Codex; agents built in Copilot Studio; AI clients that connect to apps through the MCP Security Proxy; and the gateways platform teams operate, through the new Policy Decision API.

The engine builds on the rest of Obsidian AI Agent Security. Discovery finds AI agents, and governance narrows the access they hold. The Policy Decision Engine decides what an agent does with the access it keeps.

Say yes to AI agents and stop irreversible actions

Keep AI agent policy consistent as teams adopt new agent tools. Security teams build agent policies in one Obsidian console, and each enforcement point gets its decision from that same set of policies. When a team adds agents on a supported tool, the policies already in place cover them from the start. Security stops maintaining a separate copy of each rule in each tool, and platform teams keep the gateways they built.

Tell a routine agent action from a risky one. Each decision draws on who the agent acts for, that person's employment status in Workday, the permissions the app grants, and the classification labels the company supplies. A policy holds or blocks only the agent actions that match its conditions, so a dropped table or an outbound file stops while the agent's other work continues, and tool calls that match no policy proceed.

Roll out AI agent policies without breaking workflows, and prove they work. Flag mode tests a policy against real agent traffic before it stops anything, so a new rule does not disrupt a team on day one. Each decision is logged with the agent, the person behind it, the tool, the arguments, the outcome, and the policy that matched, so security leaders can show auditors and the board which agent actions their policies stopped.

The decision happens before the action reaches the app

Each decision follows four steps:

1. An agent calls a tool. The request carries the agent ID, the invoker (the user or account behind the agent), the tool, and its arguments.
2. The enforcement point asks for a decision. The agent runtime, the MCP Security Proxy, or a customer gateway pauses the action and sends it to the Policy Decision Engine.
3. The Policy Decision Engine decides. It evaluates the company's policies using Knowledge Graph context and customer-provided context, then returns a decision and the reason for it.
4. The enforcement point applies the decision. The action proceeds, waits for approval, or stops, and the decision is logged with its full payload. In Claude Code and at the MCP Security Proxy, the agent shows the user a message the policy author wrote.

Security teams write policies in the Obsidian console, as precise as their business rules. Each policy sets which agents it covers, what triggers it, the context it checks, and what happens on a match: flag, require approval, or block. Policies security teams write include requiring human approval for any agent changing payroll data, confirming before destructive MCP tool use, blocking credential file reads, and restricting email sending for unapproved agents. Require approval is available today for Claude Code policies that run before an operation.

Each team picks its own agent tools, so the engine applies policies where each team's agents run. Every enforcement point gets its decision from the same set of policies:

Through the Policy Decision API, a gateway sends the agent ID and name, the invoker, the tool, and the arguments, and receives the decision, the reason (which is passed back to the agent), and a log entry with the full payload. Because policies are written against the agent ID, teams can govern agents that Obsidian has no connector for. Obsidian also 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.

Third-party app context makes agent decisions precise

Many tools can now stop an agent action at runtime. The difference is what the tool knows when it decides. An agent can use valid credentials, call an approved tool, and take an action its account is authorized to take, and still put the business at risk. Judging that action takes an understanding of the person behind the agent, their employment and access status, what they can reach across third-party apps, and the business context of the data involved.

Obsidian's foundation has always been third-party apps. Through connectors into more than 200 of them, Obsidian understands how each app's data is structured, how it is accessed, who can access what, and what they can do with that access. The Obsidian Knowledge Graph connects that application context with identity, HR status, agent platforms, and activity, and the Policy Decision Engine uses it at the moment of the action. Each example below depends on a fact the enforcing tool cannot see on its own:

The tools security teams use today each do part of this job well. The table below shows where each approach stops and what the Policy Decision Engine adds.

Talk to us about securing agent risk

See how the Runtime Policy Decision Engine uses what Obsidian knows about the person, the app, and the data to decide an AI agent's action before it reaches your third-party apps.

Request a Demo

‍