Notícias
Notícias
5 min de leitura
8 de outubro de 2026

RAG seguro: agente IA acessa Confluence (sem vazar dados)

Seu agente IA acessa Confluence/SharePoint. Problema: Respeita permissões? Como dar acesso seguro? Amazon Quick + Bedrock resolve (fine-grained access).

Equipe OpenClaw

Equipe OpenClaw · Time de Engenharia & Produto

A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…


RAG seguro: agente IA acessa Confluence (sem vazar dados)

Notícia: Amazon (com Bedrock) revelou que RAG com acesso seguro é PROBLEMA SOLUCIONADO agora. Framework novo: Amazon Quick (fine-grained access control). Agente IA pode ler Confluence/SharePoint/Google Drive e RESPEITAR permissões (não vaza dados sensíveis). Compliance automático (LGPD, GDPR).

Implicação: Seu agente IA pode ser "smart employee" (acessa base de conhecimento) sem ser "data thief" (vaza tudo).

"Você quer agente IA que responde perguntas usando Confluence (base de conhecimento da empresa). Problema: Confluence tem dados sensíveis (financeiro, vendas, RH). Se agente lê tudo: Vaza tudo (LGPD violation = multa R$ 5M+). Se agente lê nada: Inútil (não tem contexto). Solução antes: Impossível (ou muito cara). Solução agora (Amazon Quick): Agente respeita permissões (lê só o que usuário pode ver). Seguro + útil = problema resolvido."

What this means: Enterprise RAG just became viable (security solved).

Why it matters: LGPD/GDPR compliance is non-negotiable (multi-million penalty). RAG with proper access = compliance automatic.

Problem it reveals: RAG without access control = liability (you're building data breach into your product).

Seu agente acessa knowledge base?

Provavelmente. Aqui está o porquê é risco.


O problema: RAG sem access control = data breach

The permission problem (por que é impossível)

Típica empresa (Confluence setup):

Confluence Pages:

  • Públicas: Documentação técnica (anyone can read)
  • Internas: Roadmap do produto (team read, externos no)
  • Financeiras: P&L, forecast (CFO + CEO only)
  • RH: Salários, reviews (HR only)
  • Vendas: Deal pricing, discounts (sales team only)

Permissions:

  • Admin: See all 5 categories
  • Engenheiro: See Públicas + Internas
  • Vendedor: See Públicas + Vendas
  • HR: See Públicas + RH
  • Estagiário: See Públicas only

Now: You want RAG agent Question: "What's our Q4 forecast?" User: Estagiário Agent reads: All Confluence (porque agent é "admin") Agent responds: "Q4 forecast is R$ 100M" (from Financeiras page) Problem: Estagiário shouldn't see forecast (but agent just told him) Result: Data breach (security violation) Penalty: LGPD fine = R$ 5M+ (opsional, mas serious)

Why traditional RAG fails:

Approach 1: Agent reads everything (ignore permissions)

  • Fast (no permission checks)
  • Simple (no logic needed)
  • Insecure (data leak guaranteed)
  • Result: You go to jail (data protection officer)

Approach 2: Agent reads only public data (safe but useless)

  • Secure (no sensitive data exposed)
  • Compliant (LGPD-friendly)
  • Useless (agent can't answer real questions)
  • Result: Your agent is worthless (no one uses it)

Approach 3: Manual permission mapping (traditional approach)

  • For each page: Define who can access
  • For each user: Check permissions before RAG
  • For each query: Filter documents
  • Complexity: Insane (exponential)
  • Maintenance: Nightmare (permissions change weekly)
  • Cost: R$ 500K+ (to build/maintain)
  • Result: Too expensive (ROI negative)

Approach 4: Amazon Quick (new approach)

  • Automatic permission extraction (from Confluence)
  • Real-time permission checking (per query)
  • Transparent to user (just works)
  • Cost: Included in Bedrock (free extra feature)
  • Result: Secure + useful + cheap + easy

Real scenario (what goes wrong):

Day 1: You launch RAG agent (Confluence-connected) Day 2: Your best engineer asks: "What's the strategy for hiring in Q4?" Day 3: Agent responds: "Based on internal forecast (R$ 100M Q4 revenue) and hiring budget (R$ 50M), we should hire 50 engineers." Day 4: Engineer tells friend (outside company): "My company is hiring 50 engineers, Q4 revenue is R$ 100M." Day 5: Friend tells investor: "This company is hiring 50 people, revenue forecast R$ 100M." Day 6: Investor news hits market Day 7: Stock price reacts (information was confidential) Day 8: SEC investigation (insider information leak?) Day 9: Compliance officer discovers: RAG agent leaked forecast Day 10: LGPD investigation starts (data protection violation) Day 11: Fine: R$ 5M (0.5% of revenue, typical penalty) Day 12: You realize: RAG access control was critical (you skipped it)

Root cause: Agent read Financeiras page (without checking permissions) Solution: Amazon Quick (would have blocked access) Lessons: Always implement access control (not optional)


A solução: Fine-grained access control (Amazon Quick framework)

How Amazon Quick works (technically)

Architecture (what happens behind scenes):

User asks: "What do we know about the Johnson deal?" User identity: Sales rep (João)

Step 1: Amazon Quick extracts João's permissions

  • From: Microsoft Entra ID (Azure AD)
  • Or: Confluence permissions directly
  • Or: Custom SAML/OAuth provider
  • Result: João can see [Public, Sales pages]

Step 2: Agent queries Confluence

  • Searches for: "Johnson deal"
  • Finds: [Public page, Sales page, Financials page]
  • Filters: Keep only pages João can access
  • Result: [Public page, Sales page] (Financials filtered)

Step 3: Agent does RAG

  • Reads: [Public page, Sales page]
  • Generates response: "Johnson deal worth R$ 5M, close date Jan 2025"
  • (Doesn't mention margin or discount, because those are in Financials)
  • Result: Safe response (respects permissions)

Step 4: User gets response

  • Sees: "Johnson deal worth R$ 5M, close date Jan 2025"
  • Doesn't know: Agent filtered out sensitive data
  • Thinks: "Agent gave me all relevant information"
  • Reality: Agent filtered correctly (invisible security)

Key difference (vs traditional RAG):

Traditional RAG: User question → Query documents (all) → Generate response Problem: No permission check (data leaks)

Amazon Quick RAG: User question → Extract user permissions → Query documents (filtered) → Generate response Benefit: Permission-aware (no data leaks)

Implementation (how to build it)

Step 1: Connect identity provider (extract permissions)

python from amazon_quick import QuickPermissions

Connect to Confluence + Azure AD

quick = QuickPermissions( confluence_url="https://company.atlassian.net", identity_provider="azure_ad", # or "okta", "custom_saml" cache_permissions=True # Cache for performance )

Get permissions for user

user_id = "joao@company.com" permissions = quick.get_user_permissions(user_id)

Returns: ["public", "sales_pages", "internal_docs"]

Step 2: Filter documents before RAG

python from amazon_bedrock import Bedrock

query = "What do we know about Johnson deal?" user_id = "joao@company.com"

Get user permissions

permissions = quick.get_user_permissions(user_id)

Search Confluence (filtered by permissions)

documents = confluence.search( query=query, user_permissions=permissions # Amazon Quick magic )

Returns only docs João can see

Generate response (from filtered docs)

response = bedrock.generate( query=query, documents=documents, model="claude-opus" )

print(response)

"Johnson deal worth R$ 5M, close Jan 2025"

(Margin/discount not included, because João can't see Financials)

Step 3: Verify compliance (audit trail)

python

Log what happened (for audit)

quick.log_query( user_id="joao@company.com", query="What do we know about Johnson deal?", documents_accessed=["public_deals", "sales_johnson"], documents_filtered_out=["financials_johnson"], # João couldn't see this timestamp="2024-10-10T14:30:00Z" )

Result: LGPD-compliant audit trail

If auditor asks: "Did João see confidential data?"

Answer: "No, we filtered [financials_johnson] (João no permission)"

Proof: Audit log shows filtration


Use cases (where RAG access control matters)

Use case 1: Enterprise support agent (Zendesk + Confluence)

Before (no access control):

Customer asks: "How do I set up integration with Salesforce?" Agent reads: ALL Confluence (including internal docs) Agent finds: Internal best practices (you wanted to keep secret) Agent leaks: Your proprietary setup to competitor (who also uses your support) Result: You lose IP (to competitor)

After (Amazon Quick):

Customer asks: "How do I set up integration with Salesforce?" Agent reads: PUBLIC Confluence only (documentation) Agent generates: Helpful answer (from public docs) Agent hides: Internal IP (automatically filtered) Result: You help customer + keep IP safe

Use case 2: Sales agent (accessing deal data)

Before (no access control):

Sales rep asks: "What are we selling to Petrobras?" Agent reads: ALL Confluence + Salesforce Agent finds: All deals (including competitors, confidential pricing) Agent leaks: Competitor discounts to Petrobras rep Result: Competitor undercuts you (has your pricing intel)

After (Amazon Quick):

Sales rep asks: "What are we selling to Petrobras?" Agent reads: ONLY Petrobras deal data + public strategy Agent generates: Helpful answer (from allowed docs) Agent hides: Other customer deals (automatically filtered) Result: You help rep + keep competitor data secret

Use case 3: HR agent (accessing employee data)

Before (no access control):

Manager asks: "What's John's salary?" Agent reads: ALL HR docs (all employees) Agent finds: Everyone's salary (leaked) Agent exposes: Salary inequity (John making 2x less than peer) Result: John sees salary data + quits (or sues for discrimination)

After (Amazon Quick):

Manager asks: "What's John's salary?" Agent reads: ONLY John's file (if manager has permission) Agent generates: Helpful answer (from allowed doc) Agent hides: Other employees' salary (automatically filtered) Result: You help manager + keep salaries private


Implementasi: Como adicionar RAG access control (Amazon Quick)

Step 1: Audit current RAG (is it secure?)

For your agent, ask:

  • Does it read from Confluence/SharePoint/Drive? (Yes = needs access control)
  • Does it check user permissions? (No = it's a liability)
  • Does it log what data it accessed? (No = LGPD violation)
  • Can you prove security to auditor? (No = you're exposed)
  • Do you have insurance for data breach? (Probably not enough)

If not checking permissions: You're a data breach waiting to happen If you've never audited: Start this week If compliance asks: You have no answers

Step 2: Integrate identity provider (extract permissions)

Options:

  • Azure AD (Microsoft ecosystem) ✅ Amazon Quick supports
  • Okta (industry standard) ✅ Amazon Quick supports
  • Confluence native permissions ✅ Amazon Quick supports
  • Custom SAML/OAuth (homegrown) ✅ Amazon Quick supports

Timeline: 1 day (plug into identity provider) Cost: Free (included in Bedrock)

Step 3: Enable permission filtering (in RAG pipeline)

Before: documents = search(query) After: documents = search(query, user_permissions=get_permissions(user))

Code change: 1 line Time: 30 minutes Benefit: Security automatic

Step 4: Add audit logging (prove compliance)

For each query:

  • User ID
  • Query text
  • Documents accessed (with permissions verified)
  • Documents filtered out (why they were hidden)
  • Timestamp

Result: Audit trail Benefit: If LGPD auditor asks "Did you leak data?", answer is "No, log proves it" Storage: S3 (cheap, encrypted)

Step 5: Test permission enforcement (does it actually work?)

Weekly test:

  1. Estagiário account → Query "What's Q4 forecast?" → Agent should NOT answer (no permission)
  2. CFO account → Query "What's Q4 forecast?" → Agent should answer (has permission)
  3. HR account → Query "What's employee salary?" → Agent should only see own salary (if permission)
  4. Verify log shows filtering happened (not just permission denied)

Result: Know that permissions are enforced (not theoretical)


Conclusão: RAG sem access control = lawsuit waiting to happen (RAG com access control = compliant + useful)

For your SaaS:

Amazon Quick is not just a feature announcement. It's a signal that enterprise RAG is now viable (security solved). RAG without proper access control is a liability (you're building data breach into your product). RAG with access control is mandatory (LGPD compliance, trust).

Decision:

Option A: Keep RAG without access control (risky)

  1. Agent reads all knowledge base (no permission checks)
  2. User asks sensitive question
  3. Agent answers (leaks confidential data)
  4. Data breach happens (you didn't intend it, but it happened)
  5. Compliance officer discovers RAG is unsecured
  6. LGPD investigation starts
  7. Fine: R$ 5M (0.5% of revenue)
  8. Customer sues (you leaked their strategic data)
  9. You're liable
  10. You're dead

Timeline: You have 3-6 months (before LGPD audit catches this)

Option B: Implement RAG with access control (smart)

  1. Agent reads knowledge base (but respects permissions)
  2. User asks sensitive question
  3. Agent checks permissions
  4. Agent answers (only information user can access)
  5. No data breach (permissions enforced automatically)
  6. Compliance officer audits RAG
  7. Audit passes (log shows permission enforcement)
  8. Customer trusts you (data is safe)
  9. You're defensible
  10. You're thriving

Timeline: You have this month to implement (before compliance audit)

The hard truth: RAG is powerful but dangerous (you're giving agent access to secrets). Permission-aware RAG is the only safe way (you control what agent sees). Amazon Quick makes it easy (one-line code change). Do it now.

Implement RAG access control this month. You'll thank yourself when compliance audit arrives. 🔒


Enterprise RAG security framework (RAG without access control = liability, RAG with access control = compliance)

Se você quer transform your unsecured RAG into permission-aware, compliance-ready system (Amazon Quick), você precisa de framework que:

  • Connects identity provider (Azure AD, Okta, custom)
  • Extracts user permissions (real-time)
  • Filters documents before RAG (permission-aware search)
  • Generates compliance-friendly responses (respects access)
  • Audits every query (LGPD audit trail)
  • Handles permission changes (permissions updated dynamically)
  • Supports multiple knowledge sources (Confluence, SharePoint, Drive, custom)
  • Provides visibility (admin dashboard: who can see what)
  • Handles special cases (shared documents, delegated access)
  • Tests permission enforcement (weekly validation)
  • Generates audit reports (prove compliance to auditors)
  • Handles multi-tenant scenarios (enterprise with multiple departments)

OpenClaw Enterprise RAG Security Framework:

  • Identity integration guide (connect Azure AD, Okta, custom)
  • Permission extraction logic (real-time sync)
  • RAG pipeline modification (add permission filtering)
  • Audit logging system (LGPD-compliant trail)
  • Compliance checklist (what auditor will ask)
  • Testing playbook (verify permissions work)
  • Admin dashboard (visibility + monitoring)
  • Documentation (LGPD compliance proof)
  • Training materials (how to use securely)
  • Migration guide (upgrade from unsecured to secured RAG)
  • Incident response (if permission breach detected)
  • Architecture patterns (multi-tenant, multi-source RAG)

Use case: "Built RAG agent that reads Confluence (knowledge base). Worked great. Then: LGPD auditor asked 'How do you ensure confidential data isn't leaked?' Answer: 'Uh... we don't.' Auditor: 'That's a violation.' Me: 'Oh crap.' Fixed it with Amazon Quick (permission-aware RAG). Auditor re-checks: 'Good, you're compliant now.' Lesson: RAG access control isn't optional (it's mandatory). Amazon Quick makes it easy (was hard before)."

De RAG unsecured (data breach waiting to happen) pro RAG with access control (LGPD-compliant) → OpenClaw Enterprise RAG Security Framework

Seu agente IA acessa Confluence? Implemente access control agora (antes de auditor perguntar). 🔒


Publicado em 8 de outubro de 2026

Leia também