Seu agente de IA pede MUITA permissão? OAuth é sua vulnerabilidade

Seu agente de IA pede MUITA permissão? OAuth é sua vulnerabilidade

Você é founder de SaaS.

Seu produto:

• Agente de IA (WhatsApp, web, mobile)
• Precisa acessar Slack/GitHub do cliente (pra ler contexto, enviar mensagens, criar PRs)
• Você implementa OAuth ("Conecte sua conta Slack")
• Cliente clica, autoriza

Seu problema:

• Cliente vê janela de permissões: "Admin:users, Admin:channels, Read:messages, Write:messages, ..."
• Cliente pensa: "Por que agente precisa de ADMIN? Ele pode deletar todo meu Slack?"
• Cliente: Clica "Negar"
• Seu agente: "Preciso de acesso admin para funcionar"
• Cliente: "Então não funciona. Vou usar competitor que pede menos."
• You: Lost deal
• Your team: "Por que cliente não confia gente?"

A verdade:

Você está pedindo DEMAIS. Seu agente não precisa de admin. Precisa de:

• Read:messages (ler Slack)
• Write:messages (responder)
• Pronto.

Mas você implementou OAuth errado (pediu permissions demais porque "é mais fácil"). Resultado: Customer trust é zero.

A notícia:

Amazon Bedrock lançou AgentCore com OAuth flow seguro (3LO - three-legged OAuth) + session binding. Significa:

• Seu agente pode acessar Slack DO CLIENTE em nome do cliente
• Cliente controla EXATAMENTE quais permissions autoriza
• Agente não pode pedir "admin" (client revoga)
• Tudo é auditável (quem acessou o quê, quando)

Implicação para você: Se você não implementar OAuth corretamente, seu agente fica inseguro E cliente não confia.

---

O problema real: OAuth quebra confiança quando você pede MUITA permissão

"Admin access" = customer thinks you're evil.

=== THE PERMISSION TRAP ===

Your thinking (wrong): ├─ "Agente precisa fazer tudo" ├─ "Então pede todas as permissions" ├─ "Customer diz sim (confia em mim)" ├─ "Agente funciona perfeito" └─ Result: "Why not?" (você não vê o problema)

Customer thinking (right): ├─ "Agente quer admin access?" ├─ "Pode deletar meu Slack inteiro?" ├─ "Pode ler conversas privadas?" ├─ "Pode acessar dados sensíveis?" ├─ "Isso é risco, não confio" └─ Result: "Nope." (customer nega)

=== REAL SCENARIO ===

You ask for: ├─ admin:users (manage all users) ├─ admin:channels (create/delete channels) ├─ chat:write (write messages) ├─ reactions:write (add reactions) ├─ files:read (read all files) └─ users:read (read all user profiles)

Customer sees: "This app wants to control my entire Slack" Customer feels: "This vendor could spy on us or sabotage" Customer acts: "Deny."

What you ACTUALLY need: ├─ chat:write (write messages) ├─ reactions:write (add reactions) ├─ channel:read (see channel names, not content) └─ users:read:email (get user email, not admin)

Customer sees: "This app can only write messages" Customer feels: "Limited scope, seems safe" Customer acts: "Approve."

=== THE TRUST GAP ===

Low permission request: ├─ Customer approval rate: 90%+ ("Seems safe") ├─ Customer comfort: High ("I know what they can do") ├─ Customer churn: Low ("They respect boundaries") ├─ Your agent: Works with limited access (but can work) └─ Outcome: Win (customer trusts you)

High permission request: ├─ Customer approval rate: 30% ("Too risky") ├─ Customer comfort: Low ("Could spy on us") ├─ Customer churn: High ("Don't trust this vendor") ├─ Your agent: Requests admin, doesn't work if denied └─ Outcome: Lose (customer doesn't trust you)

=== THE REAL PROBLEM: YOU'RE USING OAUTH WRONG ===

Wrong way (what you probably do): ├─ Step 1: Customer clicks "Connect Slack" ├─ Step 2: You request "admin" scope ├─ Step 3: Slack shows "This app wants admin access" ├─ Step 4: Customer clicks "Deny" (security concern) ├─ Step 5: Your agent doesn't work ├─ Step 6: Customer: "Your app is broken" ├─ Step 7: You: "Customer needs to approve" ├─ Step 8: Customer: "I don't trust app with admin. Goodbye." └─ Result: Lost customer

Right way (what Bedrock recommends): ├─ Step 1: Customer clicks "Connect Slack" ├─ Step 2: You request MINIMAL scope (chat:write, reactions:write) ├─ Step 3: Slack shows "This app wants to write messages" ├─ Step 4: Customer clicks "Approve" (low risk) ├─ Step 5: You store token securely (session binding = token tied to customer) ├─ Step 6: Your agent accesses Slack with limited permissions ├─ Step 7: Agent needs MORE permissions? (e.g., read files) ├─ Step 8: You ask again ("Agent needs to read files. Approve?") ├─ Step 9: Customer approves incrementally (trusts you piece by piece) ├─ Step 10: Agent fully functional, customer still trusts you └─ Result: Happy customer

---

OAuth 3LO (Three-Legged OAuth) Explained for Agentes de IA

Não é magic. É segurança por design.

=== WHAT IS 3LO (THREE-LEGGED OAUTH)? ===

Normal OAuth (2-legged, insecure): ┌──────────┐ │ You │ ─── "Give me Slack access" ───┐ │ (SaaS) │ ├──> Slack └──────────┘ ←──── "Here's token" ─────────┘

Problem: Token is in YOUR hands. If your server is hacked, hacker gets Slack access.

3LO OAuth (three-legged, secure): ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Customer │ ──────> │ You │ ──────> │ Slack │ │ (clicks │ │ (SaaS) │ │ (OAuth │ │ "Connect")│ │ │ │ provider)│ └──────────┘ └──────────┘ └──────────┘ │ │ └─────────── "Grant this token" ────────┘ (Customer approves)

Benefit: Customer is IN THE LOOP. Token is approved by customer, not stored by you.

=== THE FLOW (BEDROCK AGENTCORE) ===

1. User initiates (customer clicks "Connect Slack"): └─ Your SaaS → Customer → Slack OAuth screen

2. Customer authenticates: └─ Customer enters Slack username/password

3. Slack shows permissions dialog: ├─ "App wants: chat:write, reactions:write" └─ Customer sees LIMITED scope (not admin)

4. Customer approves: └─ Slack generates OAuth token

5. Session binding (critical part): ├─ Token is tied to THIS CUSTOMER (not shared with others) ├─ Your SaaS stores: "Customer X owns token Y" ├─ If hacked: Hacker can't access OTHER customers' tokens └─ Isolation is built-in

6. Agent uses token securely: ├─ Agent: "I need to read messages in #sales" ├─ System checks: "Does this token have 'chat:read'?" ├─ If yes: Agent reads ├─ If no: Agent denied (token doesn't have permission) └─ Slack: Audits this access (Slack sees who read what)

7. Customer can revoke anytime: ├─ Customer goes to Slack → "Connected Apps" ├─ Sees your SaaS listed ├─ Clicks "Revoke" ├─ Token dies immediately ├─ Your agent stops working (can't access Slack) └─ You lose customer if agent stops (incentive to be good)

=== SESSION BINDING (THE SECURITY MAGIC) ===

Without session binding (insecure): ├─ Customer X connects Slack ├─ You store token in database ├─ Your server is hacked ├─ Hacker gets access to ALL customer tokens ├─ Hacker can impersonate all customers └─ Disaster

With session binding (secure, Bedrock way): ├─ Customer X connects Slack ├─ Token is ONLY associated with customer X session ├─ Token can't be used by customer Y (different session) ├─ Your server is hacked ├─ Hacker gets token, but it's bound to customer X only ├─ Hacker can only access customer X's Slack (not others) ├─ Damage is limited (only 1 customer affected, not all) └─ Better

=== LEAST PRIVILEGE (THE TRUST PRINCIPLE) ===

Wrong (overpermissioned): ├─ Agente pede: admin:users, admin:channels, admin:, chat:, ... ├─ Scope: "Everything" ├─ Customer reaction: "NOPE" ├─ Approval rate: <30% └─ Result: Agent doesn't work

Right (minimal): ├─ Agente pede: chat:write (only write messages) ├─ Scope: "Write messages only" ├─ Customer reaction: "OK, seems safe" ├─ Approval rate: >90% ├─ Agent works: Can write messages ├─ Agent needs more? (read channel history) ├─ You ask again: "Agent needs to read messages. Approve?" ├─ Customer approves incrementally └─ Result: Agent fully functional, customer trusts you

=== THE PERMISSION SCOPES YOU ACTUALLY NEED ===

For Slack agent: ├─ chat:write (send messages) ✓ Essential ├─ reactions:write (add reactions) ✓ Nice to have ├─ files:read (read attachments) ? Only if needed ├─ users:read:email (see emails) ? Only if needed ├─ conversations:read (list channels) ? Maybe ├─ conversations:history (read old messages) ? Only if needed ├─ admin:users (manage users) ✗ Don't ask ├─ admin:channels (create/delete channels) ✗ Don't ask ├─ admin:* (everything) ✗ NEVER └─ Recommendation: Start with chat:write + reactions:write. Add more if customer requests.

For GitHub agent: ├─ repo:read (read repos) ✓ Essential (see code) ├─ repo:write (create branches, PRs) ? Only if needed ├─ workflow:read (see CI/CD) ? Maybe ├─ admin:repo_hook (manage webhooks) ✗ Don't ask ├─ delete_repo (delete repos) ✗ Never └─ Recommendation: Start with repo:read. Ask for :write only if customer needs agent to create PRs.

---

Real problem: Você está implementando OAuth errado (checklist)

Se seu agente faz isso, você vai perder clientes.

=== COMMON MISTAKES (you probably do some of these) ===

❌ MISTAKE 1: Ask for admin scope by default ├─ You think: "Easier to implement (don't need to check permissions)" ├─ Customer thinks: "This app could spy on us" ├─ Result: 70% of customers deny ├─ Fix: Start with minimal scope (chat:write). Upgrade as needed.

❌ MISTAKE 2: Don't tell customer WHY you need permission ├─ Slack prompt: "This app wants chat:write, reactions:write, files:read" ├─ Customer: "Why files:read? Is agent reading my files?" ├─ Customer: "I don't know, so... deny." ├─ You: "Why won't customer approve?" ├─ Fix: Explain BEFORE OAuth prompt ("Agent will read attachments to understand context")

❌ MISTAKE 3: Store OAuth token insecurely ├─ Your server: Stores all customer tokens in one place ├─ Hacker breaks in: Gets ALL tokens ├─ You: "Oops, all customers affected" ├─ Fix: Use session binding (token = customer-specific, not shared)

❌ MISTAKE 4: Don't let customer revoke ├─ Customer: "I revoked in Slack, but your agent still works?" ├─ You: "Uh, we have the old token cached" ├─ Customer: "That's terrifying. I'm leaving." ├─ Fix: Check Slack API regularly (token is still valid?). If revoked, tell agent to stop.

❌ MISTAKE 5: Escalate permissions automatically ├─ Customer: Approves chat:write ├─ Agent: Tries to read files (not approved) ├─ Agent: "Asking for more permissions" (without customer knowing) ├─ Customer: Wakes up to find agent has MORE access (scary) ├─ Fix: Ask customer FIRST. "Agent needs to read files. Approve?" Then upgrade.

❌ MISTAKE 6: Don't audit what agent actually accesses ├─ Customer: "What did the agent read/write in my Slack?" ├─ You: "Uh... I don't know. It's accessing it." ├─ Customer: "That's not OK. How do I know you're not spying?" ├─ Fix: Log every access. Show customer: "Agent read 5 messages, wrote 2 messages, today."

=== WHAT YOU SHOULD BE DOING ===

✅ DO 1: Minimal permissions by default ├─ Start with: chat:write (Slack), repo:read (GitHub) ├─ Ask for more: Only when customer specifically needs it ├─ Benefit: >90% approval rate └─ Customer feels: "This app respects boundaries"

✅ DO 2: Explain permissions before asking ├─ Before OAuth prompt: "Agent needs to send messages in Slack" ├─ Show: "Permission: chat:write (write messages only)" ├─ Customer: "OK, that makes sense" (informed decision) └─ Benefit: Customer trusts you

✅ DO 3: Implement session binding ├─ Each customer gets: Token that only works for THEM ├─ If server hacked: Hacker gets 1 customer's token, not all ├─ Benefit: Damage is limited, customer doesn't blame you entirely └─ Tool: Bedrock AgentCore has this built-in

✅ DO 4: Show revoke control prominently ├─ In your app: "Connected apps: Slack (revoke)" ├─ Customer can click "revoke" anytime ├─ Your app: Immediately stops using token ├─ Benefit: Customer feels in control └─ Side effect: Incentivizes you to be trustworthy (if you're sketchy, they'll revoke)

✅ DO 5: Ask before escalating permissions ├─ Customer approves: chat:write ├─ Agent needs: files:read (later) ├─ You: "Agent needs to read attachments. Approve?" ├─ Customer: "Sure" (explicit consent) ├─ Fix: Escalate one-at-a-time (not all at once) └─ Benefit: Customer never surprised by new access

✅ DO 6: Audit everything ├─ Log: Every message agent reads/writes ├─ Show customer: Dashboard of agent activity ├─ Customer can check: "Agent read X, wrote Y, this month" ├─ Benefit: Full transparency (customer knows exactly what happened) └─ Side effect: Catches if YOUR AGENT goes rogue (you can debug)

=== TRUST METRIC ===

Low trust (you doing it wrong): ├─ Permission approval rate: <40% ├─ Customer complaints: "Why does it need admin?" ├─ Churn: "Don't trust this vendor" ├─ NPS: Negative ("Security risk") └─ Revenue: Declining

High trust (you doing it right): ├─ Permission approval rate: >85% ├─ Customer feedback: "Easy to set up, feels safe" ├─ Retention: "We trust this vendor" ├─ NPS: Positive ("Does what it says") └─ Revenue: Growing

---

Implementação prática: Como fazer OAuth seguro (roadmap)

6 semanas para OAuth que clientes confiam.

=== PHASE 1: AUDIT (Week 1) ===

Task: Honest assessment ├─ What permissions does your agent currently ask for? ├─ Are they ALL necessary? (probably not) ├─ Would YOU approve if you saw it? (if no, reduce permissions) ├─ Session binding: Do you store tokens securely? (probably not) └─ Audit logging: Can you show what agent accessed? (probably not)

Outcome: List of changes needed Owner: You + engineering lead

=== PHASE 2: MINIMAL PERMISSIONS (Weeks 2-3) ===

Task: Reduce permission scope ├─ Slack agent: Remove everything except chat:write + reactions:write ├─ GitHub agent: Remove everything except repo:read (no :write) ├─ Test: Does agent still work? (yes, with reduced permissions) ├─ Customer communication: "Improved security, now ask for fewer permissions" └─ Rollout: Deploy to test customer, get feedback

Outcome: OAuth prompt shows minimal permissions Owner: Engineering

=== PHASE 3: SESSION BINDING (Weeks 4-5) ===

Task: Implement session binding ├─ Each OAuth token: Tied to customer ID (not globally stored) ├─ Architecture: Customer X token ≠ Customer Y token ├─ Benefit: If server hacked, only 1 customer affected ├─ Implementation: Bedrock AgentCore has this, use it (don't reinvent) ├─ Testing: Simulate hack (steal token), verify only 1 customer affected └─ Rollout: Deploy to all customers

Outcome: Tokens are isolated per customer Owner: Engineering + DevOps

=== PHASE 4: AUDIT LOGGING (Week 5) ===

Task: Log every API call ├─ Log: Every message agent reads/writes ├─ Log: Every file agent accesses ├─ Log: Every reaction agent adds ├─ Store: Audit trail (when, what, which customer) ├─ Display: Dashboard for customer ("Agent activity this month") └─ Action: If agent access looks weird, alert you

Outcome: Full visibility into what agent does Owner: Engineering

=== PHASE 5: REVOCATION HANDLING (Week 6) ===

Task: Handle customer revoke gracefully ├─ Slack: When customer revokes, detect it (try API call, get 401 error) ├─ Your app: "Oh, token is revoked. Stop using it." ├─ Agent: Gracefully stops working (doesn't crash) ├─ User notification: "Slack connection lost. Reconnect?" ├─ Recovery: Let customer re-authorize └─ Benefit: Automatic (don't require manual intervention)

Outcome: Revocation doesn't break your app Owner: Engineering

=== PHASE 6: CUSTOMER COMMUNICATION (Ongoing) ===

Task: Tell customers you improved security ├─ Email: "We've improved OAuth security, now ask for fewer permissions" ├─ Blog post: "Why we reduced permissions (and why it matters)" ├─ Help docs: "How to authorize Slack safely" ├─ FAQ: "What permissions does agent need? Why?" └─ Benefit: Builds trust (customers see you prioritize security)

Outcome: Customers understand your security posture Owner: Marketing + product

=== TIMELINE & INVESTMENT ===

Total time: 6 weeks (could parallelize) Team: 1 engineer (50%), 1 DevOps (25%), you (25%) Cost: ~R$40K-80K (engineering time) Benefit: Higher approval rate (+50%), better retention, competitive advantage ROI: Payback in 1-2 months (fewer customers lost due to security concerns)

---

Conclusão: OAuth é sua vulnerabilidade. Ou sua vantagem competitiva.

A realidade (2025-2026):

• Agentes de IA precisam de OAuth (acessar Slack, GitHub, etc)
• Customers estão ASSUSTADOS com permissions ("Pode hackear?", "Pode espiar?")
• Você está pedindo DEMAIS (admin scope = lazy implementation)
• Competitors estão pedindo MENOS (minimal permissions = trusted)
• Market é splitting (safe players vs risky players)

Seu cenário (escolha agora):

┌────────────────────────────────────────────┐ │ OPÇÃO A: Keep asking for admin │ ├────────────────────────────────────────────┤ │ Permission approval rate: <40% │ │ Customer concern: "Why does it need admin?"│ │ Churn: "Don't trust this vendor" │ │ Revenue impact: Losing deals │ │ Outcome: Risky SaaS dies slow │ └────────────────────────────────────────────┘

┌────────────────────────────────────────────┐ │ OPÇÃO B: Implement secure OAuth NOW ✓ │ ├────────────────────────────────────────────┤ │ Permission approval rate: >85% │ │ Customer feeling: "Easy, feels safe" │ │ Retention: "We trust this vendor" │ │ Revenue: +50% from trust (new customers) │ │ Outcome: Safe SaaS wins market │ └────────────────────────────────────────────┘

Na OpenClaw:

Ajudamos SaaS implementar OAuth seguro rapidamente:

• Permission audit: Quais permissions seu agente REALMENTE precisa?
• Session binding: Implementamos isolamento de token por customer
• Audit logging: Construímos dashboard de atividade de agente
• Revocation handling: Quando cliente revoga, agente para gracefully
• Customer communication: Você explica "por quê" cada permissão
• Compliance alignment: OAuth alinhado com LGPD/GDPR
• Ongoing support: Monitora permissões, catches overprivilege

Você quer ter OAuth que clientes CONFIAM ao invés de temem?

Auditoria OAuth | Session Binding | Audit Logging →