Como proteger ações sensíveis sem bloquear agentes legítimos

Por que não simplesmente bloquear agentes em ações sensíveis?

Algumas ações na sua aplicação importam mais do que outras. Alterar uma senha, adicionar um membro à equipe, exportar dados, excluir um projeto, aprovar um pedido: se qualquer uma dessas ações ocorrer sem a autoridade correta, o dano é real.

Ao mesmo tempo, cada vez mais do trabalho legítimo no seu app é feito por automação. Um usuário pede a um assistente para atualizar suas configurações. Uma integração de parceiro cria registros em uma agenda. Um agente interno abre tickets de suporte. Bloquear todo cliente automatizado de rotas sensíveis quebra esse trabalho e empurra as pessoas de volta para o esforço manual ou para atalhos que são mais difíceis de proteger.

A resposta não é "bloquear agentes" nem "confiar em agentes". É um modelo em que o risco da ação, a autoridade por trás da solicitação e a evidência sobre o actor cada um tem um papel distinto. Este guia constrói esse modelo. Para a linha de raciocínio mais ampla por trás dele, veja como projetar políticas no nível do app para pessoas e agentes de AI.

Etapa 1: Classifique suas rotas por risco

Comece classificando ações, não clientes. Um esquema simples de três níveis funciona para a maioria das aplicações:

Escreva o nível na configuração da rota para que ele fique visível na revisão de código:

type Tier = "low" | "medium" | "high";

export const routeTier: Record<string, Tier> = {
  "GET /projects": "low",
  "POST /projects": "medium",
  "POST /projects/:id/members": "medium",
  "POST /account/password": "high",
  "POST /exports": "high",
  "DELETE /projects/:id": "high",
};

Os níveis mudam lentamente e são fáceis de raciocinar. Todo o resto neste guia depende deles.

Etapa 2: Como identidade, credenciais e autorização diferem?

Três perguntas costumam ser confundidas:

1. Quem ou o que está agindo? Isso é evidência de actor: uma pessoa interagindo, uma pessoa com assistência de AI, um agente ou Unknown, com uma base como verified ou declared.
2. Qual credencial foi apresentada? Um cookie de sessão, uma chave de API, um token de acesso OAuth.
3. Essa credencial pode realizar essa ação neste recurso? Isso é autorização.

Uma assinatura verified de agente (RFC 9421) responde bem à primeira pergunta. Ela não diz nada sobre a terceira, um ponto abordado em detalhe em o que requisições assinadas de agentes de AI provam, e o que não provam. Um token OAuth com o escopo correto responde à terceira pergunta. Ele diz pouco sobre a primeira. Sua decisão para uma ação de nível alto precisa sempre de uma boa resposta à terceira pergunta e usa a primeira para escolher quanto reforço extra solicitar.

interface Context {
  actor: { actor: "human" | "human_ai" | "agent" | "unknown"; basis: "verified" | "declared" | "inferred" | "unknown" };
  credential: { type: "session" | "oauth" | "api_key"; scopes: string[]; subject: string };
}

function authorized(ctx: Context, action: string, resourceOwner: string): boolean {
  return ctx.credential.subject === resourceOwner && ctx.credential.scopes.includes(action);
}

A autorização nunca é relaxada por causa de um resultado favorável do actor. O contexto de actor apenas adiciona requisitos ou escolhe entre caminhos igualmente seguros.

Etapa 3: Use autoridade delegada para agentes que agem em nome de pessoas

Quando um agente age em nome de um usuário, dê a ele sua própria credencial com autoridade limitada, em vez de deixá-lo reutilizar a sessão do usuário. OAuth 2.0 é a ferramenta padrão: o usuário aprova escopos específicos para um cliente específico, e o token registra esse cliente. RFC 9700, a OAuth 2.0 Security Best Current Practice, descreve como implantá-lo com segurança. Os servidores MCP seguem o mesmo padrão: a especificação de autorização do MCP trata um servidor MCP protegido como um resource server OAuth 2.1. Nosso post quem está chamando seu MCP server? aplica isso às chamadas de ferramentas.

Isso produz exatamente o que você precisa para ações sensíveis:

• O token mostra qual cliente está agindo e em nome de quem.
• Os escopos limitam o que ele pode fazer. Um agente de agendamento com calendar:write não pode alterar uma senha.
• O usuário pode revogar a concessão sem alterar suas próprias credenciais, e OAuth 2.0 Token Revocation (RFC 7009) define como um cliente informa ao authorization server que um token não deve mais ser válido.
• Os logs de auditoria mostram que o agente, e não o usuário, executou a ação.

Se o seu app ainda não oferece suporte a credenciais delegadas, priorize isso para as ações de que os agentes mais frequentemente precisam. É o controle individual mais eficaz para acesso automatizado.

Etapa 4: Quando você deve solicitar uma verificação de step-up?

Step-up significa pedir garantia adicional no momento de uma ação sensível. Para APIs protegidas por OAuth, RFC 9470 define como um resource server informa a um cliente que a autenticação do token atual não é forte ou recente o suficiente. O step-up certo depende de quem está agindo:

• Pessoa interagindo (Human, Human + AI): reautenticação (veja os requisitos de reautenticação em NIST SP 800-63B), um prompt de passkey baseado em WebAuthn ou um código de uso único.
• Agente com credencial delegada: um escopo dedicado à ação de nível alto, concedido explicitamente pelo usuário, ou uma confirmação enviada ao usuário por um canal externo.
• Unknown: a verificação forte existente da rota, inalterada.

type Requirement = "none" | "reauth" | "explicit_scope" | "user_confirmation" | "review";

function stepUp(tier: Tier, ctx: Context): Requirement {
  if (tier !== "high") return "none";
  const { actor } = ctx.actor;
  if (actor === "human" || actor === "human_ai") return "reauth";
  if (actor === "agent" && ctx.credential.type === "oauth") return "explicit_scope";
  if (actor === "agent") return "user_confirmation";
  return "reauth";
}

Observe que um resultado Human não ignora o step-up. Ele seleciona o step-up adequado para uma pessoa interagindo. Inferências podem estar erradas, então elas devem mudar a forma da verificação, não removê-la.

Etapa 5: Encaminhe para revisão humana quando o julgamento for necessário

Algumas ações são raras, de alto impacto e difíceis de automatizar com segurança: exportações em massa de dados de clientes, recuperação de conta após perda de credenciais ou exclusão de uma organização. Para essas situações, uma fila de revisão costuma ser melhor do que qualquer regra automatizada.

O contexto de actor torna a revisão mais rápida e justa ao fornecer ao revisor a evidência: a classe, a base, a credencial usada, o histórico de solicitações semelhantes. O revisor decide. A classificação informa.

function shouldReview(route: string, ctx: Context): boolean {
  const reviewRoutes = new Set(["POST /exports", "POST /account/recover"]);
  if (!reviewRoutes.has(route)) return false;
  return !(ctx.credential.type === "oauth" && ctx.credential.scopes.includes("export:bulk"));
}

Etapa 6: Escolha o comportamento de falha por nível

A avaliação de actor pode expirar ou não ter evidência. Decida com antecedência o que acontece.

• Nível baixo: fail open. A solicitação prossegue normalmente.
• Nível médio: fail open, com autorização normal em vigor.
• Nível alto: fail closed para a verificação forte existente. Evidência de actor ausente nunca enfraquece a proteção e nunca bloqueia uma solicitação que, de outra forma, passaria nas suas verificações normais.

A propriedade chave é a simetria. Uma falha na avaliação de actor deve deixar a ação exatamente tão segura, e exatamente tão disponível, quanto estava antes de você adicionar o contexto de actor.

Etapa 7: Não tome decisões consequentes sobre pessoas com base em inferências

Uma classificação inferred é evidência sobre uma interação, não um fato sobre uma pessoa. Não negue a alguém uma candidatura de emprego, uma decisão de crédito, um resultado de exame, moradia ou acesso a um serviço essencial porque uma sessão pareceu automatizada ou assistida por AI. Nesses fluxos, use o contexto de actor para escolher um processo, como revisão humana ou um caminho alternativo de verificação, e garanta que a pessoa consiga concluí-lo.

Isso é ao mesmo tempo um princípio de justiça e um princípio prático. Inferências têm falsos positivos, e o custo de um falso positivo nesses fluxos recai sobre alguém que não fez nada de errado.

Etapa 8: Faça o rollout primeiro em observação

Antes de qualquer coisa afetar solicitações reais, execute em modo de observação e preview:

1. Registre nível, classe de actor, base, tipo de credencial e o step-up que sua política exigiria.
2. Revise amostras de solicitações de nível alto por classe. Agentes legítimos estão usando credenciais delegadas ou reutilizando sessões de usuários?
3. Corrija as lacunas encontradas, muitas vezes oferecendo credenciais com escopo, antes de enforce.
4. Enforce em uma pequena fração de uma única rota, meça as taxas de conclusão e então expanda.

Etapa 9: Mantenha um trilho de auditoria que responda "quem e em nome de quem"

Para toda ação de nível alto, registre o suficiente para reconstruir o que aconteceu depois:

• a classe e a base de actor no momento da solicitação,
• o tipo de credencial, o cliente para o qual ela foi emitida e o sujeito que ela representa (OAuth 2.0 Token Exchange, RFC 8693, define uma claim act para registrar exatamente esse tipo de relação de "agindo em nome de"),
• os escopos que autorizaram a ação,
• o requisito de step-up ou revisão aplicado e seu resultado.

audit.write({
  action: "project.export",
  actor: ctx.actor,
  client: ctx.credential.type === "oauth" ? clientIdFromToken(req) : undefined,
  subject: ctx.credential.subject,
  scopes: ctx.credential.scopes,
  requirement,
  outcome: "approved",
  at: new Date().toISOString(),
});

Com esse trilho, uma pergunta como "foi uma pessoa ou um assistente que excluiu este projeto, e quem aprovou isso" tem uma resposta clara. Isso torna a resposta a incidentes mais rápida e dá aos usuários confiança de que a ajuda automatizada no seu app é responsável.

Um exemplo prático

Um app de gerenciamento de projetos vê um assistente atualizando prazos de tarefas para usuários e, ocasionalmente, tentando exportar projetos inteiros.

• Atualizar uma tarefa é nível médio. O assistente usa um token OAuth com tasks:write. Autorizado, sem step-up. Permitido.
• Exportar um projeto é nível alto. O token do assistente não tem export:bulk. O app envia ao usuário uma solicitação de confirmação. O usuário aprova, e o app concede o escopo para esse cliente.
• Um cliente Unknown tenta a mesma exportação com um cookie de sessão reutilizado. O prompt de reautenticação existente se aplica, exatamente como antes.

Ninguém foi bloqueado por ser um agente. Toda ação de alto impacto carregava autoridade explícita.

Onde o Proof of Actor se encaixa

O Proof of Actor fornece o lado de actor desse modelo: quem ou o que está agindo e com base em quê. Sua aplicação mantém autenticação, autorização e a decisão final. Detecte o actor, Understand como cada classe usa suas rotas sensíveis e Route cada solicitação para o nível correto de garantia.

Para projetar isso para sua aplicação com nossa equipe, candidate-se ao acesso antecipado. Para cenários de SaaS com mais detalhes, veja Apps e Sites SaaS.

Fontes

• RFC 6749: The OAuth 2.0 Authorization Framework: credenciais delegadas e com escopo para clientes
• RFC 9700: Best Current Practice for OAuth 2.0 Security: orientação de segurança atual para implantações OAuth
• RFC 7009: OAuth 2.0 Token Revocation: revogar uma concessão sem alterar as credenciais do usuário
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol: sinalização de que é necessária uma autenticação mais forte ou mais recente
• RFC 8693: OAuth 2.0 Token Exchange: a claim act (actor) para delegação
• MCP specification 2026-07-28: Authorization: servidores MCP como resource servers OAuth 2.1
• NIST SP 800-63B: Authentication and Authenticator Management: orientação de reautenticação
• W3C Web Authentication (WebAuthn) Level 3: o padrão por trás dos prompts de passkey
• RFC 9421: HTTP Message Signatures: o que uma assinatura verified de agente estabelece