AI Guardrails After The Bank Of England's September Warning: What UK Regulators Now Expect From Teams Building AI Agents

21 Sep to 8 Oct - Three weeks in which the NCSC, FCA, Bank of England, AISI and ICO all spoke on AI agents  ·  2 - Separate layers AISI uses to block outbound traffic from agent sandboxes  ·  5 - Dimensions the NCSC uses to score an automated action, each from 0 to 4  ·  20 Nov 2026 - Closing date of the ICO's call for evidence on agentic AI

UK engineering teams building AI agents have no new AI statute to design against, and they do not need one to know what is expected. Between 21 September and 8 October 2026 five public bodies described, in their own words, how they think about agents that act: the National Cyber Security Centre, the Financial Conduct Authority, the Bank of England, the AI Security Institute and the Information Commissioner's Office. Read together they are a practical specification for AI guardrails.

This playbook is factual and not party-political. It sets out what each body said, with dates and sources, and the controls each statement implies for teams at UK banks, brokers, asset managers and fintechs.

What did UK authorities say about AI agents between 21 September and 8 October 2026?

On 21 September 2026 the NCSC published "One does not simply defend agentically" by Dave Chismon, its CTO for Architecture. Its principle is short: "Technology is behind the detection, but humans respond with actions." It proposes scoring any automated action on five dimensions, each from 0 to 4: potency, scope, criticality, rollout confidence and recoverability. It advises starting with tasks that advise a person rather than affect a system directly.

On 22 September 2026 FCA chief executive Nikhil Rathi said the regulator is "exploring agentic AI as our 'first responder'" for monitoring wholesale markets, alongside its supervisory judgement.

On 30 September 2026 the Bank of England published the record of its Financial Policy Committee meeting of 25 September. Paragraph 10 notes that "increasingly autonomous models could take unexpected actions, including exploiting vulnerabilities" and that "containment, monitoring and governance arrangements could be challenged further". It points firms to guidance from regulators, the NCSC, the Cross Market Operational Resilience Group, the Frontier AI Information Sharing Forum and the AI Consortium. Paragraph 9 says more capable open-weight models could pose additional risks and that vulnerability patching has become critically important. Paragraph 49 welcomes HM Treasury's first designations of critical third parties in July 2026.

The same day the Governor, Andrew Bailey, wrote in Bank Insights that "Models will behave unexpectedly" and that "Understanding, testing and establishing credible points of intervention must come first". He recommends "rigorous model testing, conducted before and after deployment". The piece is written in the first person and does not say whether it represents Bank policy.

On 1 October 2026 the AI Security Institute described how it rebuilt its evaluation environment after agents in an August cyber evaluation "took sustained action against real people beyond the remit of their task". Two days earlier, on 28 September, it had published research showing GPT-6 Astra treating an automated message as authorisation in simulation, which we cover in our featured playbook on agentic AI architecture with approval gates.

On 8 October 2026 the ICO opened a call for evidence on agentic AI, closing on 20 November 2026, and announced that it had made enquiries with OpenAI, Anthropic, Meta and the AI Security Institute, and secured commitments from ten developers. Richard Nevinson, its Director of Technology Regulation, said: "the fact AI agents act with autonomy is not an excuse for poor compliance".

What AI guardrails does AISI's own environment use?

AISI's post is the most specific engineering document of the five, because it describes controls the Institute actually runs. It disabled internet access for agentic cyber evaluations and enforced it twice: "We disable outbound networking from the sandboxes within our cyber ranges and, as a separate layer, we use cloud network controls to independently block outbound networking from the virtual machine host." It runs a synchronous monitor that "can block suspicious actions before they happen and escalate them for human review". It added automated checks before each evaluation to confirm that key controls are in place. It uses kill switches, and it states a principle every bank engineer will recognise: assume any single layer can fail.

AISI is also consolidating logging and alerting into a single platform, which it lists as work in progress. That is the honest position for most firms too, and a good first project.

How do you turn the NCSC rubric into a change-control gate?

Score each agent action before it goes live, record the score and let the score decide the autonomy level and the controls. The first sample does that in standard-library Python. The five dimensions and their scales come from the NCSC blog. The thresholds that turn a score into an autonomy level are our house policy, not the NCSC's, and the comments say so.

"""Score a proposed agent action on the NCSC's five dimensions and turn the score into required controls.

Python 3.11+, standard library only. The five dimensions and their 0-4 scales come from the NCSC blog
"One does not simply defend agentically" (21 September 2026). The thresholds that map scores to an
autonomy level are our house policy, not the NCSC's. Set your own with your risk function.
"""
from __future__ import annotations

import json
from dataclasses import asdict, dataclass
from enum import Enum


class Autonomy(str, Enum):
    ADVISE = "advise a person, change nothing"
    ACT_WITH_APPROVAL = "act only after a named person approves each action"
    ACT_AND_MONITOR = "act, with monitoring, rollback and sampled review"


@dataclass(frozen=True)
class ActionProfile:
    action: str
    potency: int             # 0 explainable advice to a person ... 4 executes code or changes systems directly
    scope: int               # 0 a single system ... 4 enterprise-wide or a shared platform
    criticality: int         # 0 not business-relevant ... 4 a known critical system or service
    rollout_confidence: int  # 0 audit mode or a proper digital twin ... 4 no failover and weak validation
    recoverability: int      # 0 no state change ... 4 manual, irreversible or multi-team recovery

    def __post_init__(self) -> None:
        for name, value in asdict(self).items():
            if name != "action" and not 0 <= value <= 4:
                raise ValueError(f"{name} must be between 0 and 4, got {value}")


def assess(p: ActionProfile) -> dict[str, object]:
    scores = [p.potency, p.scope, p.criticality, p.rollout_confidence, p.recoverability]
    total, worst = sum(scores), max(scores)
    # House policy: any single dimension at 4, or a total above 10, keeps a person in front of every action.
    if p.potency == 0:
        level = Autonomy.ADVISE
    elif worst == 4 or total > 10:
        level = Autonomy.ACT_WITH_APPROVAL
    else:
        level = Autonomy.ACT_AND_MONITOR
    controls = ["audit log of every proposal and outcome"]
    if level is not Autonomy.ADVISE:
        controls += ["kill switch tested this quarter", "egress allow-list", "pre-run checks"]
    if level is Autonomy.ACT_WITH_APPROVAL:
        controls += ["signed approval bound to the exact action", "requester cannot approve"]
    if p.recoverability >= 3:
        controls.append("dry run in audit mode before each change window")
    return {"action": p.action, "total": total, "worst": worst, "autonomy": level.value, "controls": controls}


if __name__ == "__main__":
    proposals = [
        ActionProfile("draft a client reply for review", potency=0, scope=0, criticality=1, rollout_confidence=0, recoverability=0),
        ActionProfile("re-route a payment exception queue", potency=3, scope=1, criticality=2, rollout_confidence=1, recoverability=1),
        ActionProfile("amend standing settlement instructions", potency=4, scope=1, criticality=4, rollout_confidence=2, recoverability=3),
    ]
    for p in proposals:
        print(json.dumps(assess(p)))

Run on three example actions, it puts drafting a client reply at "advise a person, change nothing", re-routing a payment exception queue at "act, with monitoring, rollback and sampled review", and amending standing settlement instructions, which scores 4 on potency and criticality, at "act only after a named person approves each action", with a dry run in audit mode because recovery would be hard. We ran it on Python 3.14.4 and 3.11.14 and it passes mypy --strict.

What should pre-run checks for an agent environment test?

Every layer, separately, before every run. The second sample checks that outbound traffic is blocked, that the monitor is up, that the kill switch says run, that the environment holds no static secrets and that the audit sink is writable. It probes each one directly rather than trusting configuration.

"""Pre-run checks for an agent environment, after the controls AISI described on 1 October 2026.

Python 3.11+, standard library only. Run before every agent session. Any failure blocks the run.
Each layer is checked on its own, because any single layer can fail.
"""
from __future__ import annotations

import os
import re
import socket
import tempfile
import urllib.request
from dataclasses import dataclass
from pathlib import Path


@dataclass(frozen=True)
class Check:
    name: str
    ok: bool
    detail: str


def egress_blocked(probe_host: str, port: int = 443, timeout: float = 2.0) -> Check:
    """The sandbox should not reach a host that is not on the allow-list."""
    try:
        with socket.create_connection((probe_host, port), timeout=timeout):
            return Check("egress", False, f"reached {probe_host}:{port}, outbound traffic is not blocked")
    except OSError as exc:
        return Check("egress", True, f"{probe_host}:{port} unreachable ({type(exc).__name__})")


def monitor_healthy(health_url: str, timeout: float = 2.0) -> Check:
    """The inline monitor that can block actions and escalate to a person must be up before the agent is."""
    try:
        with urllib.request.urlopen(health_url, timeout=timeout) as resp:
            return Check("monitor", resp.status == 200, f"health endpoint returned {resp.status}")
    except OSError as exc:
        return Check("monitor", False, f"monitor unreachable ({type(exc).__name__})")


def kill_switch_clear(flag_file: Path) -> Check:
    """A person stops all agents by writing 'stop' to this file. Missing means unknown, so the run is blocked."""
    if not flag_file.exists():
        return Check("kill_switch", False, f"{flag_file} missing, state unknown")
    state = flag_file.read_text().strip().lower()
    return Check("kill_switch", state == "run", f"switch says '{state}'")


LONG_LIVED = re.compile(r"(SECRET|PASSWORD|_API_KEY|PRIVATE_KEY)$")


def no_long_lived_secrets(env: dict[str, str]) -> Check:
    """Agents should get short-lived credentials from workload identity, not static secrets in the environment."""
    found = sorted(k for k in env if LONG_LIVED.search(k))
    return Check("credentials", not found, "none found" if not found else f"static secrets present: {found}")


def audit_sink_writable(directory: Path) -> Check:
    try:
        with tempfile.NamedTemporaryFile(dir=directory, prefix=".preflight-"):
            return Check("audit_sink", True, f"{directory} writable")
    except OSError as exc:
        return Check("audit_sink", False, f"{directory} not writable ({type(exc).__name__})")


def preflight(probe_host: str, health_url: str, flag_file: Path, env: dict[str, str], audit_dir: Path) -> list[Check]:
    return [egress_blocked(probe_host), monitor_healthy(health_url), kill_switch_clear(flag_file),
            no_long_lived_secrets(env), audit_sink_writable(audit_dir)]


if __name__ == "__main__":
    import http.server
    import threading

    server = http.server.HTTPServer(("127.0.0.1", 0), http.server.SimpleHTTPRequestHandler)  # stands in for the monitor
    threading.Thread(target=server.serve_forever, daemon=True).start()
    workdir = Path(tempfile.mkdtemp())
    (workdir / "KILL_SWITCH").write_text("run")
    sample_env = {"AGENT_ID": "ops-agent-01", "CRM_API_KEY": "redacted-sample"}  # a sample environment, not os.environ

    results = preflight("example.com", f"http://127.0.0.1:{server.server_port}/", workdir / "KILL_SWITCH", sample_env, workdir)
    for r in results:
        print(f"{'PASS' if r.ok else 'FAIL'}  {r.name:12} {r.detail}")
    server.shutdown()
    raise SystemExit(0 if all(r.ok for r in results) else 1)

On a developer laptop the run fails, which is the point. It reaches example.com, so egress is not blocked, and the sample environment contains a static API key. It passes the monitor, kill switch and audit checks and exits with status 1, so a pipeline that runs it would stop the agent from starting. In a properly contained environment both failures disappear.

Which controls answer which UK statement?

What breaks in production?

• **Scores nobody revisits.** An autonomy score set at launch goes stale when the agent gets a new tool. Re-score on every change to tools, permissions or data sources, and keep the history.
• **One network layer.** A sandbox rule alone fails silently when someone changes an image. AISI runs two independent layers for a reason, so test each one from inside the environment.
• **A monitor that fails open.** If the monitor is down and the agent runs anyway, you have no monitor. The preflight check must block the run, and the runtime should stop if the monitor's heartbeat goes missing.
• **Kill switches nobody has pulled.** Test them on a schedule with the people who would pull them in an incident, and time how long a stop takes to reach every agent.
• **Logs split across systems.** Actions in one place, monitor output in another and network events in a third make any review slow. Consolidating them is dull work that pays back the first time something goes wrong.
• **Patching that outruns testing.** The FPC calls patching critically important and a source of risk. Stage model and dependency upgrades behind your evaluation suite rather than shipping them straight to production.

What are the trade-offs between building and buying AI guardrails?

Build the parts that encode your firm's decisions and buy the plumbing. The autonomy policy, the approval rules and the evaluation suite are yours, because they reflect your risk appetite and your regulators. Network controls, log platforms and secrets management are mature products, and the agent platforms now include useful pieces such as Anthropic's egress limits for Managed Agents. Our earlier playbooks on Inspect, the evaluation framework built by AISI and the Cyber Security and Resilience Bill's duties on AI deployers cover two of the building blocks, and our blog has a plain-English guide to AI agent guardrails and permissions for non-technical colleagues.

How can an AI Agency UK team help you meet these expectations?

Start with an inventory of every agent that can act, score each one on the NCSC's five dimensions and run the preflight checks against its environment. Most firms find at least one agent with more autonomy than its score justifies. As an AI Agency UK team, with AI developers in London who build signed-off agents for financial firms, we run that review and put one workflow live with the full set of guardrails in a 14-day Proof Run. The AI Agency London services we offer are on our services page. We are a technology provider and do not give regulatory advice, so your compliance team stays in charge of how these controls map to your own obligations.