Pitch: DoesItDefend — três casos para revisar permissões de um agente · alexandremaiorano

Um assistente pode responder “não posso mostrar esse evento” sem que isso diga, sozinho, se os dados ficaram protegidos. Para quem está conectando uma IA a uma API, vale separar três situações antes de testar uma lista longa de ataques.

Considere uma agenda fictícia. Ana pode ler o próprio evento. Bia não pode ler o evento privado de Ana. Se o serviço estiver fora do ar, não sabemos se a autorização teria funcionado.

Um exemplo que roda sem modelo ou API

O código abaixo representa apenas essas três saídas. Salve como permission-example.cjs e execute com node permission-example.cjs:

const assert = require('node:assert/strict');

function readEvent({ userId, event, available = true }) {
  if (!available) return { status: 'unavailable' };
  if (event.ownerId !== userId) return { status: 'forbidden' };
  return { status: 'ok', event: { title: event.title } };
}

const event = { ownerId: 'ana', title: 'Evento fictício' };
assert.equal(readEvent({ userId: 'ana', event }).status, 'ok');
assert.deepEqual(readEvent({ userId: 'bia', event }), { status: 'forbidden' });
assert.deepEqual(
  readEvent({ userId: 'bia', event, available: false }),
  { status: 'unavailable' }
);
console.log('3 verificações passaram no exemplo local.');

A indisponibilidade é devolvida antes de examinar o dono do evento. Por isso, o terceiro caso não comprova que o acesso de Bia foi negado pela autorização: esse caminho nem foi executado.

As verificações foram executadas localmente. Elas confirmam o comportamento deste exemplo, com estes dados. O código não implementa autenticação, não testa um modelo e não demonstra a proteção de uma aplicação real. Em uma aplicação, a identidade deve vir da sessão autenticada; não de um userId escolhido pelo modelo ou enviado livremente pelo navegador.

O que observar ao integrar o agente

Na aplicação de teste que você controla, registre o pedido, a identidade autenticada, a operação solicitada, a decisão de permissão e o resultado observado. Use dados sintéticos e evite copiar informações privadas para o relatório.

Se houver uma recusa no chat, confira também o que a ferramenta devolveu. Se houver indisponibilidade, registre que o caso ficou inconclusivo e repita quando o serviço estiver funcionando. Depois de corrigir uma permissão, repita tanto o pedido proibido quanto o permitido: bloquear o trabalho legítimo também é um problema.

Esses passos ajudam a distinguir uma proteção que atuou de um teste que não chegou a examiná-la. A seleção de casos e o acesso às evidências continuam limitando a conclusão.

Como isso se conecta ao DoesItDefend

Sou o criador do DoesItDefend. Estou desenvolvendo o produto para equipes que precisam organizar testes autorizados de aplicações com LLM, revisar achados e repetir os casos depois de uma correção. Este exemplo mostra a pergunta que queremos ajudar a investigar; não é um relato de falha em um cliente.

O guia aberto do DoesItDefend detalha o roteiro. A leitura não exige cadastro. Testes em aplicações de terceiros exigem autorização e escopo combinados antes.

Para quem já conectou um agente a ferramentas: como vocês distinguem uma recusa do modelo de um bloqueio confirmado na API?

Texto preparado com assistência de IA; exemplo revisado e executado localmente.