Are AI agents safe for banks and asset managers?

The short answer

AI agents are safe for banks and asset managers only when they run on infrastructure that strictly constrains what they can see and do — declared tools, scoped credentials, isolated tenants, bounded execution, recorded approvals and complete audit. The model is the least controllable component in the stack, so a securable design assumes the model can be wrong or manipulated and makes the blast radius small and observable.

Framed that way, the question shifts from "is the AI safe?" to "is the platform around the AI securable?" — a question security teams already know how to evaluate. Agents are privileged automation: software acting on systems with credentials. Financial institutions have run privileged automation for decades; what is new is non-determinism in the middle, and the controls that answer it.

The actual risk surface

Security reviews of agentic systems converge on a handful of concrete risks — most of them about the surroundings, not the model weights:

• —Ungoverned tool access — an agent wired directly to databases or APIs with broad permissions; one bad reasoning step becomes a data exfiltration or an unwanted write.
• —Prompt injection — malicious instructions hidden in content the agent reads (documents, emails, web pages, even data fields) that redirect its behavior.
• —Credential sprawl — API keys embedded in prompts, code or configuration, visible to the model and to logs.
• —Data leakage into telemetry — prompts and completions containing client data landing in logging and monitoring systems with weaker access controls.
• —Shadow agents — undeclared scripts and bots built by enthusiastic teams, invisible to security until an incident surfaces them.
• —Tenant bleed — in multi-client platforms, insufficient isolation letting one tenant's agent touch another's data.
• —Unbounded execution — runaway loops consuming budget, hammering internal systems, or retrying destructive actions.

The security model that answers it

Each risk has a structural countermeasure, and together they describe what a securable agent platform looks like. Capabilities are explicit: every agent is declared in a versioned registry with its tools, permissions and schemas, and nothing undeclared can run — which converts shadow AI from a discovery problem into an impossibility. Tools are least-privilege: agents call narrow, schema-typed interfaces (increasingly MCP-based) rather than raw systems, each gated by allow/ask/deny policy, with consequential actions pausing for recorded human approval.

Identity and secrets follow enterprise practice: agent invocations authenticate with verified tokens under the institution's identity provider; credentials live only in scoped vaults, injected at call time, never present in prompts, descriptors, code or traces — a property that should be contract-tested, not asserted. Isolation is layered: per-tenant separation enforced in the data layer (row-level security or stronger), per-workspace credential scopes, per-tenant rate limits and quotas. Execution is bounded: hard ceilings on duration, tool calls and tokens per run, with cancellation. And everything is observable: per-step traces and an append-only audit log make any run reconstructible — with redaction guarantees so the observability itself does not become the leak.

Prompt injection deserves its own paragraph

Prompt injection — adversarial instructions embedded in content the agent processes — is the attack class most specific to LLM systems, and no current technique eliminates it at the model layer. Mature deployments therefore manage it architecturally: agents read from curated, declared sources rather than the open web; retrieved content is treated as data, not instructions, wherever the harness allows; tool permissions are scoped so a hijacked agent still cannot reach beyond its narrow declared surface; consequential actions sit behind approval gates; and output schemas reject results that do not match the expected shape.

The honest posture for financial institutions: assume injection attempts will eventually reach any agent that reads externally influenced content, and design so the worst realistic outcome is a wasted, fully logged run — not a data exfiltration or an unauthorized action.

Questions CISOs should ask any agent vendor

A practical diligence list, usable in RFPs and security reviews:

• —Can you enumerate every agent, tool and permission from one source of truth — and prove nothing outside it can execute?
• —How are credentials stored and injected? Show the control that keeps secrets out of prompts, logs and traces — is it contract-tested?
• —What exactly does the LLM provider receive, where is it processed, and is client data used for training? (The answer should be a documented data flow, and no.)
• —How is tenant isolation enforced — at the database layer or in application code? What did your last isolation test find?
• —Which actions can agents take without human approval, and is that grading a policy we control?
• —What are the per-run execution bounds, and what happens when they are hit?
• —Can we replay any historical run — version, tool calls, data touched — and what is the audit retention?
• —Which third-party tools can agents reach, and what review gates an addition to that registry?
• —What is your model-failure and injection incident-response playbook?

The verdict

Whether agents are safe is a property of the deployment, not the technology — and both answers exist in the market today. Ungoverned agents wired broadly into financial systems are an incident in waiting. Governed agents on a constrained, observable, approval-gated runtime are arguably easier to secure than the human-driven swivel-chair processes they assist, because every step is typed, policy-checked and logged at a granularity manual work never was. The security organization's job is to make sure only the second kind exists in the building.