Seu agent tem credenciais expostas (ou tem?)

Seu agent tem credenciais expostas (ou tem?)

Cenário que está acontecendo AGORA:

OpenCode (popular dev tool) foi hackeado.

O quê foi roubado?

Credentials: API keys, tokens, passwords (de usuários).

Impact: Hackers agora têm acesso a:

• GitHub repositories
• Cloud accounts (AWS, Azure, GCP)
• Databases
• Payment systems
• Customer data

Why?

Because those credentials were stored INSIDE OpenCode.

OpenCode couldn't protect them (system compromised).

All users' credentials are now publicly available.

---

Now ask yourself:

Your agent needs credentials too:

• Stripe API key (process payments)
• Salesforce token (read customer data)
• AWS credentials (access databases)
• Gmail token (send emails)
• Slack webhook (post messages)

Question: Where are YOUR credentials stored?

Option A: In your code ✗ Committed to GitHub (visible in commit history) ✗ Visible in pull requests ✗ One breach = all credentials exposed

Option B: In .env file ✗ Not versioned, but... ✗ Still on developer's laptop (if laptop gets hacked) ✗ Still in backups (if backup gets hacked)

Option C: In environment variables ✓ Better (not in code) ✓ But still vulnerable if: - Server gets hacked - CI/CD pipeline compromised - Logs contain credentials

Option D: In secrets manager ✓ Encrypted ✓ Access controlled ✓ Audit trail (who accessed what) ✓ Rotation automated → This is correct answer

If you chose A, B, or C: Your credentials are at risk.

If you chose D: You're protected (probably).

---

The OpenCode breach (what happened, what you learn)

The incident (timeline)

October 2026 (recently):

Time: Unknown (discovered publicly Oct 16) What happened: Unauthorized access to OpenCode systems Who was affected: All OpenCode users What was stolen: User credentials (API keys, tokens, passwords) How was it discovered: Security researcher posted on Twitter Response time: OpenCode acknowledges (24 hours later) Communication: Minimal (Twitter post, no official statement) Customer notification: Still waiting (at time of writing)

Why this matters for your agent:

OpenCode is tool for developers. Developers store credentials IN OpenCode. OpenCode gets hacked. All developer credentials are stolen.

Now attacker can:

1. Access developer's GitHub repos (steal code)
2. Access developer's cloud accounts (steal data)
3. Access developer's Stripe account (steal money)
4. Use stolen credentials to deploy malicious code
5. Hijack developer's AI agents (turn them rogue)

Real impact (the scary part)

Scenario: You stored Stripe key in OpenCode

You: Stored R$ 50k Stripe account key in OpenCode (for testing) OpenCode got hacked Attacker now has: Stripe key Attacker does: Process R$ 100k in fake refunds (your money) You: Lose R$ 100k Your customers: Chargebacks (lose trust) Your business: Destroyed

Scenario: You stored AWS credentials in OpenCode

You: Stored AWS credentials in OpenCode OpenCode got hacked Attacker now has: AWS credentials Attacker does: Launches 1000 GPU instances (crypto mining) AWS bill: R$ 500k (your responsibility) You: Bankrupt

Scenario: Your agent stores API keys

Your agent needs: Salesforce token (read customer data) You stored token in: .env file (not versioned) Agent server got hacked (different attack) Attacker finds: .env file Attacker extracts: Salesforce token Attacker accesses: 10k customer records (PII) You: Liable under LGPD (multa R$ 2M+) Your customers: Class-action lawsuit Your business: Criminal investigation

---

Where your agent's credentials live (the attack surface)

The problem (credentials are everywhere)

Your agent architecture:

┌─────────────────────────────────────────────────┐ │ Your Agent │ │ │ │ Needs: API key (to call external service) │ │ │ │ Where could it be stored? │ │ │ │ 1. In code → EXPOSED (if repo hacked) │ │ 2. In .env → EXPOSED (if server hacked) │ │ 3. In logs → EXPOSED (if logs hacked) │ │ 4. In memory → EXPOSED (if process hacked) │ │ 5. In config → EXPOSED (if config hacked) │ │ 6. In secrets manager → PROTECTED (if hardened) │ └─────────────────────────────────────────────────┘

The attack surface (places hackers target):

1. Your GitHub repository

   • Hackers scan public repos for credentials
   • Credentials found in:
     • Source code comments (e.g., API_KEY = "sk_live_abc")
     • .env files (sometimes committed accidentally)
     • Commit history (removed code still visible)
   • Tools they use: TruffleHog, GitRob, Gitrob
   • Success rate: 70% of startups have exposed keys

2. Your server (if hacked)

   • Hackers gain server access (via separate exploit)
   • They look for credentials:
     • .env files
     • Environment variables
     • Config files
     • Process memory
     • Running agent code
   • If found: Game over (they control your agent)

3. Your logs

   • Agent logs might contain credentials (if not filtered)
   • Logs stored in:
     • Local files (on server)
     • Datadog, Splunk, CloudWatch (third-party)
     • Slack channels (your team posts debug logs)
   • If hacker accesses logs: Gets credentials

4. Your CI/CD pipeline

   • GitHub Actions, GitLab CI, Jenkins
   • Store credentials as environment variables
   • If pipeline gets hacked: All credentials exposed
   • (See: SolarWinds breach = this vector)

5. Your dependencies

   • Your agent uses libraries (npm, Python, etc)
   • Libraries might have:
     • Dependency on malicious package (like MALFEX)
     • Exfiltrates your credentials
     • Sends to attacker's server
   • You never know (until too late)

6. Third-party tools (like OpenCode)

   • You store credentials IN tool (for convenience)
   • Tool gets hacked
   • Attacker now has ALL user credentials
   • You're compromised (no control)

The scary truth (how exposed are you?)

Quick audit (do this RIGHT NOW):

bash

Search your GitHub for exposed credentials

git log -p | grep -i "api_key|password|secret|token"

If this returns anything: YOU'RE EXPOSED

Credentials in git history = permanent (can't delete)

Anyone with repo access = has credentials

Search public GitHub for your company name

Go to github.com and search: "your-company api_key"

If results appear: YOU'RE EXPOSED

Check your .env file

cat .env | grep -i "key|secret|password"

If file contains credentials + file is backed up: YOU'RE EXPOSED

Ask your team: "Where do we store Stripe/AWS/Salesforce keys?"

If answer is not "Secrets manager": YOU'RE EXPOSED

---

How to NOT be the next breach victim

The right way (secrets manager)

What you need:

Secrets manager = encrypted vault for credentials

Features: ✓ Encryption at rest (credentials not readable) ✓ Encryption in transit (not visible in transit) ✓ Access control (only authorized code can read) ✓ Audit trail (who accessed what, when) ✓ Rotation (automatic key rotation) ✓ Revocation (revoke instantly if compromised)

Options:

• AWS Secrets Manager (Amazon)
• Azure Key Vault (Microsoft)
• Hashicorp Vault (open-source)
• 1Password Business (team-friendly)
• Doppler (developer-friendly)

Implementation (step-by-step)

Step 1: Choose secrets manager

python

Option A: AWS Secrets Manager (if already using AWS)

import boto3

client = boto3.client('secretsmanager') secret = client.get_secret_value(SecretId='stripe-api-key') api_key = secret['SecretString'] # Now secure

Option B: Doppler (simplest for startups)

from doppler import Doppler

doppler = Doppler(token='dop_...') api_key = doppler.get('STRIPE_API_KEY') # Now secure

Option C: HashiCorp Vault (most robust)

from hvac import Client

client = Client(url='https://vault.example.com') secret = client.secrets.kv.read_secret_version(path='stripe') api_key = secret['data']['data']['api_key'] # Now secure

Step 2: Store your credentials

bash

Don't do this anymore:

echo 'STRIPE_KEY=sk_live_abc123xyz' >> .env git add .env git commit -m "Add stripe key" # ✗ WRONG (credentials in git)

Do this instead:

1. Go to Doppler (or AWS/Vault/etc)

2. Create secret: STRIPE_KEY = sk_live_abc123xyz

3. Add to .gitignore:

echo '.env' >> .gitignore

4. In your code:

from doppler import Doppler stripe_key = Doppler.get('STRIPE_KEY') # Fetches securely

Step 3: Protect your agent code

python

Before (INSECURE):

class Agent: def init(self): self.stripe_key = 'sk_live_abc123xyz' # ✗ HARDCODED self.salesforce_token = 'token_xyz' # ✗ HARDCODED

def charge_customer(self, amount):
    # Attacker can read source code, gets keys
    stripe.charge(amount, api_key=self.stripe_key)

After (SECURE):

from doppler import Doppler

class Agent: def init(self): self.stripe_key = Doppler.get('STRIPE_KEY') # ✓ FROM VAULT self.salesforce_token = Doppler.get('SALESFORCE_TOKEN') # ✓ FROM VAULT

def charge_customer(self, amount):
    # Attacker reads source code, gets nothing
    stripe.charge(amount, api_key=self.stripe_key)

Step 4: Rotate credentials automatically

python

Most secrets managers support automatic rotation

AWS Secrets Manager example:

{ "SecretId": "stripe-api-key", "RotationRules": { "AutomaticallyAfterDays": 30 # Rotate every 30 days }, "RotationLambdaARN": "arn:aws:lambda:us-east-1:123456789012:function:SecretsManagerRotation" }

Result:

- Old key invalidated after 30 days

- New key generated automatically

- Your agent uses new key (no downtime)

- If old key leaked: Only valid for 30 days

Step 5: Audit access

python

Secrets managers track who accessed what

Example (AWS CloudTrail):

{ "eventName": "GetSecretValue", "userIdentity": {"principalId": "arn:aws:iam::123456789012:role/agent"}, "sourceIPAddress": "203.0.113.45", "eventTime": "2026-10-16T10:45:32Z", "resources": [{"ARN": "arn:aws:secretsmanager:us-east-1:123456789012:secret:stripe-key"}] }

You can see:

- What secret was accessed

- Who accessed it (agent role)

- When it was accessed

- From where (IP address)

- If access was unauthorized: ALERT

---

The OpenCode lesson (what went wrong)

Why OpenCode was vulnerable

OpenCode's architecture (hypothetical, but likely):

┌─────────────────────────────────────────────┐ │ OpenCode Server │ │ │ │ Database: │ │ - user_id: 1001 │ │ - stripe_key: sk_live_abc123 ← PLAIN TEXT │ │ - github_token: ghp_xyz789 ← PLAIN TEXT │ │ - aws_credentials: ... ← PLAIN TEXT │ │ │ │ If database gets hacked: │ │ - All credentials exposed (not encrypted) │ │ - OpenCode can't protect (stored plain) │ │ - Attacker gets everything │ └─────────────────────────────────────────────┘

Why this happened:

1. Development speed (security = secondary concern)

   • OpenCode wanted to launch fast
   • Encryption = slower (crypto overhead)
   • Decision: Store plaintext (for now)
   • Never got around to fixing

2. Assumption (it won't get hacked)

   • OpenCode thought: "We're trusted"
   • OpenCode thought: "Our security is good"
   • Turns out: Security was not good

3. No encryption (the fatal flaw)

   • Even if database accessed: credentials should be encrypted
   • OpenCode didn't encrypt
   • Attacker got plaintext credentials

The lesson for your agent

Your agent is different, but same principles apply:

Your agent MUST: ✓ NOT store plaintext credentials ✓ Use secrets manager (encrypted) ✓ Implement access control (not everyone can read) ✓ Maintain audit trail (who accessed what) ✓ Rotate credentials (limit exposure window)

If you skip these: You're vulnerable (like OpenCode) If you implement these: You're protected

---

The action plan (protect your agent NOW)

Week 1: Audit

bash

Find exposed credentials

git log -p --all | grep -i "api_key|secret|password|token"

Check environment

env | grep -i "key|secret|token"

Search GitHub

Go to github.com/search?q=org:your-company+api_key

Ask your team

"Where are all our API keys stored?"

If answer is not "Secrets manager": ACTION REQUIRED

Week 2: Plan migration

1. Choose secrets manager:

   • AWS Secrets Manager (if using AWS)
   • Doppler (if using anything)
   • Hashicorp Vault (if self-hosting)
   • 1Password (if team small)

2. Estimate effort:

   • Find all credentials: 4 hours
   • Set up secrets manager: 8 hours
   • Migrate credentials: 12 hours
   • Update agent code: 16 hours
   • Test: 8 hours
   • Total: 48 hours (~1 week)

3. Plan downtime:

   • Can migrate secrets without downtime
   • Agent can use both old + new for transition
   • Risk: Low (reversible)

Week 3: Execute migration

Day 1: Set up secrets manager Day 2: Copy credentials to manager (encrypted) Day 3: Update agent code (fetch from manager) Day 4: Deploy to staging, test Day 5: Deploy to production, monitor Day 6-7: Verify, clean up old credentials

Week 4: Harden

1. Enable rotation (30-day cycles)
2. Set up audit trail (who accessed what)
3. Create alerts (unauthorized access)
4. Document process (for team)
5. Train team (how to use secrets manager)

---

Conclusion: Your credentials are high-value (protect them)

OpenCode breach signals:

1. Credentials are valuable (attackers target them)
2. Tools can get hacked (even trusted ones)
3. Plaintext = vulnerable (always encrypt)
4. Secrets manager = now table-stakes (not optional)
5. Your agent = likely storing credentials (time to audit)

Your competitive advantage:

If you implement secrets management before competitors:

• You're protected (they're not)
• Your agent is trustworthy (theirs are risky)
• Your customers feel safe (giving you credentials)
• You can market this ("enterprise-grade security")

The timeline:

Now (Oct 2026): Implement secrets manager (1-2 weeks) Wait 6 months: Regulators mandate this (SOX, LGPD, etc) Wait 1 year: Breach happens to competitor (they lose customers) Wait 2 years: This is default standard (you're just following the pack)

Better: Do it now (you're ahead, you're protected)

→ OpenClaw: Agent credentials security, Secrets manager, API key protection, Vault encryption, Breach prevention

Seu agent: credenciais expostas ou protegidas? OpenCode foi hackeada. Sua vez é agora. Proteja seus credentials 🔐