Seu agent executa código (e você não sabe disso)

Seu agent executa código (e você não sabe disso).

Você é founder de SaaS.

Seu agent roda no WhatsApp.

Cliente pode integrar APIs (Salesforce, Zendesk, seu banco).

Agent pode executar código que cliente escreveu.

Exemplo:

python

Customer writes this code

def calculate_commission(sale_amount): # Agent uses this to process customer's sales data commission = sale_amount * 0.1 return commission

Agent executa.

Mas espera...

O que impede agent (ou customer code) de fazer isso?

python

Malicious code customer could write

def steal_other_customer_data(): # Access database db = get_database_connection() # Read other customer's data other_customer_data = db.query("SELECT * FROM customers WHERE id != {my_id}") # Send to attacker send_to_attacker(other_customer_data)

Nada.

Literally nothing stops this.

Customer A's code could read Customer B's data.

You get sued for R$50M (LGPD violation: exposing customer data).

---

Ontem, AWS publicou case study:

Benchling: How to secure multi-tenant agents.

Real production system:

• 600 code execution sessions per day
• 250+ tenants per week
• Zero security incidents
• How? Sandboxing architecture that actually works

---

O problema: Agent executa código (de quem?)

Por que "standard sandbox" não funciona

=== WHAT IS AGENT CODE EXECUTION? ===

Your SaaS agent: ├─ Takes customer input ├─ Generates code (Python, JavaScript, SQL) ├─ Executes code (to call APIs, process data) ├─ Returns results │ └─ But who wrote that code? ├─ Agent LLM wrote it (can hallucinate) ├─ Customer wrote custom code (might be malicious) ├─ Agent called customer's stored functions (unknown content) └─ Result: Unknown code running in your infrastructure

=== THE THREAT MODEL ===

Who wants to exploit this? ├─ Competitor (steal your customer data) ├─ Disgruntled employee (access other customers' sensitive data) ├─ Hacker (find customer data, sell on dark web) ├─ Malicious customer (read other customers' data from same SaaS) │ └─ How bad? ├─ Worst case: LGPD violation (exposed customer data) ├─ Fine: R$2% of annual revenue (max R$50M for large company) ├─ Reputational: Customer churn ("Your SaaS exposed my data!") ├─ Legal: Class action lawsuit (all affected customers sue you) └─ Operational: Downtime, incident response, notifications

=== WHY TRADITIONAL SANDBOX FAILS ===

Traditional sandboxing approach: ├─ Run code in container (Docker) ├─ Restrict file system access ├─ Block outbound HTTP ├─ Limit CPU/memory │ └─ Looks secure, but it's NOT.

Example attack:

Malicious code: Step 1: DNS lookup (dns.attacker.com) Step 2: DNS server is attacker's Step 3: DNS response contains IP + instructions Step 4: Code follows instructions (connect to internal database) Step 5: Data exfiltrated via DNS tunneling

Result: Firewall blocks HTTP (standard sandbox check) But DNS is still allowed (standard sandbox oversight) So attack succeeds anyway

=== THE BENCHLING PROBLEM ===

Benchling's situation (life sciences SaaS): ├─ Customers: Lab researchers, pharma companies ├─ Tenants: 250+ companies using same SaaS ├─ Code execution: Agent runs customer-written analysis code ├─ Threat: Competitor company could write malicious code │ to read another lab's research data │ (worth millions) ├─ Scale: 600 code execution sessions per day │ └─ Requirement: Execute code safely across 250+ isolated tenants with ZERO security incidents (one breach = company is done)

---

A solução: Sandboxing que funciona mesmo (Benchling's approach)

Como isolar code execution com segurança real

=== BENCHLING'S ARCHITECTURE (AWS BEDROCK AGENTCORE) ===

Layer 1: Agent Code Generation ├─ LLM generates code (in secure context) ├─ Code is validated before execution ├─ Only "safe" patterns allowed (no direct DB access) └─ Result: Agent code is pre-filtered

Layer 2: Execution Sandbox ├─ Code runs in isolated container ├─ Network: BLOCKED (no outbound traffic) │ ├─ No HTTP/HTTPS │ ├─ No DNS queries (even to internal IPs!) │ ├─ No TCP/UDP to external services │ └─ Exception: Only whitelisted APIs allowed │ ├─ File system: RESTRICTED │ ├─ No access to other customers' files │ ├─ Only read/write to own tenant directory │ ├─ No access to system files (/etc, /root, etc) │ └─ No symbolic links (can't escape sandbox) │ ├─ Process isolation: STRICT │ ├─ Each code execution gets new container │ ├─ No process communication between tenants │ ├─ No shared memory │ └─ Container destroyed after execution │ ├─ Resource limits: ENFORCED │ ├─ CPU: Max 1 core per execution │ ├─ Memory: Max 512MB per execution │ ├─ Timeout: Max 30 seconds per execution │ └─ Result: DoS attacks can't crash system │ └─ Monitoring: CONTINUOUS ├─ Every execution is logged ├─ Anomalies detected (unusual API calls, data access patterns) ├─ Logs retained for audit └─ Alerts triggered on suspicious behavior

Layer 3: API Sandboxing ├─ If code needs to call API (e.g., Salesforce): │ ├─ API call goes through API gateway (not direct) │ ├─ Gateway checks: Is this API call allowed for this tenant? │ ├─ Gateway logs: Who called what, when, with what data │ ├─ Gateway rate-limits: Can't call API 10M times in 1 second │ └─ Result: No data exfiltration via API calls │ ├─ Database sandboxing: │ ├─ Code can query database (needs data) │ ├─ But query is rewritten to add filter: "WHERE tenant_id = {this_tenant}" │ ├─ Even if code tries: "SELECT * FROM all_customers" │ ├─ Database returns only: Data for this tenant (filter added automatically) │ └─ Result: No access to other tenants' data, even if code tries │ └─ Credential isolation: ├─ Code never sees credentials (passwords, API keys) ├─ Agent requests "call Salesforce API" ├─ Sandbox retrieves credentials (securely stored) ├─ Sandbox makes API call on behalf of code ├─ Code receives only: Result of API call (no credentials exposed) └─ Result: Code can't steal credentials even if it tries

Layer 4: Multi-tenant Isolation ├─ Tenant A's code runs in Container A ├─ Tenant B's code runs in Container B ├─ Containers are completely isolated (different kernel processes) ├─ Even if Tenant A breaks out of sandbox: │ ├─ Tenant A can only access Container A's resources │ ├─ Tenant A cannot access Container B │ └─ Result: Tenant B's data is still safe │ └─ Key insight: Don't rely on single sandbox. Use: Container isolation + Network isolation + File system isolation + Database filters = Defense in depth

=== THE RESULT ===

Benchling's production metrics: ├─ 600 code execution sessions per day ├─ 250+ tenants (different companies) ├─ Zero security incidents (as of publication) ├─ Zero data breaches from code execution ├─ Zero tenant data leaks │ └─ How? Multiple layers of defense. If one layer fails, others catch the attack.

---

Como implementar segurança similar pro seu agent

Sandboxing checklist pra production

=== IMPLEMENTATION ROADMAP ===

Phase 1: Basic Sandboxing (Week 1-2) ├─ Deploy code execution in isolated container (Docker) ├─ Network restrictions: │ ├─ [ ] Block outbound HTTP/HTTPS │ ├─ [ ] Block DNS queries to external domains │ ├─ [ ] Allow only whitelisted APIs (Salesforce, Zendesk, etc) │ └─ [ ] Log all network attempts (even blocked ones) │ ├─ File system restrictions: │ ├─ [ ] No access to system directories (/etc, /root, /sys) │ ├─ [ ] No access to other customers' files │ ├─ [ ] Symbolic links disabled (can't escape sandbox) │ └─ [ ] Temporary files in isolated directory (cleaned after execution) │ ├─ Resource limits: │ ├─ [ ] CPU: Max 1 core │ ├─ [ ] Memory: Max 512MB │ ├─ [ ] Timeout: Max 30 seconds │ └─ [ ] Disk: Max 100MB per execution │ └─ Cost: R$1-2k (Docker + monitoring setup)

Phase 2: API Sandboxing (Week 3-4) ├─ If code calls customer APIs (e.g., Salesforce): │ ├─ [ ] Never pass credentials to code │ ├─ [ ] Intercept API calls (via API gateway) │ ├─ [ ] Verify: Is this API call allowed for this customer? │ ├─ [ ] Log: Who called what API, with what data │ ├─ [ ] Rate-limit: Max N calls per minute │ └─ [ ] Whitelist: Only approved APIs allowed │ ├─ Database access: │ ├─ [ ] Code cannot access database directly │ ├─ [ ] Code requests data via API (not SQL) │ ├─ [ ] API adds tenant filter automatically (WHERE tenant_id = X) │ ├─ [ ] Even if code tries "SELECT *", only customer's data returned │ └─ [ ] Audit all database queries (log who accessed what, when) │ ├─ Credential management: │ ├─ [ ] Credentials stored in secure vault (AWS Secrets Manager, Vault, etc) │ ├─ [ ] Code never sees credentials │ ├─ [ ] Credentials rotated automatically │ ├─ [ ] Access to credentials is logged │ └─ [ ] Revoke credentials if tenant is deleted │ └─ Cost: R$3-5k (API gateway + vault setup)

Phase 3: Multi-tenant Isolation (Week 5-6) ├─ Tenant A's execution is completely isolated from Tenant B │ ├─ [ ] Each tenant has separate container instance │ ├─ [ ] No shared memory between tenants │ ├─ [ ] No process communication between tenants │ ├─ [ ] Even if Tenant A breaks out, can't access Tenant B │ └─ [ ] Container destroyed after execution (no reuse) │ ├─ Data isolation: │ ├─ [ ] Database: Automatic row-level security (tenant_id filter) │ ├─ [ ] File system: Separate directory per tenant │ ├─ [ ] Cache: Separate cache per tenant (no cross-tenant data) │ ├─ [ ] Logs: Separate logs per tenant │ └─ [ ] Audit: Verify isolation (e.g., Tenant A can't query Tenant B's database) │ ├─ Threat modeling: │ ├─ [ ] Can Tenant A escape container? (No) │ ├─ [ ] Can Tenant A access Tenant B's database? (No, row-level security) │ ├─ [ ] Can Tenant A steal Tenant B's API credentials? (No, credentials in vault) │ ├─ [ ] Can Tenant A's code crash Tenant B's execution? (No, separate containers) │ └─ [ ] Can Tenant A read Tenant B's files? (No, separate directories) │ └─ Cost: R$5-10k (orchestration + multi-tenancy architecture)

Phase 4: Monitoring & Compliance (Week 7+) ├─ Continuous monitoring: │ ├─ [ ] Every code execution logged │ ├─ [ ] Anomaly detection (unusual API calls, data access patterns) │ ├─ [ ] Alerting (immediate notification on suspicious behavior) │ ├─ [ ] Incident response (automated + manual follow-up) │ └─ [ ] Audit trail (retain logs for 12+ months) │ ├─ Compliance: │ ├─ [ ] LGPD compliance (customer data protection) │ ├─ [ ] SOC 2 requirements (security controls documented) │ ├─ [ ] Penetration testing (third-party validates sandbox) │ ├─ [ ] Code review (security team reviews agent-generated code) │ └─ [ ] Incident response plan (what to do if breach happens) │ ├─ Documentation: │ ├─ [ ] Threat model (what attacks are we protecting against?) │ ├─ [ ] Security controls (what are we doing to prevent each attack?) │ ├─ [ ] Assumptions (what do we assume won't happen?) │ ├─ [ ] Known limitations (what could still go wrong?) │ └─ [ ] Customer communication (tell customers about sandbox) │ └─ Cost: R$10-20k (monitoring + compliance infrastructure)

=== TOTAL INVESTMENT ===

Phase 1-4: R$20-40k (engineering) + R$1-3k/month (infrastructure) Timeline: 6-8 weeks to production-grade security Benefit: Zero breaches from code execution, LGPD compliance, customer trust

---

Conclusão

Simple verdade:

Se agent executa código = você need sandbox.

Tradicional sandbox (Docker, network blocks) = não suficiente.

Benchling's approach: Multiple layers (container + network + file system + database + API gateways + multi-tenancy).

Result: 600 executions/day, 250+ tenants, zero breaches.

Action: Audit seu agent's code execution architecture agora.

Questões to ask:

1. Does agent execute code? (Python, SQL, JavaScript?)
2. Is code from LLM (untrustworthy) or customer (possibly malicious)?
3. Is code running in sandbox? What kind?
4. Can code access database? Other customers' data?
5. Can code call APIs? Can it steal credentials?
6. Is isolation multi-tenant? Can Tenant A break into Tenant B?
7. Are executions logged? Monitored for anomalies?
8. Do you have incident response plan if breach happens?

If you answer "no" to any: You have security debt. Fix it before customer gets breached and sues you for R$50M.

Timeline: 6-8 weeks to production security.

Cost: R$20-40k + R$1-3k/month.

Payoff: Avoid LGPD fines (R$50M+), customer churn, reputational damage.

ROI: Priceless (you stay in business).

---

Próximos passos

Na OpenClaw, ajudamos SaaS builders implementar agent code execution security:

• Security Audit: Seu agent executa código? Is it sandboxed? (baseline assessment)
• Threat Modeling: Quais são os threats específicos pra você? (risk analysis)
• Sandbox Architecture: Qual design é melhor? (strategy)
• Docker/Container Setup: How to isolate code execution? (infrastructure)
• Network Sandboxing: Block DNS, HTTP, unauthorized APIs (network layer)
• File System Isolation: Separate directories per tenant (storage layer)
• Database Isolation: Row-level security, automatic tenant filtering (data layer)
• API Gateway Setup: Intercept, log, rate-limit API calls (integration layer)
• Multi-tenancy Design: Ensure Tenant A can't access Tenant B (architecture)
• Compliance Framework: LGPD, SOC 2, audit trails (governance)
• Penetration Testing: Third-party validates sandbox (validation)
• Monitoring & Alerting: Detect anomalies in real-time (operations)

Agent Code Execution Security | Sandbox Architecture | Multi-tenant Isolation | LGPD Compliance →