Modelo de Segurança

Preparado para agentes não significa descontrolado. Um sistema MCP-first descreve cada capability de forma legível por máquina, e ao mesmo tempo define quem pode invocá-la, sob quais condições, e quais rastros são gerados. Segurança não é um complemento posterior, mas parte do design de capabilities.

Seis níveis de autorização

Autenticação responde: Quem é você? Autorização responde: O que você pode fazer? Um sistema MCP-first precisa das duas perguntas, e as responde em seis níveis independentes entre si, que juntos determinam o acesso efetivo.

Nível 1: User Role

O papel do usuário autenticado forma o nível mais amplo. Ele determina classes gerais de acesso, não tools individuais.

admin
manager
employee
viewer
external_client

Nível 2: Tenant Scope

Em sistemas multi-tenant, todo acesso deve ser vinculado ao tenant. Nenhum agente pode ler ou escrever entre tenants, mesmo que seu papel de usuário tecnicamente o permitisse.

tenant:abc
project:123
contact:456

Nível 3: Tool Scope

Cada tool é protegida com seus próprios scopes. Um agente recebe exclusivamente os scopes necessários para sua tarefa definida.

contacts:read
contacts:write
projects:read
projects:write
files:read
files:write
emails:draft
emails:send
calendar:create
billing:read
billing:write
admin:users
admin:security

Nível 4: Resource Scope

Além dos Tool Scopes, o acesso pode ser restrito a tipos específicos de resource. Com isso, garante-se que um agente com contacts:read ainda não pode visualizar qualquer resource de contato.

resource.project.visible
resource.contact.visible
resource.employee.visible
resource.file.downloadable
resource.email.readable

Nível 5: Risk Level

Cada tool carrega um nível de risco declarado. Esse nível influencia a Confirmation Policy e a configuração de auditoria.

Nível 6: Confirmation Policy

A Confirmation Policy define qual barreira adicional deve ser superada antes da execução. Ela é configurada por tool e imposta pelo Policy Layer, não pelo próprio agente.

no_confirmation_required
confirmation_required
step_up_auth_required
admin_approval_required
four_eyes_required
not_allowed_for_ai

Visibilidade de tools

Se uma tool existe já é uma informação relevante para a segurança. Um agente que conhece uma tool proibida pode usá-la como superfície de ataque, mesmo que a invocação posterior fosse bloqueada.

Um Assistente de Vendas recebe, por exemplo, a seguinte lista filtrada de tools:

Human-in-the-loop

MCP-first não significa totalmente automatizado. Significa totalmente controlável, mas de forma controlada. Em ações sensíveis ou arriscadas, o sistema interrompe o agente e solicita ativamente o consentimento do usuário.

O agente reconhece, pelos metadados de risco declarados, que uma ação requer aprovação humana, e transfere o controle. Somente após confirmação explícita a tool é executada.

O exemplo a seguir mostra um diálogo de aprovação típico para o envio em massa de e-mails externos, uma das ações críticas de agentes mais comuns:

Step-up Authentication

Para ações particularmente sensíveis, uma sessão ativa não é suficiente. Mesmo um administrador autenticado deve confirmar sua identidade novamente antes de operações críticas serem executadas.

Gatilhos típicos para Step-up Auth:

• Alterar ou conceder permissões de Admin
• Alterar dados de pagamento ou assinatura
• Dados salariais ou exportações de folha de pagamento
• Gerar ou rotacionar chaves de API
• Exportações completas de dados
• Excluir usuários ou tenants

Métodos aceitos de Step-up (dependendo da policy do sistema):

Nova solicitação de senha
TOTP / Aplicativo de autenticação
Passkey
Aprovação de Admin por segunda pessoa
Princípio dos quatro olhos

Consent Ledger

Cada consentimento a uma ação de agente é um evento que deve ser armazenado permanentemente. O Consent Ledger permite rastrear retrospectivamente qual ação foi aprovada por quem, para qual escopo e com qual método de segurança.

Campos armazenados de uma entrada de consentimento:

consentId, ID exclusivo do consentimento
userId, usuário que aprovou
agentId, agente que agiu
clientId, cliente MCP conectado
toolName, tool invocada
inputSummary, resumo estruturado das entradas (sem texto simples)
riskLevel, nível de risco declarado da tool
approvedAt, timestamp da aprovação
expiresAt, validade da aprovação (se limitada no tempo)
approvalMethod, método de aprovação utilizado (ex.: "totp", "passkey", "manual")

Algumas aprovações podem ter validade limitada no tempo, por exemplo, uma aprovação única para um envio específico. Outras valem para uma sessão ou um período configurado. A Policy determina a granularidade.

Audit Trail

Cada ação MCP gera uma entrada de auditoria. Esta entrada é imutável, vinculada ao tenant e auditável por máquina. Ela forma a base para comprovações de conformidade, detecção de anomalias e revisões internas.

{
  "event": "mcp.tool.executed",
  "tool": "emails.send_external",
  "tenantId": "tenant_123",
  "userId": "user_456",
  "agentId": "agent_sales_assistant",
  "clientId": "client_claude_desktop",
  "riskLevel": "critical",
  "confirmationId": "confirm_789",
  "inputHash": "sha256:a3f2c1...",
  "result": "success",
  "createdAt": "2026-06-11T10:00:00Z"
}

O log de auditoria pode ser monitorado por máquina quanto a anomalias: frequências de execução incomuns, ações fora do horário de trabalho habitual ou acessos a scopes que um agente normalmente não usa, tudo isso é detectável, porque cada ação é claramente tipada e auditada.