Managing risk to accelerate agentic AI value creation

John Cuneo, worldwide AI solutions engineer, financial services at Cisco, describes how banks can move faster by connecting the risks and objectives of individual use cases to the capabilities needed to operate them, rather than waiting for universal agentic artificial intelligence readiness

A successful agentic AI pilot can leave a bank with an uncomfortable gap: the agent has demonstrated what it can do, but the institution has not demonstrated that it can reliably control it.

This is a question of organisational maturity. The excitement around an agent’s capabilities can run ahead of the engineering and operating discipline needed to put those capabilities into production. Financial services institutions should have an advantage here, with a long history of risk‑managed operating discipline. At Bank of England roundtables, summarised in February 2026, participants broadly supported the existing principles-based regulatory framework as providing room to innovate. They also described cautious second-line review as a potential deployment bottleneck, although views differed on whether that caution was excessive.

The challenge is to translate that governance experience into controls that can operate at agentic AI speed. Risk management should help teams get past analysis paralysis, establish what is permissible and build the capabilities needed to proceed with confidence. Think of the rails beneath a bullet train rather than the bumpers in a bowling alley. The purpose is to enable speed along a defined route. For agentic AI, that means making the permitted activities, required safeguards and conditions for intervention clear before accelerating.

A larger blast radius

An assistant confined to generating responses can still mislead a customer or disclose sensitive information. Give that system access to tools that update records, move money or execute trades, and its errors can directly affect financial and operational systems.

Harmful behaviour does not always require an obviously prohibited tool. An attacker may redirect an agent into using legitimate capabilities for an unintended purpose. Cisco’s Integrated AI Security and Safety Framework v2 distinguishes this goal-hijacking from agentic autonomy failures, including excessive agency, goal drift and reward hacking, which can arise without an identifiable external instruction.

The issue becomes more complicated when an agent delegates work to other agents. A banking assistant might ask one agent to analyse cashflow and another to initiate a transfer. Assessing each in isolation would fail to identify whether their combined actions violate the customer’s instructions.

Accountability therefore cannot depend solely on the person interacting with the assistant. The institution needs clear ownership of the service, its delegated authority and its operation. The National Institute of Standards and Technology’s (NIST’s) AI risk management framework playbook distinguishes system oversight from the roles of people using the system.

Start with the customer’s outcome

Consider a hypothetical assistant in a retail bank’s mobile app. A customer wants to understand their position across accounts, identify recurring expenses and decide how much money they can reasonably set aside.

That requires more context than a list of familiar subscription providers. Regular pet food purchases may matter just as much to the customer’s monthly cashflow.

For the bank, the opportunity could include better retention and appropriate uptake of additional services, including wealth management. Those are objectives to test, not benefits to assume. The investment case should account for operating costs, customer support and the cost of managing exceptions.

The assistant should retrieve only information the customer is entitled to access. Financial figures should come from authoritative bank systems, with calculations checked rather than left to the model to improvise.

The next question is what the assistant might do with that information. It could prepare bill payments for customer approval. A more independent version might execute payments under an explicit standing mandate, within defined limits and where permitted. A request outside those limits should require renewed authorisation or be declined.

Financial figures should come from authoritative bank systems, with calculations checked rather than left to the model to improvise

That distinction matters. Approval of each payment is different from permission to act repeatedly within an agreed scope.

The assistant should also respect the customer’s wider financial commitments. Transferring money into an investment account must not defeat a requirement to preserve funds for scheduled bills. Access to an authorised transfer tool does not make every proposed transfer acceptable.

This is where broad statements about responsible AI need to become specific engineering requirements.

Establish what the institution must demonstrate

Business, risk, compliance and technology teams should begin with the intended outcome, applicable obligations and the material risks of this particular service. They can then identify the assurance, controls and evidence required to support its proposed activities. This is the premise of use case operationalisation frameworks such as AI-GRACE.

Assurance should establish fitness for the task. Can the assistant distinguish recurring expenses from isolated purchases? Does it handle incomplete account information appropriately? Can it recognise a request falling outside its remit?

Security testing should examine the deployed system, including the model, tools and reusable agent instructions, for vulnerabilities and susceptibility to manipulation. Successful component tests should not substitute for testing their interactions. At its June 2026 meeting, the Bank of England’s AI Consortium discussed this need to assess both interconnected AI systems and their individual elements.

Run-time controls must enforce the boundaries under which the service was assessed, including customer-specific access, transaction limits, resource limits and checks before execution. Input and output inspection can help, but instructions telling an agent to behave are no substitute for enforced permissions. The Cisco framework identifies least-privilege tool access, explicit approval gates, bounded execution and independent outcome verification as relevant controls.

For this assistant, a transfer that would breach the agreed balance protection should be blocked before execution. Uncertain or exceptional situations should be routed for appropriate review. Human accountability remains essential, but a person should not have to inspect every internal step for the system’s boundaries to hold.

Where a necessary capability is missing, the bank has a concrete choice: close the gap and reduce the proposed scope, or postpone deployment

Evidence needs to connect these activities. The bank should be able to reconstruct the relevant customer instruction, information used, approvals, control decisions, actions and outcomes. It also needs records of the tests supporting deployment and the versions assessed. Retention and access should reflect the sensitivity of that information.

The point is to establish whether each required capability is sufficient, only partially sufficient, absent or not yet demonstrated.

An infrastructure team saying “We have an AI cluster” has answered only part of the question. Resilient infrastructure might support service availability. It does not establish that customer information is isolated, transactions are properly authorised or problematic behaviour can be detected and contained. Equally, owning a security product does not prove that its controls function in the deployed workflow.

Release what can be supported

The deployment decision should follow from that assessment. Applicable obligations must be satisfied, controls must demonstrate adequate performance, and an accountable owner must accept the remaining risks within the institution’s risk appetite. The service also needs monitoring and a workable response when conditions change. NIST’s playbook explicitly addresses residual risk, post-deployment monitoring and recovery.

Pre-production testing cannot prove future retention or revenue gains. It can support a decision to proceed with operating measures that test whether those benefits actually materialise.

Where a necessary capability is missing, the bank has a concrete choice: close the gap and reduce the proposed scope, or postpone deployment. It may be able to release the spending analysis service while withholding payment execution.

This is where faster delivery can originate. Engineering knows what must be built; reviewers know what must be demonstrated; the business knows which value can be pursued now.

The use case focus should operate within existing governance, not become another parallel approval process. Enterprise-wide assessments remain necessary, including for shared dependencies and aggregate exposure. But a particular service should not automatically wait for the institution to solve every readiness problem associated with every possible agent.

Later use cases can reuse applicable obligation mappings, tested controls, evaluation methods and evidence arrangements. Their assessments can concentrate on whether those capabilities remain sufficient and what additional gaps must be closed.

Permission should not be inherited with the technology. New actions, data, jurisdictions or levels of independence can change the requirements. A good operating record supports reassessment – it does not, by itself, justify greater authority.

The practical question for the next project is therefore: what must we demonstrate to operate this use case, with this degree of independence, and which capabilities are missing?

Answering it connects risk management directly to investment and delivery. Banks can pursue useful outcomes sooner, avoid building beyond their ability to control a service, and make subsequent deployments less repetitive. That is how governance maturity can become an advantage in agentic AI.

スポンサーコンテンツ