Deploying agents inside the biggest, most secure global banks

‍What it takes to run an AI agent on a customer’s infrastructure, with their approved vendors, without changing the system their team validated.

AI agents are moving from pilots into the core operations of global banks, and the bar for deploying them is rising fast. For institutions of this scale, a shared cloud platform is just the starting point. Many need dedicated infrastructure, deployment in their own cloud accounts, and tight control over which models and vendors ever touch customer data.

That’s exactly the problem Bretton Enterprise is built to solve. Some Bretton customers run on our managed multi-tenant platform, but the largest regulated institutions also require formal review for every change, and for them, deployment architecture is part of the security model. From dedicated, single-tenant infrastructure to an institution’s own environment, Bretton lets the security boundary move while the agent and the system it runs on stay the same.

Choosing a deployment model

Every institution’s requirements are different, so Bretton offers three deployment options: our shared platform, dedicated infrastructure, or the institution’s own cloud account (bring your own cloud, or BYOC). Dedicated and BYOC deployments can also restrict outside access to approved providers and dependencies only. We help each team choose the simplest option that gives them exactly what they need. Here’s how the options compare:

Data residency and external access

In customer-controlled deployments, Bretton is designed to run on infrastructure the institution already governs: its own compute, storage, encryption keys, identity provider, and monitoring. Customer data stays in that environment rather than passing through Bretton’s systems to be processed. The main exception is usage telemetry, which flows back to Bretton’s control plane. When Bretton needs access to logs, traces, or other observability data for support, it is granted just in time and only with the institution’s approval.

‍

External access is controlled the same way. Every model provider, document processor, enrichment vendor, or web research tool is another place customer data could go, and another vendor the institution’s risk team has to review. So the agent can only reach providers the institution has approved, and two layers enforce that. Every external call goes through Bretton’s agent gateway, which applies allowlists and rate limits, and each outside API is an explicit tool that has to be enabled and configured before an agent can use it. Beneath that, network egress rules can hard-block outbound traffic so only specifically approved endpoints are reachable.

Model providers are held to the same standard. Bretton maintains zero data retention (ZDR) agreements with every model provider it uses, so inference requests are processed in memory and never persisted. Once a response is returned, the provider keeps no record of the prompt, the documents, or output, which means customer data lives on a model provider’s infrastructure only for as long as the request takes. 

‍

How substitution and model changes work

A common first question when moving an AI agent into a customer’s own environment is simple: if everything around the agent changes, does the agent change too? The answer depends on what’s being swapped.

Most of what surrounds the agent can adapt to the institution. Inference can run through an approved Amazon Bedrock endpoint, logs and telemetry can flow into the monitoring tools the team already uses, and data can live in the institution’s own PostgreSQL and S3-compatible storage. Any replacement has to meet Bretton’s compatibility and quality requirements, so the agent itself stays the same.

The model is the exception, because it’s what the agent reasons with. Each deployment keeps a single list of approved models, and the agent can only call a model on that list, in the approved region.

Every new model has to earn its place on that list using the institution’s own history. We re-run real past cases with the candidate and check its answers against both the current model and the decisions the institution’s team actually made. Then we re-run the current model on the same cases to see how much variation is normal, and the candidate has to hold up against that baseline. Across workflows, the agent harness gives every model a strong head start: in BackOfficeBench, our evaluation of seven frontier models on 500 KYC and KYB cases, 97% of cases that needed review were escalated inside the Bretton harness, compared with 78% without it.

For screening alerts, a new model has to do at least as well as today: no more missed escalations, false-positive auto-clears within 1 percentage point of normal variation, and no real matches cleared, with every changed decision reviewed blind.

Capabilities in restricted environments

Some institutions limit what the agent can connect to even further, and that involves a tradeoff. In a fully disconnected environment, features that rely on live web research, commercial enrichment, external screening providers, or hosted frontier models aren’t available.

To make that tradeoff clear up front, each deployment profile spells out how every capability is handled. A capability either runs locally inside the deployment, is served through an endpoint the institution has approved, is allowed out through a defined network path, or is unavailable in that profile. There is no hidden fallback to an unapproved service, so what the institution sees in the configuration is what the agent can actually do.

Day-to-day operations

Deploying into a customer’s environment is the easy part. Operating there safely, release after release, is where Bretton has invested most. In practice, that comes down to five things:

• Every release is traceable. Each part of a deployment, from code to infrastructure and database changes, is versioned and tied back to the source that produced it, so it’s always clear exactly what is running.
• Updates are tested before they arrive. Each release goes through Bretton’s own test environments and automated testing first. It then rolls out gradually through the customer’s own release channel, and any component can be rolled back if something looks wrong.
• The system is easy to monitor and recover. Logs and monitoring data can feed the institution’s own tools. Backups are automated, and audit logs can’t be altered.
• Support access is limited. Bretton’s access is restricted to what’s needed, runs over a private network, and is read-only in production by default.
• Ownership is clear. The customer and Bretton each have a documented set of responsibilities.

Keeping the setup stable matters just as much. At a regulated institution, adding a new dependency or opening a new network path can mean another round of security review. So Bretton deployments are designed to keep a small, fixed footprint, and routine updates work within what’s already been approved rather than adding to it.

The bottom line

As Bretton increasingly works with some of the largest names in financial services, a shared platform is no longer the right setup for them. That’s why we’ve made this investment. Whether an institution needs its own infrastructure, a private cloud deployment, or a tightly restricted environment, the goal is the same: one agent system, running inside whatever boundary the institution requires, with clear ownership at every layer. 

If your team is working through requirements like dedicated infrastructure, BYOC, data sovereignty, or a restricted AI environment, we’d be happy to talk them through.