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.