Governança de Dados para Agentes de IA: Como o DataSpoc Mantém Seu Lake Seguro

No momento em que você dá a um agente de IA acesso aos seus dados, alguém da segurança vai perguntar: “O que impede ele de deletar tudo?” Pergunta justa. A maioria das integrações IA-para-dados não tem uma boa resposta. O DataSpoc tem.

Este post cobre o modelo de segurança que permite que agentes de IA consultem seu data lake sem introduzir novos riscos.

O Medo

Times hesitam em conectar agentes de IA a dados por razões válidas:

1. Acesso de escrita: E se o agente executar DROP TABLE ou DELETE FROM?
2. Proliferação de credenciais: Mais um conjunto de senhas de banco para gerenciar e rotacionar.
3. Exfiltração de dados: O agente pode enviar dados para destinos não autorizados?
4. Sem trilha de auditoria: Como você sabe quais dados o agente acessou?
5. Escopo crescente: O agente pode ver tudo, incluindo dados que não deveria.

Esses medos são justificados quando você dá a agentes acesso direto ao banco de dados. O DataSpoc elimina cada um deles.

Camada de Segurança 1: Somente Leitura por Design

O servidor MCP do Lens é somente leitura. Ele não expõe operações de escrita. Ponto.

from dataspoc_lens import LensClient

lens = LensClient()

# This works — read query
df = lens.query("SELECT * FROM curated_sales LIMIT 10")

# This is rejected — write query
try:
    lens.query("DROP TABLE curated_sales")
except Exception as e:
    print(e)
    # "Write operations are not permitted. Lens is read-only."

# These are also rejected
lens.query("INSERT INTO curated_sales VALUES (...)")  # rejected
lens.query("UPDATE curated_sales SET amount = 0")     # rejected
lens.query("DELETE FROM curated_sales")                # rejected
lens.query("CREATE TABLE test (id INT)")               # rejected

Isso é aplicado no nível do motor, não apenas no nível do prompt. Mesmo que um LLM gere uma query de escrita, o Lens não a executará. O parser SQL verifica cada instrução antes da execução.

Quando usando o servidor MCP, a mesma proteção se aplica:

{
  "mcpServers": {
    "dataspoc-lens": {
      "command": "dataspoc-lens",
      "args": ["mcp"]
    }
  }
}

O servidor MCP expõe ferramentas como query, tables, schema e ask. Nenhuma delas aceita operações de escrita. Um agente de IA conectado via MCP fisicamente não pode modificar seus dados.

Camada de Segurança 2: Cloud IAM (Sem Novas Credenciais)

O DataSpoc nunca gerencia credenciais. Ele usa seu Cloud IAM existente:

AWS

# Lens uses your existing AWS credentials
# Option 1: AWS SSO (recommended)
aws sso login --profile data-team

# Option 2: IAM role (for EC2/ECS/Lambda)
# Automatically uses the instance/task role

# Option 3: Environment variables
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

A política IAM controla o que o agente pode ver:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::company-analytics",
        "arn:aws:s3:::company-analytics/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": ["s3:PutObject", "s3:DeleteObject"],
      "Resource": "*"
    }
  ]
}

Observe: a política IAM explicitamente nega acesso de escrita ao S3. Mesmo que o Lens tivesse um bug que permitisse SQL de escrita (não tem), a camada de nuvem bloquearia a escrita.

GCP

# Use application default credentials
gcloud auth application-default login

# Or service account
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/sa-key.json"

# IAM binding — read-only access to the bucket
- members:
    - serviceAccount:dataspoc-reader@project.iam.gserviceaccount.com
  role: roles/storage.objectViewer

Azure

# Use Azure CLI credentials
az login

# Or managed identity (recommended for production)
export AZURE_STORAGE_ACCOUNT="companylake"

{
  "roleDefinitionName": "Storage Blob Data Reader",
  "scope": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Storage/storageAccounts/companylake"
}

O insight principal: o DataSpoc não adiciona nenhuma nova credencial. O agente de IA tem exatamente o mesmo acesso que o humano que o configurou. Se seu Cloud IAM diz “esta identidade só pode ler do bucket de analytics,” isso é tudo que o agente pode fazer.

Camada de Segurança 3: Controle de Acesso por Bucket

Diferentes times veem diferentes dados por terem acesso a diferentes buckets:

s3://company-finance    → Finance team only
s3://company-hr         → HR team only
s3://company-product    → Product team only
s3://company-analytics  → Everyone (aggregated, non-sensitive)

Configure o Lens para apontar para o bucket apropriado:

# Finance team's agent
export DATASPOC_BUCKET="s3://company-finance"
dataspoc-lens mcp  # This agent sees finance data only

# Product team's agent
export DATASPOC_BUCKET="s3://company-product"
dataspoc-lens mcp  # This agent sees product data only

Um agente configurado com s3://company-product literalmente não pode acessar s3://company-finance. Ele nem sabe que esse bucket existe. O isolamento é no nível da infraestrutura de nuvem, não na lógica da aplicação.

Camada de Segurança 4: Trilha de Auditoria

Toda query executada através do Lens é SQL. SQL é texto. Texto é registrável.

from dataspoc_lens import LensClient

lens = LensClient()

# Every call to query() or ask() produces a SQL statement
# that can be logged, reviewed, and audited

# ask() returns both the answer and the SQL it generated
answer = lens.ask("How many customers do we have?")
# Internally executes: SELECT COUNT(*) FROM curated_customers
# This SQL is logged to .dataspoc/logs/

O Lens registra cada query no bucket:

bucket/
  .dataspoc/
    logs/
      lens/
        2026-04-15T14:30:00Z.json
        2026-04-15T14:31:15Z.json

Cada entrada de log contém:

{
  "timestamp": "2026-04-15T14:30:00Z",
  "query": "SELECT COUNT(*) FROM curated_customers",
  "source": "mcp",
  "tables_accessed": ["curated_customers"],
  "rows_returned": 1,
  "duration_ms": 45,
  "status": "success"
}

Você pode revisar exatamente quais dados o agente acessou, quando e quanto. Compare isso com RAG, onde a etapa de recuperação é opaca — você não consegue ver facilmente quais chunks foram enviados ao LLM.

Comparação: Três Abordagens para Acesso a Dados por IA

Abordagem 1: Acesso Direto ao Banco de Dados (Perigoso)

# The agent gets a database connection string
import psycopg2
conn = psycopg2.connect("postgresql://admin:password@prod-db:5432/main")
cursor = conn.cursor()

# Nothing stops the agent from running:
cursor.execute("DROP TABLE customers")  # disaster
cursor.execute("SELECT * FROM hr.salaries")  # data leak
cursor.execute("UPDATE orders SET status = 'shipped'")  # data corruption

Problemas:

• Credenciais no código
• Acesso total de leitura/escrita
• Sem limitação de escopo
• Um erro destrói dados de produção

Abordagem 2: RAG com Vector Store (Não Auditável)

# The agent retrieves chunks from a vector store
results = vector_store.similarity_search("customer salary data", k=20)
# Which 20 chunks were returned? Hard to audit.
# Did they include sensitive HR data? Maybe.
# Can you prove what the LLM saw? Not easily.

Problemas:

• Recuperação opaca (quais chunks foram realmente retornados?)
• Embeddings podem codificar dados sensíveis
• Sem controle de acesso por linha
• Não é possível provar compliance

Abordagem 3: DataSpoc Lens (Governado)

from dataspoc_lens import LensClient

lens = LensClient()  # uses cloud IAM, read-only, scoped to one bucket

# Every action is SQL — auditable, reviewable, explainable
df = lens.query("SELECT region, COUNT(*) FROM curated_sales GROUP BY region")

# Write operations are rejected at engine level
# Access scope is determined by cloud IAM
# Every query is logged with timestamp and tables accessed

Vantagens:

• Sem credenciais para gerenciar
• Somente leitura por design
• Escopo definido por Cloud IAM
• Trilha de auditoria completa
• Toda resposta rastreia a uma query SQL

Checklist de Configuração para Produção

Aqui está um checklist passo a passo para implantar o DataSpoc com agentes de IA em um ambiente governado:

1. Criar uma Identidade IAM Dedicada

# AWS: Create a role for the agent
aws iam create-role --role-name dataspoc-agent-reader \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy --role-name dataspoc-agent-reader \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

2. Restringir a Buckets Específicos

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::company-analytics",
        "arn:aws:s3:::company-analytics/*"
      ]
    }
  ]
}

3. Configurar o Servidor MCP

{
  "mcpServers": {
    "dataspoc-lens": {
      "command": "dataspoc-lens",
      "args": ["mcp"],
      "env": {
        "DATASPOC_BUCKET": "s3://company-analytics",
        "AWS_PROFILE": "dataspoc-agent-reader"
      }
    }
  }
}

4. Habilitar Registro de Queries

# dataspoc config
logging:
  enabled: true
  destination: "s3://company-analytics/.dataspoc/logs/lens/"
  level: "all"  # logs every query

5. Revisar Logs Regularmente

from dataspoc_lens import LensClient

lens = LensClient()

# Query the agent's own audit logs
df = lens.query("""
    SELECT timestamp, query, tables_accessed, rows_returned
    FROM lens_audit_log
    WHERE timestamp >= CURRENT_DATE - INTERVAL '7 days'
    ORDER BY timestamp DESC
""")
print(df)

Conclusão

Dar acesso a dados a agentes de IA não precisa ser assustador. O modelo de segurança do DataSpoc é simples:

1. Motor somente leitura — escritas são impossíveis no nível do parser SQL
2. Cloud IAM — sem novas credenciais, mesmas permissões que humanos
3. Isolamento por bucket — cada time/agente vê apenas seus dados
4. Trilha de auditoria SQL — toda query é registrada e revisável

O resultado: seu time de segurança obtém a governança que precisa, e seu time de dados obtém agentes de IA que realmente funcionam. Sem compromisso necessário.