> For the complete documentation index, see [llms.txt](https://docs.skail.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skail.dev/aprender/garantias/seguranca.md).

# Segurança

Como o skail autentica e isola, o que ele recebe da sua aplicação e o que você controla. Para o arquiteto e para quem responde ao questionário de segurança.

## Autenticação

Toda chamada ao skail, do runtime e da API HTTP, leva dois valores: a chave (`SKAIL_KEY`, header `skail-key`) e o namespace (`SKAIL_NAMESPACE`, header `Skail-namespace`, formato `tenant/environment`). A chave precisa existir, estar habilitada e pertencer ao environment do namespace; caso contrário a chamada é recusada com 401 ou 403. Revogar uma chave leva até um minuto para valer em todas as chamadas.

A chave é um segredo. Não vai em código versionado, em URL nem em log. No host, use o mecanismo de segredos (variáveis do container, Kubernetes Secret, Key Vault). Cada environment tem a própria chave, então a chave de `dev` não abre `prod`. Ver [Chaves: criar, rotacionar, revogar](/operar/chaves-criar-rotacionar-revogar.md).

## Isolamento

O namespace é a unidade de isolamento. Execuções, eventos e telemetria de um environment não são visíveis de outro; uma chave só autoriza o environment a que pertence. Dentro do environment, cada execução tem um único dono por vez: duas instâncias da sua aplicação não processam a mesma execução ao mesmo tempo.

## O que o skail recebe da sua aplicação

O skail recebe o que a sua aplicação lhe entrega para orquestrar a execução: os argumentos das functions e dos commands, os resultados dos commands, o corpo do trigger e do fire, e a telemetria (spans e os logs emitidos com `ILogger` dentro de functions e commands). É isso que aparece na linha do tempo do Monitor.

O skail não recebe o que os seus commands leem e escrevem nos seus sistemas. O `DbContext` fala com o seu banco, o `HttpClient` fala com a sua API; do command, o skail só conhece os argumentos e o retorno.

A consequência prática é uma regra de desenho: passe para functions e commands o mínimo necessário para orquestrar (ids, valores de decisão), e carregue dados sensíveis dentro do command que precisa deles, sem devolvê-los como resultado. Um command `CarregarCliente(clienteId)` que devolve o cadastro inteiro expõe o cadastro inteiro na linha do tempo; um command `CobrarCartao(clienteId, valor)` que devolve `Aprovado` expõe só isso. Ver [Como passar dados entre função e commands](/construir/escrever-fluxos/como-passar-dados-entre-funcao-e-commands.md).

## O que você controla

Quais dados entram como argumento e resultado. Quem tem a chave de cada environment. A rotação das chaves. O que a sua aplicação loga dentro de functions e commands. Onde a sua aplicação roda e como ela acessa os seus sistemas.

## Próximos passos

[Chaves: criar, rotacionar, revogar](/operar/chaves-criar-rotacionar-revogar.md) para o ciclo de vida das credenciais. [O que o skail faz pela sua execução](/aprender/arquitetura/o-que-o-skail-faz-pela-sua-execucao.md) para o papel de cada lado. [Autenticação e headers](/construir/api-http/autenticacao-e-headers.md) para a referência.