One Big Idea

The model is not the vulnerability. The permissions are. When you hand an AI agent the ability to do something inside the bank rather than merely to answer, the exposure moves with it — and it lands somewhere almost nobody is watching: the short plain-language manual that ships with every tool the agent is allowed to call.

Last week this letter asked what a bank owes the applicant its model just refused. This week the question moves one layer down, to the thing that acts rather than the thing that answers. A supervisor has just put a date on it.

On 7 July 2026 the European Central Bank wrote to the chief executive of every significant institution it directly supervises about AI-enabled cybersecurity threats. It required an assessment of the evolving threat landscape without delay and a comprehensive action plan — resources allocated, clear roles and responsibilities assigned, timelines for implementation defined — filed with the Joint Supervisory Team by 31 October 2026.

Be precise about what happens next, because it is the easiest thing in that letter to over-read. The ECB then runs a horizontal analysis across the submitted plans to identify trends, challenges and areas for improvement, and shares the conclusions back with institutions. That is a search for trends, not a ranking of one bank's plan against another's. The distinction changes what you should write: a bank that believes it is being graded against its peers produces a different document from one that has been asked to be useful. Write the plan to be useful.

Two framing details matter as much as the contents. It was the first letter on the ECB's letters-to-banks page in more than four years — the previous entry is "Leveraged transactions" of 30 March 2022, a gap of 1,560 days. And the supervisor asked for plans, not incident reports: its stated concern is models "capable of identifying software vulnerabilities and generating functioning exploits at unprecedented speed, compressing the timeline between vulnerability discovery and exploitation". The letter asserts that compression without publishing an interval, so no before-and-after figure is quoted here — and you should be sceptical of any deck that gives you one and attributes it to this letter.

Nothing in it binds a bank in Vietnam. What it gives you is a major prudential supervisor's own written list of what it expects to find.

The Insight · The manual nobody reads

When a board reads a letter like that, two reactions follow and both misfire. The first is to harden the prompt — buy a guardrail, filter the inputs, red-team the chatbot. The second is to file the whole thing as model risk and send it to model validation, where it becomes a document review of a system that changes weekly.

Both miss where the exposure actually sits. Your agent has tools, and every tool ships with a description: a short manual in plain language telling the agent what the tool does, what it needs, and when to use it. The agent reads that manual as instruction and trusts it completely. The manual is not code, so no engineer reviews it. It is not something a customer typed, so no filter inspects it.

Change the manual and the agent does something nobody asked for, using a permission you legitimately granted. When that request arrives at your core banking system it looks entirely valid — because it is valid. Correct credential. Correct format. Wrong reason.

Call it the firewall fallacy: the existing controls watch the channel the attack does not use. They inspect 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.

Framework of the Week · The Agent Attack-Surface Map

Five surfaces and one control layer, in this framework's ranked order rather than in numerical order:

  • S3 · Tool and action — the attacker edits the tool's description, not its code. This is where this framework ranks the highest exposure, and in most banks it has no owner at all.
  • S1 · Instruction — anything the agent reads: email, document, ticket, page, dataset. This is the delivery mechanism.
  • S4 · Identity — the credential and its delegation chain. This is the blast radius.
  • S2 · Knowledge — the retrieval corpus. For most banks in this region, this is the surface actually exposed today.
  • S5 · Supply chain — model weights, frameworks, connectors, packages. It arrives before you write a line of code.
  • S6 · Containment and observability — not a sixth surface. It is the answer to all five.

Be exact about what the S3 ranking is, because it is the claim most likely to be repeated without its caveat. It is this framework's analytic judgement, not a measured league table. The threat documents behind the taxonomy — the OWASP Top 10 for LLM Applications, NIST AI 100-2, NIST AI 600-1 and MITRE ATLAS — are taxonomies and risk frameworks. None of them is a benchmark and none publishes comparative attack-success rates across attack classes, so no superlative is claimed here and no percentage is quoted. The ranking rests instead on three properties a reader can check for themselves: 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 you already own do not inspect it; and the resulting request is indistinguishable from a legitimate one at the point it lands.

The reclassification of S6 matters just as much as the ordering. A framework that lists containment as a peer invites you to "cover all six" and spread the budget six ways. The correct reading is narrower and cheaper: rank your five surfaces, then fund the one layer that limits every one of them.

The control for S3 is not a better filter. It is decoupling execution from the model: the agent proposes an action, a deterministic policy engine authorises it against pre-defined rules, and only then does anything execute. That single move converts a problem of persuasion into a problem of authorisation — which is something a bank already knows how to govern.

The full map, with the surface table, the three gates that must close before any agent holds a production credential, the Vietnam layer and the six-question diagnostic as a worksheet, lives in the Frameworks library.

Use Case · Why the identity surface deserves your next hour

S4 carries the sharpest bank-specific finding, and it is the one your existing control library is least ready for. Dual control, maker-checker, segregation of duties and privileged access management were all designed around human speed.

If the agent is the maker, generating hundreds of API calls a minute, no human checker reviews them — you have a rubber stamp with an audit trail, which is 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; 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.

The direction of travel is delegated, short-lived, attributable identity: a token that records both the human who granted consent and the agent that acted, so every automated action carries borrowed, verifiable authority.

And here is the part to take to your internal auditor this week. ISO/IEC 42001, the AI management standard, carries thirty-eight Annex A controls, none of which addresses identity management. ISO/IEC 27002:2022 clause 5.16 — the identity-management guidance behind Annex A 5.16 of the ISO/IEC 27001 your bank is almost certainly already certified against — covers the full lifecycle of human and non-human identities, and requires non-human identities to be registered through their own approval process, with a named owner, and deleted when no longer needed. Service accounts, API tokens, machine credentials, cloud service principals: that is what an agent's credential is.

Both of those ISO readings sit behind a paywall, so treat them as this series' reading rather than as quotations, and check the clause text with your own certification body before either goes into an audit response. You do not have to take it on trust, though, because the supervisor has now said the operative part in a document anyone can open: Annex 1 of the 7 July letter asks for zero-trust principles including "continuous verification of users, devices, applications, application programming interfaces (APIs) and service accounts", alongside robust access controls with least privilege, multi-factor authentication and comprehensive logging. The service account is named at the top of the supervisory stack, in the same breath as the human user.

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. Testing that costs a meeting rather than a budget request.

A word on S1 while we are here, because the mitigation story is better than most security decks admit and this letter would rather be accurate than alarming. Published work on spotlighting — transforming an input so its provenance carries a continuous signal — reports attack success falling from above fifty percent to below two, with minimal impact on task efficacy. That is better than an order of magnitude and it does not carry the product-degrading cost the genre usually asserts. Deploy those defences. But below two percent is not zero, and the base rate is whatever volume an attacker chooses, so for a state-changing instruction into a core banking system the boundary still moves: check the action, not the input, and require human approval at the action boundary for anything that changes state.

Risk Note · The Vietnam layer already in force

Vietnam does not regulate AI agents as such, and it does not need to for these duties to bite.

SBV Circular 09/2020/TT-NHNN, in force since 1 January 2021, already requires monitoring and logging, network security, malware controls and incident management — and access control in which every account belongs to one named user, with shared accounts requiring approval and per-moment attribution. An agent running on a shared service account is already outside that text. Circular 50/2024/TT-NHNN, in force 1 January 2025 as amended by Circular 77/2025/TT-NHNN effective 1 March 2026, requires every access to customer data to be monitored. PDPL 91/2025/QH15, in force 1 January 2026, starts a seventy-two-hour breach notification clock, because an agent breach is a personal-data breach.

And AI Law 134/2025/QH15, in force 1 March 2026, at Article 35 gives pre-existing finance-sector systems an eighteen-month transition running to approximately 1 September 2027. Read that precisely, because the loose version of it is doing real damage in board papers: it is a transition for systems already in place, not a sector-wide exemption and not a grace period for whatever you build next quarter. It is a planning runway. The count of risk tiers in that law is not asserted here, and Vietnam's Prime Minister has not yet published the definitive high-risk AI list that will set the exact scope of conformity assessment for banking.

One more thing worth saying plainly, because most security decks will not: there is no public, confirmed case of an AI agent causing direct financial loss at a bank, and no enforcement action to cite. The threat literature is overwhelmingly vendor telemetry and academic red-teaming. That absence is not a reason to wait — it is precisely why the supervisor asked for a plan instead of a report. You are funding defence against a demonstrated capability, not an observed epidemic, and any vendor deck implying otherwise is describing a market rather than a loss experience.

The model is not the vulnerability. The permissions are.

One question for your next technology committee, and do not accept a roadmap as the answer: name the owner of every credential an AI agent currently holds, and tell me how long each one lives. If the answer is "the platform team would have to check", that surface has no owner. The cheapest control on this map is the permission you have not granted yet — and every week a bank runs agents without an entitlement model, that control gets more expensive to install.

Latest Video

This week's briefing — Video 14: Can you stop an AI agent that's already running? — walks the map end to end on screen in 8 minutes 17 seconds, from the tool description nobody reviews through to the containment layer that decides whether you would find out at all.

Watch: youtu.be/ZwoNSULGysc

The full deep-dive — the two wrong reactions, all five surfaces with the reasoning behind the order, the S4 identity finding, the Vietnam layer, the weekend nobody was driving, and the sources and caveats in full — is in The Agent Attack-Surface Map: Where an AI Agent Actually Gets Attacked Inside a Bank.

The free five-page playbook in the Frameworks library turns it into a worksheet for your own stack.

Reply and tell me who owns the tool descriptions in your bank — most teams have never asked the question, and the answer is usually that the manual an agent trusts completely has no reviewer at all. I read every response. Forward this to a banking executive who is about to grant an agent its first production credential.

Was this forwarded to you? Subscribe to The AI Architect Letter — free, every Saturday.

Minh Tran · AI Business Architect · LinkedIn · Workshops & advisory: aibusinessarchitect.ai