AI Runtime Policy Enforcement For UK Business Agents

AI Trust & Governance

22 July 2026 | By Ashley Marshall

Business AI agents are moving from answering questions to taking action. Once an agent can approve spend, update a CRM record, change a finance workflow or trigger an operational process, governance has to move into runtime, not sit in a policy document.

Agents change the governance problem from output review to action control

The first wave of business generative AI risk was mostly about content. Did the model hallucinate? Did it expose sensitive information? Did it produce a biased answer? Those questions still matter, but they are no longer enough. A business agent connected to Xero, HubSpot, Salesforce, Microsoft 365, ServiceNow, Zapier, Make, Stripe or an internal API is not merely producing text. It can request a tool call, pass parameters, update a system of record, send a message, change a workflow state or trigger a downstream process.

That is why runtime policy enforcement matters. It is the control layer that asks, at the moment an agent is about to act, whether the action is allowed. The answer should depend on the user, role, data category, business object, workflow state, value threshold, customer status, legal basis, contract rules, system sensitivity and current risk signals. A procurement assistant can draft a supplier approval note. It should not be able to approve a new supplier, change bank details or release a payment without the right policy checks and named human accountability.

The UK government's pro-innovation AI regulation white paper sets out five cross-sector principles: safety, security and robustness, appropriate transparency and explainability, fairness, accountability and governance, and contestability and redress. Those principles become practical only when translated into runtime decisions. A policy that says humans remain accountable is weak if the agent can still update a complaint outcome at 2am with no approval trail.

What this means in practice is straightforward. Before connecting an agent to operational tools, define the actions it can request, the systems it can touch, the data it can read, the values it can approve and the conditions that force escalation. Treat every action as a decision point, not an implementation detail. If a workflow affects money, customers, staff, legal rights or regulated obligations, the control should sit in the path of execution.

Static access controls are not enough for agents that can approve or spend

Most business systems already have access controls, but agentic workflows expose a gap. Traditional access control asks whether a user or application can access a system. Runtime policy enforcement asks whether this specific action is acceptable in this specific context. That distinction matters when an AI agent is working across finance, CRM, support and workflow platforms. A user may be allowed to view invoices and create purchase requests. That does not mean an agent acting on their behalf should be able to approve a GBP 12,000 supplier payment, change payment terms, alter a refund rule or mark a customer dispute as resolved.

Good runtime policy looks like a set of clear business constraints. Finance agents might need a spending cap, vendor whitelist, duplicate invoice check, bank detail change block, segregation of duties rule and mandatory approval for anything above a threshold. CRM agents might be allowed to draft notes and suggest next actions but blocked from changing lifecycle stage, owner, deal value or consent status without confirmation. Workflow agents might trigger low-risk tasks automatically but require human approval before notifying customers, closing a case, changing service entitlement or opening access to a new system.

Microsoft's Foundry agents documentation describes function calling as a pattern where the model requests a function call, the application executes the function and returns the output. It also notes that production examples should use human-in-the-loop approvals where appropriate. That is the architectural lesson: the model should not be the final authority on whether a business action runs.

The counterargument is that the agent is only doing what an authorised employee could do. That misses the point. Agents can act faster, repeat errors consistently, combine permissions across systems and execute actions without the natural friction of a person reading a screen, hesitating and asking a colleague. Runtime controls put that friction back where it is valuable: at the moments where money, records or customer outcomes change.

UK data protection and contestability rules make audit trails non-negotiable

When an agent updates a customer record, processes a refund, changes an HR note or routes a complaint, it may affect personal data and individual rights. UK businesses therefore need more than a chat transcript. They need an audit record that shows what the agent saw, what it intended to do, which tool it requested, which policy evaluated the request, who approved or rejected it, what system changed and how a person can challenge the outcome.

The ICO guidance on AI and data protection focuses on accountability, governance, fairness, accuracy, transparency and Article 22 of the UK GDPR, including questions around solely automated decision-making. Runtime policy enforcement supports those duties because it creates structured evidence. If a data subject asks why a decision was made, or a regulator asks how the organisation controlled an AI process, the business can show the policy, the decision route and the human review point instead of relying on a generic assurance that staff were meant to supervise the tool.

This is especially important where agents touch CRM or support systems. A small update can have a large downstream effect: a vulnerable customer flag removed from a record, a consent field changed, a complaint categorised as low severity, a refund refused, a lead moved into a sales sequence or a staff record amended. Each of those may look administrative, but the business consequence is real.

What this means in practice is that every agent action should produce a decision receipt. At minimum it should include timestamp, agent identity, human requester, connected system, object identifier, proposed action, policy result, approval status, reviewer if any and final system response. For high-risk actions, keep the prompt, relevant retrieved context, tool parameters and policy version. That evidence is not just compliance paperwork. It is how teams debug errors, defend decisions and improve controls without guessing.

Security guidance points to lifecycle controls, monitoring and rollback

AI runtime enforcement is also a security control. Agents connected to business systems create new paths for prompt injection, excessive permission use, data leakage, workflow abuse and accidental escalation. An attacker who can influence an agent's input may try to make it ignore instructions, reveal records, approve an action or call a tool with malicious parameters. A well-designed policy layer limits what the agent can do even when the model output is wrong.

The NCSC Guidelines for secure AI system development are useful because they apply to AI systems built from scratch and to systems built on external APIs or hosted models. The guidance breaks security across secure design, secure development, secure deployment, and secure operation and maintenance. That maps neatly to business agents. Design defines the allowed actions. Development implements the tool contracts and tests. Deployment controls identity, secrets, infrastructure and release. Operation monitors behaviour, manages updates and keeps incident response ready.

DSIT's Cyber Security Breaches Survey 2025 reported that 43% of UK businesses identified a cyber breach or attack in the previous 12 months, equal to about 612,000 businesses. It also found that only 14% reviewed cyber security risks from immediate suppliers and only 7% reviewed wider supply chain risk. That matters because agent platforms, model providers, plugins and automation connectors are now part of the operational supply chain.

Runtime policy should therefore include monitoring and rollback, not just approval. Teams need alerts for unusual tool use, repeated policy denials, spikes in spend requests, access to sensitive objects, off-hours execution and unexpected connector behaviour. They also need a kill switch that can pause an agent, revoke a connector, disable a tool or route all actions to manual approval. A policy gate with no operational response plan is only half a control.

Guardrails help, but business policy needs a separate enforcement layer

Many vendors now offer guardrails, safety filters, tool permissions and content controls. Those are welcome, but they should not be mistaken for complete business policy enforcement. A guardrail can block harmful content, redact personal data or stop a model discussing prohibited topics. A business policy engine decides whether this agent may approve this refund, update this CRM field, trigger this onboarding workflow or spend this amount from this budget.

Amazon Bedrock Guardrails, for example, provides configurable safeguards for foundation model applications, including content filters, denied topics and sensitive information filters that can help block or mask personally identifiable information in user inputs and model responses. That is valuable, especially for reducing leakage and unsafe outputs. But a refund approval rule, segregation of duties check or procurement threshold is usually specific to the organisation. It has to understand the company's systems, roles, approval matrix and exceptions.

The same applies to broader agent ecosystems. Anthropic's Model Context Protocol is one example of the move towards standardised connections between AI assistants and data sources or tools. Standardisation can make integration cleaner, but it can also make tool access easier to spread across the business. The control question remains local: which servers, tools and operations are approved, who can invoke them, what data can cross the boundary and which actions require review?

The misconception to address is that guardrails slow the agent down and make it less useful. Badly designed guardrails do. Well-designed runtime policy makes useful automation safer to scale. It lets low-risk actions run automatically, routes medium-risk actions for quick approval and blocks high-risk actions unless the right conditions are met. The aim is not to make every agent ask permission for everything. The aim is to make sure the permission model matches the business consequence of the action.

A practical enforcement model starts with a register of agent actions

The practical starting point is not a grand AI governance programme. It is an action register. List every agent, every connected system, every tool it can call and every action it can request. Split actions into read, draft, recommend, queue, update, approve, spend, notify, export and trigger. Then assign a policy to each action class. Read actions need data access rules. Draft actions need review rules. Update actions need field-level limits. Approval and spend actions need thresholds, segregation of duties and audit. Trigger actions need downstream impact checks.

A good UK business pattern is three-tier enforcement. Tier one is automatic approval for low-risk, reversible actions such as drafting a task, summarising a record or tagging a non-sensitive internal note. Tier two is human confirmation for material but routine actions such as updating a CRM stage, sending a customer email, issuing a small refund or triggering a standard workflow. Tier three is blocked or senior-approved action for high-impact changes such as supplier bank details, contractual commitments, HR decisions, large payments, regulated customer outcomes or irreversible data deletion.

Use named frameworks to keep the model credible. The NIST AI Risk Management Framework is organised around Govern, Map, Measure and Manage, and its 2024 generative AI profile gives organisations a way to think about risks created by generative systems. ISO/IEC 42001 gives a management system approach for AI governance. Neither replaces your runtime rules, but both help structure ownership, risk assessment and continuous improvement.

What this means in practice is that the agent launch checklist should include more than prompts and model choice. It should include action inventory, owner, data categories, tool permissions, policy thresholds, approval routes, audit fields, monitoring alerts, rollback method, testing examples and review date. If the business cannot write those items down, the agent is not ready to act autonomously. It may still be useful as an assistant, but it should remain in recommendation mode until the runtime controls catch up.

Frequently Asked Questions

What is AI runtime policy enforcement?

It is the live control layer that checks an AI agent's proposed action against business rules before the action is executed. It can allow, block, escalate or require human approval based on context.

Why does runtime enforcement matter for UK businesses?

It matters because agents can now update records, approve actions, spend money and trigger workflows. UK businesses need controls that support accountability, security, data protection and contestability at the point of action.

Is this different from ordinary access control?

Yes. Access control decides whether a user or app can reach a system. Runtime policy enforcement decides whether a specific agent action is allowed in a specific business context.

Which agent actions should always need extra control?

Approving spend, changing supplier bank details, updating CRM consent fields, altering HR records, changing complaint outcomes, deleting data, exporting sensitive records and triggering customer-facing workflows should all need explicit policy checks.

Do vendor guardrails solve this problem?

No. Vendor guardrails help with safety, content filtering and sensitive information controls. Internal runtime policy is still needed for company-specific approvals, spending limits, roles, workflow rules and audit requirements.

What should an agent audit log contain?

It should record the timestamp, agent identity, human requester, system, business object, proposed action, tool parameters, policy result, approval status, reviewer where relevant and final system response.

How can small businesses start without overcomplicating governance?

Start with an action register, three risk tiers and a simple approval matrix. Let low-risk actions run, require confirmation for material updates and block or escalate high-impact actions.

Which frameworks are useful for runtime AI governance?

UK businesses should consider the UK AI regulation principles, ICO AI and data protection guidance, NCSC secure AI system development guidance, NIST AI RMF and ISO/IEC 42001 as useful reference points.