AI Control Plane Sandbox Requirements for Banks: A Pre-Install Specification (as of November 2026)

What changed and why the sandbox is examiner-facing evidence

The supervisory backdrop has moved. The agencies issued revised model risk management guidance that updates SR 11-7, published as OCC Bulletin 2026-13 on April 17, 2026, and as Federal Reserve SR 26-2. It covers model testing, validation and monitoring, governance and controls, and considerations for vendor and other third-party products. It takes a risk-based approach tailored to a bank's model risk profile, size and complexity, and it states that it does not set enforceable standards or prescriptive requirements.

Separately, in September 2026 the FDIC, OCC, FRB and NCUA issued a proposal to replace existing third-party risk management guidance. As of November 2026 it is a proposal, not final guidance. It continues to state that using a third party does not diminish the bank's responsibility, and it says due diligence may evaluate how a vendor's controls align with the bank's own policies and controls.

Three design consequences follow. Write the sandbox specification against the bank's own policies and the guidance currently in force, and track the proposal. Involve model risk reviewers when acceptance criteria are set. Record the results as the bank's own work, not as vendor-supplied assurance. Presented this way, the sandbox is the first piece of evidence a reviewer sees, not a feature demonstration.

Isolation and data-handling requirements

The guidance above does not prescribe sandbox network or data controls, so these are design choices. Make them explicit and defensible. Run the sandbox in an environment the bank controls, separate from production networks, credentials and data stores. Block all outbound connections by default and allow only destinations the bank approves in writing, including any vendor telemetry or update paths. If the vendor needs a path out, that is a finding to record and decide on, not a convenience.

Scope identity narrowly. Use sandbox-only service accounts and test users, give the vendor's runtime the least privilege needed for each tested tool call, and keep production secrets out of the environment entirely. Record which identities and permissions were granted, since the architecture and permissions tested are part of what reviewers will ask about.

Use synthetic or masked data only. Define who generates it, how masking is verified, and how realistic it must be to exercise redaction rules, for example synthetic account numbers and names in the formats the policies target. Treat prompts, responses and evidence records produced in the sandbox as data under the bank's retention rules, and define how they are deleted when the evaluation ends.

Self-managed deployment in the bank's cloud

A self-managed deployment changes where the evidence and the data live. The runtime executes in the bank's own cloud account, so the sandbox can mirror the intended production topology: the same network boundaries, identity model and storage regions. That makes more of the sandbox result transferable, but the bank should still list which findings carry over and which need re-testing after install, such as production identity integration, real traffic volumes, and the egress allow-list at production scale.

As one example, Trussed is deployed self-managed in the customer cloud and enforces policy in the execution path across models, agents, tools and MCP servers, with outcomes of allow, redact, block, rate limit and escalate for human approval. It produces audit-ready evidence with configurable retention and data residency. Trussed does not position itself as a pre-deployment testing or red-teaming product, so a bank would pair a sandbox like this one with its own validation work.

Finally, treat the sandbox result as a baseline. Drift, new failure modes and control weaknesses may not appear before launch, so schedule re-validation after go-live and keep the specification as the starting point for it.