What is action-boundary enforcement?
Action-boundary enforcement controls the actions an agent takes (the tool calls) instead of inspecting the text it produces. The boundary sits at the point of effect, where it can't be talked around.
Guardrails vs. boundaries
Most “AI safety” tooling is text-filtering: it scans prompts and completions for unsafe content and tries to block bad strings. That helps with what a model says. It does little about what an agent does, and agents do plenty: execute SQL, send email, transfer funds, delete files.
Enforgate enforces at the action boundary: the moment a tool call leaves the agent and is about to take effect. Every call is evaluated against an explicit policy and gets a verdict before anything happens. The decision is about the call: which tool, with which arguments, not about the surrounding prose.
Why this is stronger
- It can't be prompt-injected around.A jailbreak that convinces the model to misbehave still has to make a tool call, and that call meets the same policy. The boundary doesn't care how the model was persuaded.
- It's deterministic. A policy is rules, not a classifier. The same call always gets the same verdict, and you can read the exact rule that decided it.
- It fails closed.No matching rule means deny; a malformed condition means deny; an audit-write failure means the call is refused. Uncertainty never resolves to “allow.”
- It's auditable. Because enforcement happens at the call, every action, allowed, blocked, or held, is a recorded event with a verdict and a rule.
Where text filtering still fits
Content moderation and prompt hygiene are complementary: they reduce how often an agent tries something harmful. Action-boundary enforcement is the backstop for when it tries anyway. Defense in depth: filter the text if you like, but put a hard boundary on the actions.
In Enforgate, the boundary is your policy, enforced by the gateway on every call. For the data-protection guarantees behind it, see security & data handling.