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, 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 that runs 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 action. The agent's tool is a function called create_discount_code, 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 a few lines of code that run when the tool is called. The discount percentage is read; if it is greater than 30, the call returns a refusal. The customer identifier is checked against the agent's allowed scope; if the agent is not authorised for that customer, the call returns a refusal. Both the input and the outcome are written to an audit log.

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, 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 code 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, 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.