Glossary

What is policy enforcement for LLM tools?

Policy enforcement for LLM tools is a deterministic layer between an AI agent and the system of record. When the agent calls a tool, this layer reads the typed parameters of the call, evaluates them against rules in code or platform configuration, and either executes the call or refuses it.

The defining property is independence from the prompt. The layer does not read the chat, does not see the system prompt, and is not asked to make a judgement. It runs the same checks every time, on the same typed inputs, with the same outcome. The conversation can be jailbroken without changing what the policy decides.

Where the policy lives

There are three places a rule can sit in an LLM-based system: in the prompt (model layer), in the tool definition the model is shown (description layer), or in the code or platform configuration that runs deterministically when the tool is called (action layer). Only the third is enforceable in the strict sense.

A rule in the prompt is a request to the model. The model usually complies. A sufficiently creative prompt can change that. A rule in the tool description is even weaker: it is documentation, not enforcement. The model is meant to read and respect it, and often does, but nothing stops it from calling the tool with violating parameters anyway.

A rule in the action layer is code that runs on each call. The model cannot influence it. The user cannot influence it. The only thing that influences it is whether the parameters and the call context satisfy the rule.

What makes a policy enforceable

Three properties.

Deterministic. The check produces the same result for the same input, every time. This is what deterministic execution gives you. The opposite of asking a model to grade itself.

Out of band. The check runs in code the model does not control, on inputs the prompt cannot rewrite. The tool call carries typed parameters; the policy evaluates those parameters, not the chat that led to them.

Auditable. The check has an input, an output, and a record. Each call, each decision, each refusal can be read back later. A policy that runs but cannot be inspected is not a policy a business can defend.

What a policy looks like in practice

Take a discount-code tool with two typed parameters: a customer identifier and a discount percentage. The agent can be talked into calling it with any value the user proposes.

The policy is enforced when the tool is called: either by a few lines of code in the tool itself, or by a parameter guardrail configured on the tool in the agent platform. Either form produces the same property: the discount percentage is read; if it is greater than 30, the call returns a refusal. Both the input and the outcome are written to an audit log. The same layer can carry other rules, an allowed customer scope or a daily issue limit for instance, each evaluated on typed parameters the same way.

No prompt can change those checks, because no prompt reaches them. The agent can be persuaded to ask. The policy decides.

How dhino runs policy enforcement

In dhino, agents talk to enterprise data through Model Context Protocol tools that map to named actions: read a record, run a parameterised query, call a business operation. There is no path to the underlying database; the agent can only invoke the actions the platform has exposed.

Above each action sits the policy layer. Per-agent scoping decides which tools an agent is allowed to call. Per-call rules check parameters: ranges, allow-lists, business constraints. Per-call audit records the input parameters and the result. None of this sits in the prompt.

See dhino Trust for the product overview and the agent guardrails entry for where this layer fits in a defence-in-depth stack.

Common questions about policy enforcement

What does policy enforcement mean for an LLM agent?

A deterministic layer between the agent and the system of record. When the agent calls a tool, this layer reads the typed parameters of the call, evaluates them against rules in code or platform configuration, and either executes or refuses. The layer does not read the prompt and is not influenced by it.

How is policy enforcement different from a system prompt rule?

A system prompt rule asks the model to behave a certain way. The model usually complies. A determined prompt can talk it out of complying. A policy in the action layer is not asked, it runs. The model can be persuaded to call an action with parameters that violate the policy; the call still does not execute.

Can a policy layer be bypassed by prompt injection?

Not at the policy layer itself, by design. Prompt injection acts on the model. The policy layer sits below the model and evaluates the action, not the conversation. What an injection can do is persuade the model to call an allowed action with parameters the user did not intend. The policy decides whether those parameters are allowed; the prompt cannot change that decision.

Where should LLM policy enforcement run?

Outside the model. In code or platform configuration, on infrastructure the model does not control, before the action reaches the system of record. The two usable places are inside the tool implementation itself or in a layer above it shared across tools. The wrong places are inside the system prompt, inside the model’s training, or in a wrapper that asks the model to check its own work.

See policy enforcement on a real action

Tell us which action an AI agent of yours needs to call. We will show you what a policy layer above it looks like, and what it refuses when the prompt is broken.