9 min read - Policy-Constrained AI Agents: Three Gates Before They Act

An AI agent can quote a policy and still take the wrong action. It can complete the requested task while skipping a required confirmation. It can also produce a confident answer before the user has supplied the facts that determine what the rule means.

Three independent research papers submitted on 20 August 2026 make those failure modes unusually concrete. One examines underspecified legal questions, one tests agents against executable financial rules, and one evaluates workflow-level controls in customer service. They do not prove a universal solution. Together, however, they provide a useful design signal for startups, SMEs and mid-market teams moving an agent from chat to operational action.

The practical conclusion is this: do not treat “the model knows the policy” as a control. Put three separate gates around the agent—input sufficiency, workflow state and execution evidence—and test each gate independently.

What the new research actually found

The first signal concerns the moment before an answer. The InsufficiencyBench preprint, submitted on 20 August, evaluates whether models notice legally material information missing from a user query. Its 202 items cover six legal domains and 24 US jurisdictions, with annotations by practising attorneys. Across ten frontier models, the authors report that no model exceeded an F2 score of 0.46 for identifying missing elements; median recall was 0.44. Models often hedged too broadly or answered using assumptions they had not made explicit.

This is not evidence about every legal system or business process. The authors state that the dataset is small, US-focused and single-turn, and that agreement between the LLM judges was moderate rather than validated against human scoring. The business lesson is narrower: answer quality is not enough if the system has no test for whether the question is answerable yet.

The second signal concerns the path between request and result. The PolicyGuide preprint compiles organisational policies into workflow graphs, persists the agent's position and uses an external verifier to propose the next compliant step. In three English customer-service domains, the authors report that mean four-run reliability rose from 0.42 for the baseline to 0.62 with PolicyGuide. The largest gain was in the most procedural telecom domain.

Again, the boundary matters. These were benchmark tasks with a frozen user simulator, not live customers. The paper says the overall retail gain over the baseline was not statistically significant, and its ordered-trace measure was author-designed without a second-annotator agreement estimate. The result is a promising architecture hypothesis: long procedures may need externally tracked state, not another policy paragraph in the prompt.

The third signal concerns what happened at execution. The ReguSim preprint separates four artifacts: the agent's stated reasoning, the attempted order, the enforcement outcome and the evidence shown to a monitor. In its controlled financial-compliance environment, visible rules reduced but did not eliminate rejected actions. Confident rationales could also mislead an independent monitor when enforcement evidence was absent, while simple structured monitoring baselines matched or outperformed prompt-only LLM monitors on the synthetic sample.

ReguSim is deliberately not a market simulator, legal adjudication system or measure of real-world misconduct. Its useful contribution is the separation of intent, attempt, enforcement and evidence. A fluent explanation is not proof that the permitted action was executed—or that a forbidden one was blocked.

The three-gate operating model

These papers study different domains and should not be merged into a single benchmark result. The following model is an Exceev operational inference from their shared pattern, aligned with the NIST AI Risk Management Framework, which treats risk management as part of AI design, development, use and evaluation.

The gates are ordered. If Gate 1 fails, the agent asks for missing information or routes the case to a person. If Gate 2 fails, it cannot jump ahead just because the final outcome appears reasonable. If Gate 3 fails, the action does not proceed, even when the model produces a persuasive rationale.

This design also avoids asking one model to be actor, policy interpreter, approver and auditor at the same time. Independence does not require an expensive second model at every step. A schema validator, rules engine, permission boundary or database constraint may be the stronger verifier.

Apply the gates to a real workflow

Consider a support agent allowed to issue account credits.

At Gate 1, it verifies the customer, account, transaction, reason and requested remedy. Missing identity or transaction data triggers a precise question, not a guessed value. The agent may summarize the case, but it cannot recommend a final outcome under silent assumptions.

At Gate 2, the system loads the current refund policy, checks eligibility and records whether required diagnostics or approvals are complete. The workflow state is stored outside the chat transcript. A new conversation therefore cannot erase an unfinished prerequisite.

At Gate 3, a deterministic service checks the amount, currency, account, authorization and idempotency key before calling the payment or billing tool. The log records both the requested credit and the actual tool result. A later reviewer sees the decision chain, not merely the agent's explanation.

The same pattern can support procurement triage, employee onboarding, invoice exceptions or cross-border customer intake. The policy content and qualified reviewers will differ. The control structure remains useful: establish facts, follow the approved path, and verify the action against authoritative state.

For higher-impact workflows, connect this design to an agent audit trail and start with a limited pilot before the agent touches business data.

What to test before production

A polished demonstration usually exercises the happy path once. A production evaluation should instead contain paired cases and repeated runs.

1. Complete and incomplete inputs. Remove one material fact at a time. The agent should identify the gap without refusing well-specified requests.
2. Permitted and near-miss actions. Vary one threshold, role, sequence or approval. Confirm that the boundary changes the outcome.
3. Conflicting evidence. Give the prompt one value and the authoritative system another. The trusted source should win and the conflict should be logged.
4. Long procedures. Restart the conversation midway, retry a step and switch operators. The persisted workflow state should remain correct.
5. Persuasive pressure. Ask the agent to skip verification because the request is urgent or commercially important. Policy should not become a personality test.
6. Tool failures and duplicates. Return timeouts, partial success and late responses. Reconciliation and idempotency should prevent duplicate effects.

Track measures by gate rather than compressing them into one “compliance score.” Useful measures include recall of missing material inputs, unsupported assumption rate, prerequisite completion, forbidden-action attempt rate, hard-block effectiveness, false-stop rate, audit-record completeness and time to human resolution. Set thresholds for the specific harm and workflow; the new papers do not establish universal production targets.

The trade-offs leadership must own

Three gates add engineering and operating cost. Policy graphs need owners and version control. Extra verification can add latency. Strict controls can stop valid requests, while weak ones create a false sense of safety. Logs may also contain sensitive business or personal data and need an appropriate retention and access design.

Those are not reasons to collapse the controls into a longer system prompt. They are reasons to choose the autonomy level deliberately. A low-volume, high-impact process may remain human-led with AI preparing evidence. A stable, high-volume process may justify more automation after repeated tests. A process whose rules are disputed, frequently changing or not machine-testable may not be ready for autonomous execution at all.

The accountable business owner should approve the policy interpretation and stop conditions. Engineering should own runtime enforcement and observability. Security and privacy specialists should review access and evidence handling. Qualified domain experts should validate consequential legal, financial or regulated decisions. The model cannot absorb those responsibilities.

A four-week pilot sequence

• Week 1—model the decision. Select one bounded action, identify material inputs, map authoritative sources and name the policy owner.
• Week 2—implement the gates. Add structured intake, external workflow state, deterministic enforcement and an append-only decision record.
• Week 3—test adversarially. Run incomplete, conflicting, out-of-order, duplicated and urgent cases across repeated trials.
• Week 4—review the exceptions. Measure human escalations and false stops, inspect complete traces, then decide whether to proceed, narrow the scope or keep the process human-led.

The deliverable is not simply an agent. It is a versioned workflow, an evaluation set, an evidence trail, named owners and a reversible deployment decision.

Sources and limitations

• InsufficiencyBench, submitted 20 August 2026, is a US legal-domain preprint with the scope and judge limitations described above.
• PolicyGuide, submitted 20 August 2026, reports benchmark results across three English customer-service domains, not live production outcomes.
• ReguSim, submitted 20 August 2026, uses a bounded rule surface and synthetic monitoring records; its results are not legal findings or market-prevalence estimates.
• NIST AI Risk Management Framework is a voluntary risk-management reference. It does not certify this proposed architecture or replace sector-specific obligations.

All three research papers are early evidence. No cross-paper comparison was performed, their metrics are not interchangeable, and this article's three-gate model is an operational synthesis rather than a result claimed by the authors. Revalidate the sources and obtain qualified advice before a legal, financial, employment or regulatory decision.

Final take

The current signal is not that agents suddenly became compliant. It is that evaluation is moving closer to the real unit of risk: whether the system knew enough, followed the required procedure and produced enforceable evidence of what it actually did.

Before an agent can act, require all three gates. If the evidence is incomplete, the safest and most useful output may be a targeted question, a blocked action or a clean handoff to a person.