An AI agent can have a unique identity, a spending limit and a stop button. None of those names the person responsible when its work changes a customer record or triggers a refund.
On 15 October 2026, the Financial Stability Board published its final Sound Practices for Responsible Adoption of Artificial Intelligence. Its 12 practices are a voluntary, proportionate toolkit for financial institutions, not a new law. They connect organisation-wide governance with the risks of individual AI use cases. For teams deploying agents, the useful question is concrete: who owns this workflow, when must a human approve an action, and how will intervention work?
An agent ID tells you which system acted. It does not tell you who is accountable.
The FSB report addresses agent identifiers in its discussion of documenting AI use. Its human-oversight material then considers risk-based approval triggers, accountable individuals and ways to intervene, including pausing an agent or removing access where appropriate. These are related controls, not interchangeable ones. See the final report's PDF pages 30 and 56–57.
An identifier helps investigators distinguish one agent from another. An accountable owner should understand the use case, its limits and the escalation path. A technical stop can restrict an action. It cannot decide who has responsibility for the work or whether the organisation's wider governance is adequate.
The FSB encourages boards and senior management at financial institutions to use the practices when refining existing governance, risk-management and control frameworks. Teams outside finance can use the workflow questions as an engineering exercise; this report does not, by itself, impose a universal legal requirement on every business deploying an agent.
Start with one consequential workflow
Take a refund workflow as an example. Before expanding the agent's permissions, write a short operating record that answers five questions:
- Who owns it? Name the accountable person for the use case and the person who handles an escalation. Do not put only the agent's service account in this field.
- What can proceed? Define the actions and limits the agent may use without further approval. Be specific about the connected service, data and amount limits rather than relying on a general instruction to be careful.
- What needs approval? Set risk-based triggers and identify who can approve an exception. Record what happens while a request is waiting; pending approval is not completed execution.
- How can someone intervene? Identify the appropriate pause or access-removal mechanism, who may use it, and how the team will test it. Check the actual connected path rather than assuming an interface button controls every route.
- What evidence will you inspect? Keep the policy decision separate from the service's reported outcome. Compare what was allowed, blocked or escalated with what the connected system actually reports doing.
Test those boundaries with an isolated, harmless workflow before relying on them for consequential work. Include an allowed action, an approval-required action and a denied action. Record the limits of the test as well as its result. A successful check of one connector is not proof of organisation-wide coverage.
A policy decision is not a business outcome
An ALLOW decision says the policy permitted the requested action. It does not, by itself, establish that a refund settled. An approval request says review was required, not that a human approved it. A signed evidence package can help verify the integrity of the bytes it covers; it does not certify compliance or prove every external effect.
This distinction matters during an incident. The owner needs to know both what the control decided and what the connected service reported. Missing or failed execution should remain visible rather than being folded into a generic success label.
Where HaltState fits
HaltState checks connected actions against configured policies before execution. Its public control room shows recorded policy decisions and reported outcomes, including a synthetic retail refund workflow. That example is useful for inspecting the difference between permitted work, review and blocked actions; it is an owned demonstration, not a customer case study.
A control layer does not replace the accountable owner, the institution's risk framework or controls outside the connected path. It gives the team a technical place to apply action limits and investigate the resulting records.
Choose one workflow today. Name its owner, write down its approval triggers and test its intervention path. Then compare that operating record with the refund workflow in the HaltState control room and the agent integration guide.
Sources
- Financial Stability Board announcement, 15 October 2026.
- Sound Practices for Responsible Adoption of Artificial Intelligence: final report, especially PDF pages 30 and 56–57. The report addresses a wider set of governance and lifecycle practices than this agent-focused briefing.
- HaltState public control room and integration guide for the separately described product example. No FSB endorsement is implied.
General information only. This article and video are not legal advice. Applicability depends on jurisdiction, role, activity and current requirements; obtain qualified legal advice for decisions about your own circumstances.