APRENDER. PRATICAR. EVOLUIR.1. Separar a pergunta, a fonte e a resposta
Num assistente fictício de APS, a resposta deve ajudar o operador a interpretar um runbook. Contextual grounding compara a resposta com a fonte e a pergunta: um facto pode estar correto no documento e mesmo assim responder ao serviço errado. Passa os três componentes e testa exemplos com contradição, irrelevância e resposta útil. O limiar é uma confiança mínima, não uma percentagem certificada de exatidão; subir o valor pode bloquear mais respostas legítimas. A documentação limita os casos suportados e não promete cobertura universal de conversational QA ou chatbot. No comité, apresenta resultados do conjunto de avaliação e as limitações da aplicação. Evita transformar uma demonstração curta numa garantia sobre todas as conversas futuras.
2. Definir quando o texto pode sair
No streaming síncrono, os chunks são inspecionados antes da entrega; no assíncrono podem chegar ao cliente enquanto a avaliação decorre. Bloquear chunks seguintes não apaga o que foi recebido. Se o requisito proibir entrega antes de inspeção, a escolha de latência tem de respeitar esse limite. O mascaramento de informação sensível não é suportado em modo assíncrono. Além do modo de streaming, verifica a ação do filtro: NONE devolve deteção sem bloquear. Constrói o teste de aceitação a partir do que o cliente efetivamente recebe, não apenas do evento de deteção no backend. Regista também latência e respostas legítimas bloqueadas, para que segurança e experiência sejam avaliadas com a mesma versão de configuração.
3. Delimitar o input e controlar as ferramentas
Nas Invoke APIs, o filtro de prompt attack exige input tags. Usa um sufixo aleatório novo por pedido para reduzir a possibilidade de o utilizador fechar um delimitador previsível e colocar conteúdo fora da zona avaliada. Esta regra específica não deve ser confundida com a integração Converse. A filtragem de conteúdo também tem limites nas estruturas de ferramentas: não valida toolUse.input. Um executor que altera infraestrutura deve validar esquema, recurso, operação e autorização do operador antes de agir. A equipa pode manter o piloto apenas como recomendação enquanto esses controlos são construídos. Nos testes, inclui argumentos sintaticamente válidos mas fora do âmbito autorizado e confirma que o executor os rejeita sem depender da explicação produzida pelo modelo.
4. Demonstrar a combinação de políticas
Verified Access avalia dados de confiança segundo políticas Cedar. Num documento, é necessário um permit aplicável e nenhum forbid aplicável. Quando grupo e endpoint têm documentos, ambos devem permitir. Se não existe documento no endpoint, aplica-se a decisão do grupo. Criar recursos sem qualquer política não abre uma fase de acesso livre. A aceitação de sintaxe também não confirma que os atributos da condição correspondem aos dados do trust provider. Constrói uma matriz com identidade e dispositivo permitidos e negados. O código local desta aula modela apenas a combinação booleana de decisões já calculadas; não interpreta Cedar nem autentica pessoas. Serve para discutir por que um permit amplo no endpoint não remove o requisito do grupo.
5. Seguir o caminho privado até ao serviço
Num interface endpoint, DNS, conectividade e autorização precisam de provas diferentes. Private DNS permite que o hostname regional habitual resolva para interfaces privadas na VPC, com as opções DNS necessárias ativas. Um nome específico do endpoint pode resolver publicamente para endereços privados; isso não cria conectividade a partir da Internet. Se a aplicação recebe timeout, confirma origem, porta, security group da interface, NACL e caminho. Não uses um ping falhado como diagnóstico final: os interface endpoints não respondem a ICMP. Testa a porta esperada e depois uma chamada autenticada, preservando validação TLS. No handover, entrega resultados por subnet relevante e indica que identidade foi usada, para não confundir um sucesso administrativo com as permissões reais da aplicação.
6. Ensaiar falhas e registar limites
Uma aplicação em duas AZs continua dependente de uma única AZ se o endpoint só existe nessa localização. Distribui interfaces e ensaia comportamento do cliente, resolução e recuperação. Para o assistente, ensaia também o caminho em que a ferramenta rejeita a operação, o filtro bloqueia a resposta e a latência ultrapassa o orçamento. Define quem recebe o alerta e o que é apresentado ao operador sem revelar conteúdo sensível. O relatório de aceitação deve separar autorização, alcance de rede, inspeção de texto e autorização da ferramenta. Nenhuma destas provas substitui todas as outras. Resume a versão, os cenários executados, os resultados negativos esperados e o procedimento de recuperação antes de entregar a exploração diária à equipa RUN.
# Original decision-combination model, not a Cedar evaluator.
# No credentials, network calls, or AWS changes.
def allow(group, endpoint=None):
return group and (endpoint is None or endpoint)
assert allow(True, True) is True
assert allow(False, True) is False
assert allow(True, False) is False
assert allow(True) is True
assert allow(False) is False
print('five policy-combination cases passed; no identity was authenticated')
Um texto de resposta aceitável acompanha argumentos que tentam alterar um recurso fora do âmbito do operador.
Armadilhas comuns
Deteção como bloqueio; streaming como revogação; sintaxe como política correta; DNS como conectividade.
Tópicos relacionados: Evidência e aceitação operacional · Segurança e continuidade
Valida cada fronteira com a identidade, o conteúdo e o caminho reais do caso de uso.
Referência: Contextual grounding checks · SCS-C03