Context OS is one layer of a Governed AI stack.
Updated 31 October 2026
To enforce policy before an AI agent acts, evaluate each proposed action against defined rules before it executes. Do not rely on checks that run after the fact. A pre-action check returns one of three results: allow the action, require a named approver above a threshold, or block it. Record the result, the policy version and any approver every time. Without that record, the control exists only in a document.
Why checks must come before the action
An agent often acts through tools. It updates a customer record, sends a message or submits a payment instruction. Once the tool call completes, reversing it may be slow, costly or impossible. A check that runs afterwards can report a problem, but it cannot prevent the harm.
Placement also changes accountability. When the policy runs before the action, the organisation can show that a rule was applied to this specific request, with these data, at this time. That is the evidence a supervisor or internal auditor will ask for first.
What a pre-action check evaluates
A useful check looks at three things. The first is permission: whether this agent may perform this action on this data. The second is threshold: whether the value, exposure or risk of the action exceeds a level that requires a named human approver. The third is context: whether the inputs are current, correctly sourced and free of conflicting instructions.
Permission checks are the simplest, and many organisations already run them for human users. Threshold and context checks are where agent deployments usually fall short. An agent may hold permission to issue a refund and still need approval above an amount the business sets. It may also need to stop when the customer record it is using was updated minutes earlier by another system.
Designing approval thresholds
Set thresholds in business terms, such as transaction type, customer segment, product or exposure category. Assign a named approver to each threshold. Define what the approver sees before they decide. An approval screen that offers only a yes or no button does not give the approver enough context to judge the action.
Keep thresholds in a versioned policy store, not hard-coded in prompts or application code. Changes should pass through the same approval process as other control changes. Record the policy version with every decision, so a later review can see which rule applied when the action was taken.
Handling exceptions and failed checks
When a check fails, the agent should stop, record the reason and route the case to the designated owner. Silent retries and fallback actions are a common source of audit findings, because they change the outcome without leaving a clear record. An agent that cannot complete a check should not look for a shorter route to the same result.
Exceptions need an owner, a reason and an expiry date. A standing exception that nobody reviews becomes an unrecorded policy change. Review open exceptions on a fixed schedule, and close those that no longer have a business reason.
What the EU AI Act asks for oversight
Article 14 of Regulation (EU) 2024/1689, the AI Act, sets human oversight requirements for high-risk AI systems. In summary, the Article requires that such systems can be effectively overseen by natural persons. Overseers must be able to stay aware of the tendency to rely too heavily on automated output, to override the output, and to interrupt the system through a stop function.
These are binding requirements for high-risk systems once they apply. The Digital Omnibus on AI, Regulation (EU) 2026/1744, amends the Act, including some application dates. Check the amended text for the dates that apply to your system before you plan around them. For a bank, the practical translation is simple: approval thresholds, override rights and a stop control should be designed and tested before an agent is given authority over a regulated decision.
What the UAE central bank guidance says about oversight
The Central Bank of the UAE's guidance note on AI and machine learning expects licensed financial institutions to maintain appropriate human oversight. It states that human-out-of-the-loop operation should be limited to low-risk, non-material processes. That wording is useful for approval design. An agent acting on a material decision needs a person in the loop, and materiality should be defined in advance.
The note is guidance. It says it supplements and does not replace existing laws. Treat it as a supervisory expectation, and check its current status on the rulebook page.
A minimum set of controls
A pre-action design for a regulated agent usually includes a named owner for each agent; a register of permitted actions; a policy check before each class of action; approval thresholds with named approvers; a stop control the business can use without engineering support; and a trace that links the request, the check, the approval and the outcome. Each item should be tested, not only documented.
The test is a rehearsal. Run a sample of blocked, approved and allowed actions, then confirm that the traces show what happened. Repeat the rehearsal after each policy change and each new tool connection.
What to ask a vendor
Ask any platform vendor, including ElixirData, to demonstrate three cases live: a blocked action, an approved action and an allowed action. For each, ask for the trace. Check whether the policy version is recorded, whether the approver sees the context they need, and whether the stop control works without the vendor's engineers. ElixirData is XenonStack's decision infrastructure platform, and it includes pre-action policy checks, approval thresholds and decision traces. It is one option to evaluate against the criteria in our buyer guide, and product information is at https://www.elixirdata.co/.
Testing a pre-action check before go-live
Before an agent receives authority over a live action, run the check in a controlled environment with a fixed set of test cases. Include clear allows, clear blocks and the borderline cases that sit close to a threshold. Borderline cases matter most, because they show whether the rule behaves as the policy owner intended.
Record the expected result for each test case before running it. Then compare the actual result, the policy version and the trace. A test that passes only because nobody wrote down the expected answer proves little. Keep the test set under version control, and rerun it after every policy change, every new tool connection and every change to the model behind the agent.
Involve the people who will own the exceptions in this test, not only the engineers. An approver who has never seen a blocked action will not know how to respond to one in production. Walking through a small set of real cases with the approver is often the fastest way to find a threshold that is set in the wrong place.
Measuring whether the control works
A pre-action control should be measured on three things: how many actions it stops that should have been stopped, how many it stops that should have proceeded, and how long an approver takes to decide. The first two show whether the rule is accurate. The third shows whether the control is practical. A control that blocks correct actions or takes days to clear will be bypassed in practice, and a bypass is a control failure.
Review the figures monthly in the same forum that reviews other operational risks. Use them to adjust thresholds through the policy change process, not by editing the agent directly.
Frequently asked questions
What is a pre-action check?
A pre-action check is a rule evaluation that runs before an agent executes an action. It returns one of three results: allow, require approval or block. The result, the policy version and any approver should be recorded, so the decision can be reviewed later by someone who was not in the room.
Should approvals be automated?
Routing approvals can be automated, so the right person receives the request quickly. A named person should still own each approval threshold and each exception. Automation that approves material actions without a human removes the control the threshold exists to provide.
Where should the stop control sit?
The stop control should sit outside the agent, in a system the business can operate without engineering support. It should halt pending and future actions for an agent or for a class of action. Test it regularly, and record each use with the reason and the person who triggered it.
Related reading
For the criteria used to compare platforms, read Which Platforms Give AI Agents Governed Business Context? For the context layer these checks depend on, read Context OS vs Semantic Layer vs Data Catalog vs Knowledge Graph. For the record these checks should produce, read How Banks Keep an Audit Trail of Every AI Agent Decision.
Sources
- European Union, Regulation (EU) 2024/1689 (AI Act), Article 14. Binding for high-risk systems. Official text: EUR-Lex.
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending the AI Act. Check the amended text for application dates: EUR-Lex.
- Central Bank of the UAE, Guidance Note on Consumer Protection and Responsible Adoption and Use of AI and ML by Licensed Financial Institutions. Guidance, not a regulation: CBUAE rulebook.
- NIST, AI Risk Management Framework 1.0, 26 January 2023. Voluntary: NIST AI RMF.
Disclosure: This article is published by XenonStack, which develops ElixirData, a platform with pre-action policy checks.
