Controle de Acesso RAG do Amazon Quick Transfere Verificações de Permissão para o Momento da Consulta

O Amazon Quick mudou o controle de acesso em RAG ao adicionar uma segunda verificação de permissão antes que o conteúdo corporativo chegue ao modelo. O anúncio de 7 de outubro aborda uma lacuna de segurança persistente: as permissões indexadas podem ficar desatualizadas entre ciclos de sincronização.

O novo design de controle de acesso RAG do Amazon Quick combina filtragem rápida dentro de um índice de busca com verificação em tempo real na fonte de dados original. A AWS descreve suporte a conhecimento corporativo proveniente de sistemas como Microsoft SharePoint, Google Drive e Atlassian Confluence.

Essa distinção é importante porque a geração aumentada por recuperação, ou RAG, produz respostas usando trechos recuperados de fontes de informação conectadas. Se a recuperação admitir um trecho não autorizado, o modelo poderá expor seu conteúdo por meio de um resumo, comparação ou resposta indireta.

A principal disputa, portanto, não é a AWS contra outro fornecedor. É a verificação autoritativa na fonte contra a prática amplamente usada de copiar permissões para um índice de IA e confiar nessa cópia.

A AWS afirma que sua abordagem em duas etapas reduz o intervalo entre uma alteração de permissão e sua aplicação em uma resposta de IA. No entanto, o anúncio não elimina riscos de identidade, configuração, latência, auditoria ou conectores. Ele muda onde as empresas devem estabelecer o limite de segurança da recuperação.

O Controle de Acesso RAG do Amazon Quick Adiciona uma Segunda Barreira

A mudança importante não é outro conector corporativo. É uma decisão de permissão tomada depois que os candidatos à recuperação são encontrados e antes que seu texto chegue ao modelo.

Muitos sistemas RAG ingerem tanto conteúdo quanto listas de controle de acesso, ou ACLs, durante uma varredura programada. Uma ACL registra quais usuários ou grupos podem acessar um recurso específico. O sistema armazena essas permissões como metadados ao lado dos trechos de documentos indexados.

Quando alguém envia uma pergunta, a camada de recuperação pesquisa o índice e filtra os resultados usando esses metadados armazenados. Esse arranjo é eficiente porque tanto a classificação por relevância quanto a filtragem de permissões ocorrem perto do índice vetorial.

A fragilidade está no tempo. Uma ACL indexada representa as permissões observadas durante a última sincronização bem-sucedida. Ela não descreve necessariamente quem pode abrir o documento no momento da consulta.

A AWS apresentou seu design de ACL em tempo real como um controle adicional acima dessa filtragem indexada. A primeira etapa ainda usa dados de ACL armazenados para reduzir o conjunto de candidatos. A segunda etapa pergunta à fonte conectada se o usuário tem acesso no momento.

Apenas os trechos que passam pelas duas etapas se tornam contexto para o modelo de linguagem de grande porte. Contexto é a informação recuperada fornecida ao modelo enquanto ele prepara uma resposta.

Essa ordem é crucial. O sistema não depende do modelo para reconhecer material confidencial ou removê-lo após a geração. Ele tenta excluir trechos não autorizados antes do início da geração.

A AWS ilustra o processo com o Google Drive. O Quick primeiro realiza uma busca semântica, que recupera trechos por significado, em vez de correspondências exatas de palavras-chave. Ele aplica as ACLs armazenadas no índice para produzir um grupo menor de documentos candidatos.

Em seguida, o Quick chama APIs do Google Drive para validar esses candidatos. A AWS afirma que o serviço usa credenciais de conta de serviço fornecidas pelo administrador para criar tokens de acesso específicos do usuário por meio de impersonação.

O Google Drive continua sendo a fonte autoritativa para as permissões de cada candidato. Um documento que falha na verificação em tempo real é removido, mesmo que a ACL indexada ainda indique acesso.

Essa sequência preserva grande parte da vantagem de velocidade de um índice. Verificar cada documento em um grande repositório por meio de uma API remota produziria latência e volume de solicitações substanciais. Verificar apenas um conjunto reduzido de candidatos cria um equilíbrio mais prático entre segurança e desempenho.

O SharePoint segue o mesmo padrão geral, embora seu fluxo de identidade seja diferente. A documentação da AWS descreve uma filtragem antes da recuperação seguida de uma verificação delegada dos direitos atuais do usuário no SharePoint.

Para uma base de conhecimento do SharePoint com ACL habilitada, o Quick solicita que o usuário faça login quando conteúdo protegido se torna relevante. O serviço então usa um token delegado para validar o acesso a cada documento candidato.

De acordo com o fluxo de ACL do SharePoint, esse login geralmente é uma etapa única. O token de atualização associado dura aproximadamente 90 dias.

A documentação também especifica acesso delegado para ler itens do site, arquivos, o perfil básico do usuário e manter acesso autorizado. Esses escopos merecem revisão porque a verificação em tempo real depende de uma delegação de identidade funcional.

Isso é mais do que uma atualização de conector. A AWS está atribuindo responsabilidades diferentes a duas camadas. O índice realiza a seleção rápida de candidatos, enquanto o sistema de origem fornece a resposta final de permissão.

Essa arquitetura transforma os metadados de ACL desatualizados de único tomador de decisão em um filtro inicial. Eles ainda podem afetar quais candidatos são considerados, mas deixam de ter a palavra final nos fluxos em tempo real compatíveis.

Permissões em Cache se Tornaram o Elo Fraco do RAG Corporativo

O RAG corporativo herda todas as regras complexas de permissão de seus sistemas de origem e adiciona sincronização e mapeamento de identidade como novos pontos de falha.

Um repositório corporativo típico raramente tem uma política de acesso simples. O SharePoint pode combinar sites, grupos, herança, exceções e concessões explícitas. O Google Drive pode incluir arquivos pessoais, drives compartilhados, compartilhamento direto, associação a grupos e configurações para toda a organização.

O Confluence adiciona espaços, páginas, associação a grupos e restrições herdadas. Uma empresa pode usar os três sistemas e, ao mesmo tempo, conectar OneDrive, Amazon S3 e aplicações web internas.

O Amazon Quick atualmente documenta integrações para S3, Confluence, Google Drive, OneDrive, SharePoint e conteúdo web autenticado. Suas integrações de acesso a dados usam vários padrões de autenticação, incluindo OAuth e contas de serviço.

Replicar regras de acesso em um índice normalizado exige que um conector interprete corretamente cada fonte. Ele precisa preservar identidades de usuários, grupos aninhados, herança, regras de negação e alterações feitas após a varredura anterior.

Um defeito de mapeamento pode conceder acesso de forma excessivamente ampla. Uma sincronização atrasada pode preservar acesso após a mudança de função de um funcionário. Uma varredura com falha pode manter o conteúdo atualizado enquanto sua representação de permissão permanece antiga.

O problema se torna mais sério quando funcionários tratam um assistente de IA como atalho entre repositórios. Uma interface convencional revela arquivos individualmente, muitas vezes com limites familiares de pastas ou sites. Um assistente RAG combina evidências de diferentes fontes em uma única resposta.

Essa síntese aumenta a utilidade, mas também muda o padrão de exposição. Um usuário não precisa saber que um documento restrito existe. Uma pergunta ampla pode recuperar um trecho e transformá-lo em uma afirmação concisa.

Uma resposta pode combinar uma atualização pública de projeto com um orçamento confidencial, decisão de pessoal ou plano de aquisição. Mesmo uma divulgação parcial pode revelar informações que a interface original teria ocultado.

A filtragem pós-geração oferece uma solução fraca porque o modelo já recebeu o trecho. Barreiras de proteção podem identificar categorias como dados pessoais ou conteúdo inseguro, mas não compreendem automaticamente as permissões de documentos de cada empresa.

O local correto para a autorização de documentos é antes da geração. Esse princípio também importa para citações, perguntas de acompanhamento, resumos, exportações e ações acionadas por agentes.

O anúncio da AWS concentra-se na defasagem entre permissões sincronizadas e o estado atual da fonte. Considere um funcionário removido de um grupo confidencial de estratégia logo após uma varredura programada.

Um sistema de replicar e filtrar pode continuar reconhecendo a antiga associação do funcionário até a próxima sincronização bem-sucedida. Atualizações orientadas por eventos podem reduzir esse intervalo, mas não abrangem todas as alterações de permissão em todas as plataformas.

A AWS observa especificamente que algumas alterações, como atualizações de associação a grupos no Confluence, nem sempre produzem um evento utilizável. Um conector não pode reagir imediatamente a um evento que nunca recebe.

Os sistemas de origem também evoluem. Um novo método de compartilhamento ou tipo de política pode superar a lógica de tradução do conector. O índice pode então representar incorretamente as permissões até que o conector receba uma atualização.

A verificação em tempo real muda a dependência. A camada de IA ainda precisa de lógica de integração funcional, mas a decisão final vem do sistema já responsável pelo recurso.

É por isso que o anúncio pressiona equipes que criam pilhas RAG personalizadas. Agora elas precisam justificar por que um snapshot replicado de permissões é suficiente quando uma grande plataforma de nuvem oferece validação na fonte durante a recuperação.

Isso também pressiona compradores corporativos a fazer perguntas mais precisas. “O produto oferece suporte a ACLs?” já não é suficiente, porque a filtragem de ACLs indexadas e a autorização em tempo real fornecem garantias diferentes.

Uma avaliação útil deve identificar a fonte da verdade, a identidade transmitida durante a recuperação, o momento das verificações, o tratamento de falhas e as evidências disponíveis para auditores.

A lição mais ampla também se aplica a sistemas de conhecimento pessoais e de equipe. Uma base de conhecimento de IA bem projetada precisa de limites que correspondam às informações que ela conecta, e não apenas à interface que as apresenta.

O Mecanismo em Duas Etapas Troca Simplicidade por Decisões Mais Atualizadas

A AWS melhora a atualização das permissões ao aceitar um caminho de recuperação mais complexo, com dependências adicionais de identidade, API e operação.

A primeira etapa existe para escala. O Quick pesquisa o índice vetorial e aplica metadados de ACL sincronizados antes de contatar uma plataforma de origem.

Essa etapa limita as chamadas em tempo real a documentos que são semanticamente relevantes e aparentemente acessíveis. Sem essa redução, cada pergunta poderia disparar solicitações de permissão em um corpus muito maior.

A segunda etapa existe para correção. O Quick verifica os documentos candidatos por meio da API da fonte relevante e descarta qualquer candidato ao qual o usuário não possa acessar no momento.

Esse modelo híbrido se assemelha a um filtro grosseiro seguido de uma decisão autoritativa. O filtro grosseiro controla custo e latência. A decisão final aborda acessos revogados e replicação imperfeita de permissões.

O modelo recebe apenas trechos aprovados pela verificação em tempo real. Esse design reduz a probabilidade de que material não autorizado entre em prompts, respostas geradas, citações ou processamento posterior pelo modelo.

O mecanismo também esclarece o que “tempo real” significa nesse contexto. Não significa que o Quick sincroniza constantemente todas as permissões. Significa que o sistema valida documentos selecionados enquanto processa uma consulta.

Essa abordagem pode refletir uma revogação mais cedo do que uma varredura programada. A AWS afirma que as alterações aparecem nas respostas de IA em instantes, em vez de esperar horas ou dias pela sincronização.

Esse prazo é uma alegação da empresa, não uma garantia de nível de serviço medida de forma independente. O comportamento real dependerá da plataforma conectada, do estado do token, da disponibilidade da API, da configuração do conector e do modo específico da base de conhecimento.

A arquitetura cria várias questões operacionais. Uma API de origem pode limitar solicitações, retornar erros transitórios ou sofrer uma interrupção. Um token delegado pode expirar ou perder o consentimento necessário.

As empresas precisam saber como o Quick lida com cada condição. Um padrão seguro deve falhar de forma fechada, o que significa que permissões incertas excluem o documento em vez de permiti-lo.

Falhar de forma fechada protege a confidencialidade, mas pode reduzir a qualidade das respostas ou não produzir resultado durante uma falha de identidade. Os usuários podem interpretar essa ausência como conhecimento inexistente, e não como uma decisão de segurança.

A observabilidade, portanto, torna-se essencial. Os administradores precisam de registros que mostrem qual fonte foi verificada, qual identidade foi usada, se a verificação foi bem-sucedida e por que um documento foi excluído.

A latência merece atenção equivalente. Uma verificação remota de permissões pode ter baixo custo, mas uma resposta pode depender de vários documentos em múltiplos repositórios.

A verificação paralela pode reduzir o tempo de espera, embora possa aumentar os picos de tráfego direcionados às APIs conectadas. A verificação sequencial controla a concorrência, mas pode fazer um assistente parecer lento.

Armazenar em cache uma decisão ao vivo bem-sucedida pode melhorar o desempenho, mas o cache reintroduz um intervalo de atualização. O artigo público da AWS não fornece detalhes suficientes para avaliar todas as políticas de cache, timeout, repetição ou limite de taxa.

O mapeamento de identidades continua sendo outra fronteira difícil. A identidade que consulta no Amazon Quick precisa corresponder à identidade reconhecida pelo Google Workspace, Microsoft Entra ou outra fonte.

A impersonação de conta de serviço pode preservar decisões específicas por usuário quando configurada corretamente. Ela também introduz credenciais, políticas de delegação, trilhas de auditoria e privilégios administrativos que as equipes de segurança precisam examinar.

A fonte ainda importa mais do que o banco de vetores, mas a integração se torna uma infraestrutura sensível à segurança. Um erro na impersonação ou no tratamento de tokens pode comprometer o valor da verificação ao vivo.

A documentação da AWS para fontes de dados personalizadas do Bedrock ilustra uma limitação importante. Sua documentação de ACLs personalizadas informa que essas fontes usam metadados de ACL fornecidos pelo cliente, e não verificação em tempo real na origem.

A mesma documentação estabelece uma distinção ainda mais clara. A filtragem com reconhecimento de ACL não é uma fronteira de autenticação, porque o Bedrock não consegue verificar o contexto de identidade fornecido pelo aplicativo chamador.

Os aplicativos devem autenticar usuários antes disso e transmitir informações de identidade verificadas. As empresas não devem tratar apenas a filtragem de metadados como autorização completa.

Para fontes personalizadas, o aplicativo fornece entradas de permissão e negação para cada documento. O Bedrock as aplica antes da recuperação, e as entradas de negação prevalecem sobre as de permissão.

No entanto, essas permissões só são tão atuais e precisas quanto o processo de ingestão do cliente. Não há uma API de origem autoritativa que o Bedrock possa consultar quando o próprio conector personalizado define a ACL.

Essa ressalva impede uma interpretação excessivamente ampla do anúncio da AWS. A verificação em tempo real é um recurso específico de conectores, não uma propriedade universal de todas as configurações de base de conhecimento do Bedrock.

A arquitetura ainda é significativa. Ela estabelece uma meta melhor para repositórios compatíveis, ao mesmo tempo em que documenta que implementações personalizadas mantêm mais responsabilidades.

Verificações em Tempo Real Não Transformam o Bedrock na Fronteira de Segurança

A nova camada reduz uma janela de exposição, mas as empresas continuam responsáveis pela autenticação, configuração, governança da fonte, testes e detecção de incidentes.

A AWS apresenta a verificação autoritativa na origem como proteção contra dados de ACL desatualizados ou mapeados incorretamente. Essa alegação é razoável para alterações de permissões avaliadas com sucesso por meio de APIs de origem compatíveis.

Isso não significa que todos os problemas de controle de acesso desaparecem. O sistema só pode aplicar as permissões que a origem retorna para a identidade e o recurso que verifica.

Se a própria fonte concede acesso de forma ampla demais, o Quick respeitará essa concessão ampla. Se um administrador coloca informações confidenciais em uma pasta amplamente compartilhada, a verificação em tempo real não inferirá uma política de negócios mais restritiva.

A mesma questão se aplica a permissões herdadas. A autoridade da fonte melhora a consistência técnica, mas não consegue determinar se uma concessão herdada era apropriada.

As organizações ainda precisam de revisões de acesso, políticas de privilégio mínimo, procedimentos de desligamento e regras de propriedade para repositórios compartilhados. O RAG pode expor mais rapidamente uma governança de fonte fraca porque torna conteúdos dispersos mais fáceis de encontrar.

A autenticação é outro controle independente. A documentação do Bedrock alerta explicitamente que a filtragem com reconhecimento de ACL não autentica usuários finais. O aplicativo chamador deve estabelecer a identidade antes de fornecer o contexto do usuário.

Esse alerta importa porque uma verificação confiável de permissões contra uma identidade não confiável prova pouco. Um aplicativo malicioso ou defeituoso poderia transmitir o identificador de outro usuário, a menos que controles anteriores impeçam isso.

As empresas devem testar o caminho completo, começando no login e terminando na resposta gerada. Os testes devem abranger acesso revogado, mudanças em grupos, permissões herdadas, negações explícitas, expiração de tokens, falha de API e recriação da base de conhecimento.

O SharePoint introduz uma restrição de configuração que merece atenção. A AWS informa que o gerenciamento de ACL deve ser ativado durante a criação da base de conhecimento e não pode ser alterado depois.

Uma equipe que tenha omitido a configuração deverá criar outra base de conhecimento. Essa exigência pode afetar planos de implementação, reindexação, testes de aceitação e gestão de mudanças.

As permissões necessárias da Microsoft também precisam de análise. A configuração gerenciada por administrador pode exigir direitos de leitura de diretórios e grupos, além de acesso a sites selecionados ou mais amplos do SharePoint.

O aplicativo de verificação delegada solicita permissões separadas para leitura de arquivos e conteúdo de sites. As equipes de segurança devem distinguir esses dois aplicativos e entender quais credenciais sustentam a ingestão em comparação com as verificações no momento da consulta.

Conectores personalizados exigem outro programa de testes. Uso incorreto de maiúsculas e minúsculas nos campos de ACL, uma lista ausente ou um e-mail de usuário incompatível podem remover silenciosamente documentos da recuperação.

A AWS informa que essas falhas de recuperação fecham o acesso em vez de reportar um erro de autorização. Esse comportamento protege os dados, mas complica o diagnóstico, pois os usuários podem simplesmente receber menos resultados.

A segurança do conteúdo vai além das permissões. Documentos autorizados podem conter instruções maliciosas destinadas a manipular um modelo, um risco frequentemente chamado de injeção indireta de prompt.

Uma ACL correta não torna um documento seguro. Ela apenas estabelece que o usuário pode acessá-lo. As empresas ainda precisam de controles de conteúdo, proteções para modelos, restrições de ferramentas e monitoramento.

A AWS menciona Bedrock Guardrails, verificações de fundamentação e políticas de segurança configuráveis ao lado da arquitetura de ACL. Esses controles tratam riscos diferentes e não devem ser considerados substitutos da autorização.

A própria Generative AI Lens da empresa já alertou que reconstruir ACLs complexas por meio de metadados gera esforço de engenharia e possíveis lacunas de permissões. Ela recomenda uma seleção cuidadosa entre abordagens gerenciadas ou personalizadas.

Essa orientação sustenta a motivação para verificações no momento da consulta. Ela também reforça a necessidade de examinar detalhes de implementação, em vez de aceitar um rótulo amplo como “RAG com reconhecimento de permissões”.

A validação independente continua limitada. A AWS forneceu a arquitetura, a documentação e o exemplo de cliente, mas nenhum benchmark público compara taxas de vazamento, latência, sobrecarga de API ou comportamento em falhas.

A Mondelēz International fornece o principal sinal de cliente do anúncio. A AWS afirma que a empresa implementou o Amazon Quick para mais de 35.000 funcionários em quatro regiões.

Jamahl Wiggins, especialista sênior em inovação M365 da Mondelēz, afirmou que o controle de acesso em tempo real ajudou a satisfazer revisores de segurança e conformidade. A declaração mostra demanda empresarial, embora não substitua uma avaliação de segurança independente.

Os compradores devem solicitar evidências em seu próprio ambiente. Um piloto representativo precisa de estruturas reais de grupos, mudanças frequentes de permissões, conteúdo sensível e tentativas controladas de recuperar informações com acesso revogado.

As equipes também devem medir falsas negações. Um sistema que nunca vaza porque frequentemente descarta conteúdo autorizado ainda pode falhar como produto de conhecimento.

Métricas úteis de aceitação incluem precisão de autorização, completude da recuperação, latência adicional, falhas na renovação de tokens, taxas de limitação e a porcentagem de perguntas sem resposta causadas pela verificação.

A conclusão mais forte é, portanto, mais restrita do que a mensagem de marketing. O controle de acesso RAG do Amazon Quick fornece às implementações compatíveis uma decisão de autorização mais atual, mantendo intacto e necessário o sistema de segurança ao redor.

Três Sinais Mostrarão se o Design se Sustenta em Escala Empresarial

O próximo teste é verificar se a validação autoritativa na origem continua precisa, observável e responsiva em repositórios e tipos de conectores reais.

O primeiro sinal é a cobertura documentada de conectores. O anúncio da AWS cita SharePoint, Google Drive e Confluence como fontes empresariais centrais, enquanto seus exemplos detalhados se concentram no Google Drive e no SharePoint.

Os compradores devem observar documentação específica de cada fonte que explique quais conectores realizam verificações ao vivo. A documentação também deve distinguir configurações gerenciadas por administrador, por usuário e personalizadas.

Essa distinção importa porque bases de conhecimento com nomes semelhantes podem ter comportamentos de autorização diferentes. Uma configuração do Google Drive pode usar autorização do usuário, enquanto outra depende de uma conta de serviço e impersonação.

Se a AWS publicar semânticas consistentes de verificação em mais conectores, o argumento para um modelo comum de segurança empresarial se fortalecerá. Se a cobertura continuar limitada, as equipes ainda operarão com níveis mistos de garantia.

O segundo sinal são as evidências operacionais. As empresas precisam de distribuições de latência, comportamento de limitação, tratamento de timeout, regras de repetição, semântica de falha fechada e logs que conectem cada resposta às suas verificações de autorização.

A verificação em tempo real é convincente durante uma solicitação normal. Sua credibilidade depende do que acontece quando Microsoft Graph, Google Drive ou outra fonte responde lentamente ou não responde.

Uma implementação madura deve tornar essas falhas visíveis sem expor nomes de documentos sensíveis. Os administradores devem conseguir separar conteúdo ausente, recuperação com falha e autorização negada.

A AWS pode reforçar a confiança ao documentar eventos de auditoria e limites de serviço. Estudos de caso de clientes podem ajudar quando incluírem comportamento medido, e não apenas aprovação de governança.

A implementação da Mondelēz cria um ponto de referência importante porque a AWS informa mais de 35.000 funcionários em quatro regiões. Detalhes futuros sobre adoção, confiabilidade e operações de suporte tornariam o exemplo mais informativo.

Se grandes clientes relatarem desempenho estável sob mudanças frequentes de permissões, a arquitetura ganhará respaldo prático. Se exigirem isenções amplas ou solução frequente de problemas, sua carga operacional ficará mais clara.

O terceiro sinal é como concorrentes e equipes internas de plataforma respondem. A autorização no momento da consulta pode se tornar um requisito padrão de aquisição para RAG empresarial, em vez de um recurso opcional de segurança.

Os fornecedores podem expor validação de fonte semelhante, oferecer recuperação sensível a permissões por meio de busca empresarial nativa ou argumentar que índices sincronizados podem proporcionar garantias equivalentes com menor latência.

As equipes de RAG personalizado enfrentam a mesma escolha. Elas podem adicionar chamadas à fonte, depender de metadados de ACL cuidadosamente sincronizados, isolar domínios de segurança em índices separados ou consultar um sistema de busca existente sensível a permissões.

Cada caminho envolve uma contrapartida. Verificações em tempo real adicionam dependências, ACLs replicadas criam risco de desatualização, índices separados aumentam a complexidade operacional, e a busca empresarial herdada pode restringir o design de recuperação.

A resposta do mercado revelará se a verificação autoritativa na fonte se tornará uma referência ou permanecerá uma arquitetura premium para repositórios altamente sensíveis.

Para compradores empresariais, a ação imediata é simples. Pergunte a cada fornecedor de RAG onde ocorre a decisão final de autorização do documento.

Em seguida, revogue o acesso a um arquivo sensível e consulte seu conteúdo antes da próxima sincronização programada. Repita o teste com perguntas diretas, resumos, citações e prompts de acompanhamento.

Revise os logs quando o acesso falhar. Confirme se o sistema contatou a fonte autoritativa, qual identidade apresentou e se o documento chegou a entrar no contexto do modelo.

O controle de acesso do Amazon Quick RAG eleva o padrão ao aproximar a verificação final da fonte e do momento da consulta. O design merece atenção porque aborda uma janela concreta de exposição.

Seu valor duradouro dependerá da cobertura dos conectores, de um comportamento de falha transparente e de desempenho mensurável sob carga empresarial real. Seu sistema RAG atual consegue responder a essas mesmas perguntas de autorização com evidências, em vez de garantias?