What Is an AI Policy / Decision Engine

An AI policy engine is a runtime decision component that receives a proposed agent action, evaluates it against your policy using identity and effective-access context, and returns a verdict before the action completes. Think of the AI policy engine as the reasoning brain for agentic access control, an "Intel Inside" style decision layer that sits with your identity graph rather than in the network path. It answers one question per action: allow, approve, block, or remediate.

Here is the mechanism in plain terms. An agent decides to call a tool, query an application API, or invoke another agent. Before the action lands, the engine receives that event through a native platform hook. It resolves three things: the identity of the human or upstream agent that triggered it, the identity and inherited credentials the agent is running on, and what those credentials can actually do inside the destination application right now. It applies deterministic policy to that combined picture and returns a decision.

This matters because agents are probabilistic. They pick different tools, phrase requests differently, and chain actions no one scripted at design time. A non-human identity that moves roughly sixteen times more data than a human does, and that inherits standing credentials, is a machine insider whether or not anyone intended it to be. The engine's job is to convert that unpredictable behavior into a predictable outcome.

How it differs from a business rules engine

A business rules engine fires when fixed conditions match: block if user role equals X. That works for stable processes like loan thresholds. It cannot resolve maker-mode credential inheritance, agent-to-agent chaining, or entitlements that change hour to hour. An AI policy engine reasons across dynamic context instead of matching static values, so it can catch "block if the runner's authority does not match the credentials this action would execute on." Same word, policy, very different machine underneath.

A decision engine answers "should this happen?" A gateway or proxy answers "let me carry this traffic for you." Those are architecturally different jobs, and conflating them is the most common category error in this space.

• Gateway or proxy. Sits inline. Terminates connections and moves bytes. Adds latency to every request, risky or not, and becomes a bottleneck and a single point of failure for every agent call.
• AI policy engine. Sits at the control plane. Subscribes to events through native platform APIs and webhooks. Returns verdicts without ever touching the transport path.

For a security architect, the practical difference is operational. An inline device means network rewiring, a new thing to scale, and a new thing that breaks. A control-plane decision engine hooks into the AI platform at its own decision point and enforces there. No proxy to maintain, no inline choke point to keep alive. Obsidian works this way on purpose: it is not a gateway and does not carry your traffic. It informs the platform's decision, which is why the "Intel Inside" framing fits better than any inline picture.

The core function of an AI policy engine is evaluating effective access, meaning what the agent can actually do inside the target application at the moment of the call, not what a configuration page claims it should be able to do.

This is where posture-only, read-the-config approaches fall down. They export settings, tabulate risk, and produce a static report. They cannot see that an agent built in maker mode carries its creator's admin token into the destination application and will execute with those privileges no matter who invokes it. Theoretical configuration is not reality. Runtime truth is.

Effective access resolves the whole chain and ties it to a concrete footprint inside the third-party app:

1. Who invoked the agent (the runner identity).
2. Whose credentials it runs on (the maker, the specific service account, the OAuth grant).
3. What those credentials can reach in the destination app right now, down to which objects, tables, and actions.
4. What the specific tool call is trying to touch: which record, which field, which file.
5. Whether any toxic combination applies, such as broad connector scope on an orphaned owner, or public exposure over sensitive data.

The verdict comes from that resolved authority, correlated to real reach inside the application, not from the paper version. Roughly ninety percent of agents end up over-permissioned, so the gap between the config and the effective access is usually the entire risk. Grounding the decision in effective access is also what keeps the blast radius of any single compromised agent small.

The engine sits at the control plane, next to the identity graph, subscribed to platform events. It is not in the network path, not embedded in the model, and not a wrapper around a tool protocol. A typical placement looks like this:

• Above. SIEM, ticketing, and incident response consume the verdicts and the evidence.
• Center. The policy engine, with its identity graph, its effective-access resolver, and its rule set.
• Below. Native API and webhook integrations with the AI platforms your teams actually run agents on.
• Adjacent. Browser telemetry for shadow AI use that never touches a governed platform at all.

Because the integration is API-and-webhook based, security teams can stand the engine up without filing a change request against every application admin. There is no connector to negotiate per downstream app and nothing to insert into live traffic. One control plane, correlating agent activity to effective access across platforms, is what replaces the recurring fire drill of hand-built agent inventories.

Every decision draws from three input streams that have to be correlated in real time. Drop any one and the engine is guessing.

Identity context. The runner, whether human or an upstream agent, plus the maker who built and owns the agent, the credentials it authenticates with, and whether that owner account is still active. An orphaned agent whose creator was offboarded but whose credentials still work is a high-priority signal, because it is a machine insider with no human accountable for it.

Tool call payload. The specific action: which tool, which server, which endpoint, which parameters, and what data the call would read or write. This visibility only exists at runtime. Retroactive log review cannot reliably reconstruct which tool inside a given server was invoked or what it carried.

Target application state. What the destination app currently permits for the resolved identity. This is the effective-access lookup: not what the agent's config asserts, but what the application will actually allow when that token hits the API, expressed as concrete objects and actions.

Correlating all three is the hard part and the whole point. It is what lets the engine say "this exact identity, running on this service account, is about to read these specific records," which is a claim an auditor can verify and a static posture report can never make.

The engine returns one of four deterministic outputs per evaluated action.

• Allow. Within policy. Log and continue.
• Approve. Step-up required. The action needs human sign-off, a manager approval, or second-factor verification first.
• Block. Violates policy. Stop it before completion.
• Remediate. The action exposes a standing problem, such as a public agent over sensitive scope or an orphaned owner. Open a ticket, revoke a scope, or disable the agent.

Deterministic outputs matter precisely because agents are not deterministic. If enforcement is fuzzy, no auditor, board committee, or incident responder can rely on it.

One honest note on where enforcement stands today. Autonomous block-and-approve enforcement is live now for Claude and Microsoft Copilot. For other platforms the engine operates in discover-and-govern mode: it produces full identity, tool-call, and effective-access evidence and can drive remediation through tickets and workflows, with in-line runtime enforcement on the roadmap rather than shipping today. The practical path is the same either way. Start in monitoring mode, build trust in the identity graph, then move to approve and block where autonomous enforcement is available.