How Benchling secured multi-tenant AI agents with Amazon Bedrock AgentCore
Amazon Web Services Jeremy Stashewsky
Benchling runs AI-generated scientific code for thousands of tenants inside a locked-down AWS setup. The twist: it uses DNS Firewall, VPC endpoints, and per-job credentials to stop data leaks without role sprawl.
Based on reporting by Amazon Web Services, Jeremy Stashewsky — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Benchling had a problem that sandboxing alone could not solve. Its AI agents generate scientific code for researchers across thousands of life sciences tenants, and that code has to run with very tight boundaries: no cross-tenant access, no unauthorized network paths, no easy way out for data. Traditional controls were not enough, especially when DNS could still slip through the cracks.
So Benchling moved the untrusted work into a separate AWS account and built a defense-in-depth setup around Amazon Bedrock AgentCore Code Interpreter in VPC mode. The production account holds the main Benchling stack, customer data in Amazon S3, IAM roles, and AWS STS. The untrusted code account runs the agent code. That account has no internet gateway and no NAT gateway, and the Code Interpreter sits behind a security group limited to port 443.
The DNS layer is where the design gets especially strict. Amazon Route 53 Resolver DNS Firewall uses three priorities: first, known bad domains are blocked; second, only explicitly allowed endpoints can resolve; third, everything else gets NODATA. In practice, that means Benchling can allow only the S3 endpoints it needs and shut the door on DNS tunneling tricks that try to smuggle data out through subdomains.
Network access to AWS services also goes through VPC endpoints with explicit policies. Benchling uses a Gateway endpoint for in-region S3 and an Interface endpoint for cross-region S3, and both only permit specific buckets. Even if untrusted code had valid credentials, the network itself would still refuse traffic to anything outside the approved set. Prefix list routing, NACLs, and the security group add more layers, but the big idea is simple: nothing leaves unless it was deliberately allowed.
Benchling also avoids one IAM role per tenant, which would have turned into a mess at this scale. Instead, it injects temporary credentials into each session through AWS STS, scoped per job. A continuous validation suite then keeps testing the whole setup, including DNS tunneling attempts, direct connection attempts, and bucket access outside policy. That matters because secure configurations age badly once infrastructure starts changing under them. Benchling is treating exfiltration resistance like a test, not a promise.
My take — AI-written commentary, not fact-checked reporting
This is the right instinct: assume untrusted code will try to wander, then make wandering expensive and boring. The industry loves waving around agent demos while quietly trusting defaults that were never meant for regulated data. Benchling’s setup is a reminder that real AI safety in production often looks less like a model alignment manifesto and more like a lot of sharp little walls.
Read more about this at: Amazon Web Services