The 9 questions bank risk teams ask before an AI agent ships

Before an AI agent reaches production in a bank, model performance is only one part of the review. Risk teams also need to understand the boundaries around the agent: what it can reach, what it can change, when approval is required, and how the system responds when the workflow does not go as planned.

A successful demo can make an agent look ready before the infrastructure around it is. The model responds correctly, its tools work, and the workflow completes in a controlled environment. Once that same agent can read customer data, call internal services, invoke MCP servers, update records, or trigger downstream processes, the risk profile changes. The bank must govern not only the outcome, but how the agent reaches it.

That shifts the review from model performance to execution control. Risk teams need a clear record of who made each request, what that workload was permitted to access, and what happened next. That history must also remain available when the workflow is reviewed later. They also need defined behaviour for partial failures, retries, human approvals, version changes, data movement, and operations at scale.

These are infrastructure questions as much as AI questions. Agents complicate that review because a single workflow may run for hours, behave non-deterministically, and act across privileged systems. The controls around the model therefore matter just as much as the model itself. Banks need to know who is acting, where data can move, how execution is recorded, how failures are recovered, and how the system will be operated after deployment.

1. What exactly can this agent do?

The first risk question is not which model the agent uses. It is what the agent is permitted to do. A banking agent may read customer records, call internal APIs, invoke MCP servers, update case data, initiate workflows, or delegate work to another agent. Each capability increases the impact of unexpected behaviour, so permissions need to be enforced outside the model itself.

Diagrid Catalyst policies provide that runtime boundary. Applications, agents, and MCP servers receive workload identities, while access policies determine which workloads may communicate. Unauthorized requests are rejected at the service-invocation boundary before they reach the target.

That separation matters because the model is not an authorization system. Prompt injection or faulty reasoning may cause an agent to request an operation outside its intended scope, but runtime policy remains deterministic. The bank can therefore enforce what the agent may access independently of what the model attempts to do.

2. What data can the agent access, and where can it go?

Permission to invoke a service is only part of the risk picture. Banks also need to understand what data crosses each boundary, where it is processed, and which credentials enable access. A single workflow may touch customer records, transaction data, internal APIs, model providers, state stores, and external services.

Catalyst's security architecture keeps the control plane outside the application data path. Configuration flows into the data plane, while application payloads remain within the data plane and the applications processing them. Regions and projects provide additional isolation boundaries, and BYOC deployments can keep the data plane inside the customer's own cloud when residency requirements demand it.

Secrets are handled separately from application logic. Catalyst can use its managed secret store or integrate with Azure Key Vault, AWS Secrets Manager, and HashiCorp Vault. For a bank risk team, this makes data movement and credential use easier to review because both can be defined independently of the agent's prompt or code.

3. Can every action be tied to a specific identity?

Shared credentials weaken both authorization and accountability. If several agents appear to downstream systems as the same generic application, the bank may know that a request occurred without being able to establish which workload initiated it.

Catalyst gives each workload its own identity and uses SPIFFE-based certificates and mutual TLS across Catalyst workloads. Policies are evaluated against those identities, allowing a research agent, payment agent, MCP server, and customer-service agent to operate under different permissions even within the same broader system.

Role-based access control also governs human and machine access to the Catalyst control plane, separating platform administration from workload permissions. For regulated systems, identity is not just a security feature. It underpins attribution, authorization, and auditability.

4. Can we reconstruct exactly what happened?

When a customer disputes an outcome or an internal review investigates a failed process, application logs may not provide enough evidence. The bank needs the execution record itself: which activities ran, what inputs and outputs were produced, which tools were called, where the workflow waited, and where it failed.

Catalyst records workflow execution history and exposes each execution through graphs and event histories. Operators can inspect activity inputs, outputs, errors, durations, and the sequence of events that produced the final outcome, while metrics, distributed traces, and structured logs provide the surrounding operational context.

For stronger integrity guarantees, Catalyst also supports verifiable execution. Workflow events are cryptographically signed as they are written, creating a tamper-evident history that is verified when read. This allows the bank to detect whether execution history has been modified, giving investigations and audits a stronger evidentiary foundation.

5. What happens when a model, tool, or dependency fails?

Agents rely on systems they do not control. Model providers throttle, APIs time out, databases become unavailable, MCP servers fail, and network calls drop. Production architecture must assume these failures will happen and define how the workflow responds.

Catalyst Workflows use durable execution so workflow progress survives crashes, deployments, activity failures, and other interruptions. Completed work is preserved in workflow history, allowing execution to recover from the appropriate point instead of restarting the workflow from scratch.

Catalyst also supports resiliency policies for calls to workloads and components. Retries, timeouts, and circuit breakers can be enforced at the runtime layer rather than rebuilt throughout agent code. This gives bank risk teams explicit failure controls to review: what gets retried, when requests time out, when a failing dependency is isolated, and how execution recovers.

6. Can a retry repeat a sensitive action?

Retries improve reliability, but they can create risk when an activity has a financial or operational side effect. An agent may update a payment instruction, create a transfer request, modify a case record, or send a customer communication. If the downstream action succeeds but completion is not recorded before a failure, the same request may be attempted again.

Durable execution preserves completed workflow history during recovery, but side-effecting activities still need idempotency where duplicate execution would be harmful. Transaction references, workflow instance IDs, idempotency keys, or conditional writes can help the receiving system recognize that an operation has already been processed.

For risk teams, the key control is not simply whether retries exist. It is whether every sensitive operation has a defined duplicate-handling strategy. Read-only actions may be safe to repeat. Financial side effects require stronger protection.

7. Where must a human remain in control?

Automating a workflow does not mean handing every decision to the agent. The agent may do the groundwork, such as collecting evidence or preparing a recommendation, while a person remains responsible for approving the step that carries greater risk.

Catalyst Workflows support external events and durable waiting, allowing approval to become part of the workflow itself. The workflow can persist its state, suspend without holding a thread or connection open, and resume when the approval event arrives. If approval does not arrive in time, a durable timer can trigger the next escalation step.

The result is an enforceable boundary between autonomous work and decisions that still belong to a person. Approval becomes part of the workflow record, so operators can see why execution stopped and what caused it to resume. Human oversight is far stronger when the runtime enforces that checkpoint instead of relying on a process people are simply expected to follow.

8. What happens when the agent changes while workflows are still running?

Production agents evolve. Models change, prompts are refined, tools are replaced, dependencies move, and workflow code is redeployed. Long-running workflows make those changes harder because an execution that started under yesterday's code may still be active when today's version goes live.

Catalyst reconstructs durable workflows by replaying recorded history through the orchestrator. Workflow changes therefore need to preserve the execution path expected by workflows already in flight. A change that works perfectly for a new workflow can still break an older one if replay no longer matches its recorded history.

Catalyst documents workflow versioning strategies for handling that transition, including which changes are replay-safe and how incompatible changes can be migrated. Catalyst does not replace the bank's broader governance over models, prompts, or tools, but it ensures workflow changes account for executions already in progress. The deployment question becomes simple: what happens to every in-flight workflow when the new version goes live?

9. Can we operate and recover it when it is no longer a pilot?

Success creates its own operational challenge: volume. Once usage grows, operators may be dealing with thousands of workflows in different states at the same time. Some are still running, some are waiting, and others have failed against the same dependency. Operations teams need to find the common problem and recover the affected work as a group rather than investigate every execution from scratch.

Catalyst's workflow operations provide a project-wide view of durable workflow instances, including filtering, execution graphs, event histories, inputs, outputs, and controls for individual executions. Its observability capabilities add metrics, traces, and structured API logs, helping operators move from a platform-level symptom to the workflow and activity responsible for it.

Production readiness therefore means more than completing the happy path. A bank needs an execution environment in which agents can be identified, constrained, observed, investigated, interrupted, recovered, and operated at scale. Catalyst brings those controls into the same runtime coordinating the work.

From model review to execution control

Taken together, the nine questions point to the same conclusion: agent risk cannot be managed at the model layer alone. Identity, authorization, data boundaries, durable execution, human approval, verifiable history, resiliency, versioning, and operations all surround the model.

That is the role Catalyst is built to play. The agent framework defines how the agent reasons and what work it attempts. Catalyst provides the durable, governed execution layer that controls how that work reaches production systems and how teams retain control as conditions change.