A case study is a design prompt
AWS's September 21 Benchling case study describes AgentCore Code Interpreter in VPC mode and a defense-in-depth approach for running agent-generated scientific code across tenants. The authors highlight network isolation, including DNS controls. Treat this as an attributed architecture example, not a certification that another application is secure merely because it uses the same service. The business issue applies broadly: one company may serve many customers through shared infrastructure, while each customer's information and actions must remain within the right boundary throughout the workflow.
Source: How Benchling secured multi-tenant AI agents with Amazon Bedrock AgentCore · 2026-09-21
Check where customer identity is established
Identify the point where a request becomes associated with a customer or organization. That association should come from authenticated context, not from text the user can freely edit. Follow it through retrieval, memory, tool calls, background tasks, and output storage. An illustrative support agent might begin with a correct login and later query a document collection without the tenant filter. The starting screen would look secure while the downstream action crosses a boundary. Review the whole path, including jobs that run after the original session ends.
Inspect what each tool can reach
List the tools the agent uses and the data each one can access. Ask whether a search, code runner, file store, or customer-record connector sees only the necessary scope. Review outbound network destinations as well as inbound access. A tool with broad credentials can undermine careful application-level rules if the agent invokes it in an unexpected way. Use narrowly scoped identities and test denied actions. The practical goal is to make a mistaken instruction fail safely, rather than relying on every generated step to select the correct customer context.
Include caches and memory in the review
A boundary review should cover temporary state. Shared caches, reusable examples, conversation memory, and generated artifacts can carry information between requests. Decide what is customer-specific, what is safe to share, and how that distinction is enforced. Test a sequence in which one customer leaves sensitive information and another asks a related question. Use harmless test data with unmistakable markers. Inspect both the final answer and the retrieved evidence. Leakage can occur through a summary or a suggested action even when no original file is directly exposed.
Verify deletion and incident handling
Document how a customer's records and derived artifacts are removed when required by the agreed policy. Include backups, logs, and temporary stores within the relevant retention rules rather than promising instant removal everywhere. Define how the team investigates a suspected boundary failure without exposing more customer information. Keep a concise incident record with the affected scope, containment, and next decision. A trustworthy service needs an operational response to failure as well as preventive controls. The people running it should understand that response before important customer data enters the system.
Demand evidence for the full path
Before accepting a multi-customer AI workflow, run role and tenant separation checks using an isolated environment. Verify both permitted and forbidden cases, including retrieval, tool execution, memory reuse, and artifact access. Keep the test evidence with the release decision and rerun relevant checks when integrations change. AWS's example highlights how architecture can support these goals, but the application still needs its own proof. A login screen establishes who enters. Reliable customer isolation depends on preserving the correct authority across every place the agent can read, write, or remember.