A prompt is not a control
Telling a model not to do something is a suggestion, not a boundary. If the only thing preventing an agent from issuing a refund is an instruction in its system prompt, you do not have a control — you have a hope with good grammar.
Real guardrails are enforced outside the model, in code the model cannot influence.
Layer one: capability boundaries
An agent can only call the tools it has been granted, and each tool is a typed function with validated inputs. If it invents an account number, schema validation rejects it before anything reaches your ERP. Deny by default, grant explicitly, scope per environment.
Layer two: value and confidence thresholds
Every action carries a value and a confidence. Below thresholds you set, it executes. Above them, it routes to a named approver with the full reasoning trail attached. Thresholds are configuration, not code, so operations can tighten them without a release.
Layer three: policy evaluation
Before execution, the proposed action is checked against policy: is this counterparty on the approved list, is this within budget, does this require dual approval, is it outside business hours. Policy lives in one place and applies to every agent uniformly.
Layer four: reversibility
If an action can be taken automatically, the reverse should also be automatic. We build the undo path alongside the do path. It is the difference between an incident that takes four minutes to resolve and one that takes a fortnight.
- Scoped, revocable credentials per tool and per environment
- Schema-validated inputs so invented values fail closed
- Configurable value and confidence thresholds
- Centralised policy evaluation before execution
- A tested reverse path for every automated action
- Immutable audit records for every step, tool call and token
Working on this yourself?
We run ninety-minute working sessions with no charge and no pitch. Bring the process that keeps breaking and whatever numbers you have.
Book a session