Free executive playbook.

A supervisor has put a date on this question. On 7 July 2026 the Chair of the ECB's Supervisory Board wrote to the chief executive of every significant institution it directly supervises about AI-enabled cybersecurity threats (letter SSM-2026-0301), requiring an assessment "without delay" and a comprehensive action plan — resources allocated, clear roles and responsibilities assigned, timelines for implementation defined — submitted to the Joint Supervisory Team by 31 October 2026, after which the ECB runs a horizontal analysis across the plans to identify trends and shares the conclusions back. It was the first letter on the ECB's letters-to-banks page in more than four years (the previous entry is 30 March 2022, a gap of 1,560 days), and the supervisor asked for plans, not incident reports. Nothing in that letter binds a bank in Vietnam. What it gives you is a major prudential supervisor's own written list of what it expects to find. Between a supervisor asking for plans and a certification your bank already holds sits the actual gap, and it is not a tool: it is ownership. ISO/IEC 42001, the AI management standard, carries thirty-eight Annex A controls, none of which addresses identity management — while ISO/IEC 27002:2022 clause 5.16, the identity-management guidance behind the ISO/IEC 27001 most banks are already certified against, covers non-human identities across their lifecycle and requires them to be registered through their own approval process, with an owner, and deleted when no longer needed. Both ISO readings sit behind a paywall and are this series' reading rather than quotations; the free, quotable version of the same requirement is the ECB's own Annex 1, which asks for continuous verification of "users, devices, applications, application programming interfaces (APIs) and service accounts". So the honest executive sentence is not "no standard covers agent identity"; it is the standard we are certified against already requires this, and we are not applying it to our agents. The Agent Attack-Surface Map names five surfaces plus one control layer, ranks them on this framework's own analytic reading rather than in the intuitive order, and its central finding is that the surface it ranks first is the one with no owner — the tool's own description, a plain-language manual the agent reads as instruction. Not code, so no engineer reviews it. Not user input, so no filter inspects it. The model is not the vulnerability. The permissions are.

What's inside

  • Why now — a supervisor asked for plans, not incident reports — the 7 July 2026 letter to CEOs (SSM-2026-0301) and the 31 October 2026 filing deadline, with resources allocated, clear roles and responsibilities assigned and implementation timelines defined, followed by a JST engagement and an ECB horizontal analysis across the plans to identify trends — expressly a search for trends rather than a ranking of one bank's plan against another's, which is the single most over-read sentence in the letter; why the supervisor is acting on a demonstrated capability ahead of loss experience, its stated concern being that emerging AI models identify vulnerabilities and generate working exploits "at unprecedented speed", compressing the timeline between discovery and exploitation — an assertion the letter makes without publishing an interval, so this playbook quotes none; the letter's own hedge, that these developments "do not introduce entirely new risks" but "significantly amplify the speed and scale at which such risks materialise"; DORA (Regulation (EU) 2022/2554) as the anchor, described as remaining "highly relevant and valid" rather than superseded, plus the two accommodations that came with the demand — the IT Risk Questionnaire collection deferred from September 2026 to February 2027, and case-by-case adjustment of on-site inspections and deep dives; where the genuinely systemic concern actually lives, which is the same-day ESRB warning on "systemic cyber risks stemming from frontier artificial intelligence models" and not the letter itself; and why quantum is explicitly out of scope — post-quantum cryptography "must start now", but encryption risk is deferred to a separate letter · and what the evidence does not yet show, stated up front rather than buried: there is no public, confirmed case of an AI agent or large language model causing direct financial loss at a bank and no enforcement action to point at, the threat literature being overwhelmingly vendor telemetry and academic red-teaming — which is not a reason to wait but is the reason the supervisor asked for a plan instead of a report, and the reason a bank should understand itself to be funding defence against a demonstrated capability rather than an observed epidemic
  • The map — five surfaces plus one control layer, each with the single question that exposes whether it has an owner: S3 tool and action, where the attacker manipulates the tool's description rather than its code · S1 instruction, where anything the agent reads becomes an instruction — email, document, ticket, page, dataset · S4 identity, where the target is the credential and its delegation chain · S2 knowledge, where it is the retrieval corpus · S5 supply chain, where it is model weights, frameworks, connectors and packages · and S6 containment and observability, which is deliberately not a sixth surface but the answer to all five, because a framework that lists it as a peer invites a reader to "cover all six" when the correct move is to rank five and fund the one layer that limits every one of them
  • The hole — tool-description poisoning and the firewall fallacy — why this framework ranks the tool and action surface first, and, just as important, what that ranking does and does not rest on: it is analytic judgement, not a measured league table, because the threat documents this series cites (OWASP Top 10 for LLM Applications, NIST AI 100-2, NIST AI 600-1, MITRE ATLAS) are taxonomies and risk frameworks that publish no comparative attack-success rates, so a superlative such as "far above anything else on the map" would have no citation base and is not made here · the three checkable properties the ranking does rest on — the attack needs no privileged access because a tool description is content; the manual sits outside both code review and input filtering, so the two controls a bank already owns never inspect it; and the resulting request is indistinguishable from a legitimate one where it lands · and the rule this playbook holds itself to: a figure is published only where this series has traced the figure itself, whatever the standing of the body it is attributed to — which is why no percentage appears here and why the ranking is stated as judgement · the firewall fallacy, where your controls watch the channel the attack does not use, inspecting what a customer typed and what the model wrote back while the instruction that mattered entered through the tool manifest and left as an ordinary interface call · why the request that reaches core banking is entirely valid because it is — correct credential, correct format, wrong reason · and the control that actually answers it, which is not a better filter but decoupling execution from the model: the agent proposes, a deterministic policy engine authorises against pre-defined rules, and only then does anything execute, converting a problem of persuasion into a problem of authorisation, which is something a bank already knows how to govern · plus why the boundary still moves from the input to the action even though the input-layer defences are better than this series first said — the foundational demonstration is Greshake and co-authors (arXiv:2302.12173, 2023), which exploited real LLM-integrated systems with no direct interface to the model; the benchmark to argue it on is AgentDojo (arXiv:2406.13352, 2024), 97 realistic tool-using tasks including e-banking navigation and 629 security test cases, which finds attacks and defences both challenged and existing attacks breaking some security properties but not all; and Spotlighting (Hines and co-authors, arXiv:2403.14720, Microsoft 2024) reduced attack success from greater than 50% to below 2% on GPT-family models with minimal impact on task efficacy — which withdraws an earlier claim in this series that delimiting moves the rate only "by a few points" at a product-degrading cost. The conclusion holds on the correct ground instead: below 2% is not 0%, and a low-single-digit residual per attempt is not an authorisation control for a state-changing instruction into core banking
  • Where banking's oldest controls break — dual control, maker-checker, segregation of duties and privileged access management at machine speed: if the agent is the maker, generating hundreds of API calls a minute, no human checker reviews them and the control becomes a rubber stamp with an audit trail, worse than no control because it reads as compliant; if the agent is the checker, an algorithm is validating an algorithm, which voids the independence the control exists to supply; and privileged access management was built to rotate static credentials for named humans, so an agent created mid-request, acting once and terminating, has no session to manage and usually holds a long-lived secret instead because that was the fast way to ship it — against which the direction of travel is delegated, short-lived, attributable identity, a token recording both the human who granted consent and the agent that acted, so every automated action carries borrowed, verifiable authority · plus the ISO finding to take to your auditor next week, with no budget request: test your agents against clause 5.16, which names service accounts, API tokens, machine credentials and cloud service principals in scope, and which you are probably already certified against — a meeting rather than a capital request
  • The 3 gates, the Vietnam layer and the one-afternoon diagnostic — the three gates that must close before any agent holds a production credential for a state-changing action, stated here exactly as the playbook states them so the page and the PDF cannot drift apart: 1 · execution decoupled from the model — the model proposes, a deterministic policy engine authorises, only then does anything execute, with no exception for pilots; 2 · identity delegated, short-lived and attributable — a token proving both the agent and the delegating human, and no standing secrets anywhere in the path; 3 · containment before the entitlement — action logging a supervisor could read, a bounded blast radius, and a human approval gate for high-risk operations. Putting an owner on every tool description and under change control is the first of the five application steps rather than a gate, and is listed as such · the honest local reading first, because it changes what you should buy: for a mid-sized Vietnamese bank running read-only assistants over a legacy monolithic core the tool surface is largely prospective, since a legacy core does not hand an agent a menu of dynamic discoverable interfaces and very few banks have granted agents real production entitlements yet, so what is exposed today is the knowledge surface — what those assistants can retrieve, what they may see, and what leaves the building inside a payload to a foreign-hosted model — and anyone selling a Wall-Street threat model to a bank in this position is selling the wrong year's problem · then the Vietnam layer, which does not regulate AI agents as such and does not need to: SBV Circular 09/2020/TT-NHNN, in force 1 January 2021, requiring monitoring and logging, network security, malware controls, incident management, annual review of the information-safety regulation and access control in which every account belongs to one named user, with shared accounts requiring approval and per-moment attribution — so an agent on a shared service account is already outside that text · SBV Circular 50/2024/TT-NHNN, effective 1 January 2025 with staged commencement and as amended by Circular 77/2025/TT-NHNN from 1 March 2026, requiring keys, PINs and biometric data encrypted or masked at rest, access by function, and every access to customer data monitored · PDPL 91/2025/QH15, in force 1 January 2026, with a seventy-two-hour breach clock, the Article 21(1) impact assessment filed within sixty days of first processing as a duty in its own right rather than one triggered by profiling or automated decisioning, a data-protection officer duty and cross-border penalties reaching five percent of prior-year revenue, because an agent breach is a personal-data breach · and AI Law 134/2025/QH15, in force 1 March 2026, whose Article 35 finance-sector window to approximately 1 September 2027 covers pre-existing systems and is a planning runway rather than an exemption — a different instrument from Digital Technology Industry Law 71/2025 · plus the six questions for your next technology committee — one for each of the five surfaces and a sixth for the control layer, which is the only one that asks whether you would find out at all — where any answer of "the platform team would have to check" means that surface has no owner, and the counter-arguments carried rather than answered away: phishing and ransomware still cause the overwhelming majority of actual losses so this is new-surface hygiene rather than a re-prioritisation of the security budget, S4 is identity and access management and S1 is input validation so a siloed "AI security programme" can pull funding from zero-trust work that would have covered both, an objective "number one hole" is close to unfalsifiable so the order is the evidence's order and you should rank your own, and the surface missing from the map is human over-reliance on agent output — a read-only assistant producing a wrong compliance summary an executive then acts on is a regulatory problem with no cryptographic component at all, and may be the most probable failure in a Vietnamese bank in 2026

Five pages · free with a member sign-in · PDF.

One note on the downloadable edition, in the interest of the same traceability this playbook argues for. It was rendered on 6 September 2026, before the ranking claim on this page was corrected. Where the PDF says the tool-and-action surface carries "the highest measured attack rate", read this page instead: that ordering is this framework's analytic judgement, not a measured result, because the threat documents behind it — the OWASP Top 10 for LLM Applications, NIST AI 100-2, NIST AI 600-1 and MITRE ATLAS — are taxonomies that publish no comparative attack-success rates. The PDF's Vietnam table also frames the PDPL Article 21(1) impact assessment as applying to automated decisioning; that duty is unconditional. Everything else in it stands, and a corrected edition will replace it.

Watch: youtu.be/ZwoNSULGysc

Want the weekly version? Subscribe to The AI Architect Letter · Read the latest insights.