C->>A: Authenticated OpenAI-compatible or Anthropic request
A->>W: Size, canonicalization, WAF, session, rate-limit
W-->>C: Fail-closed response + durable error evidence when rejected
W->>U: Forward only after admission
U-->>A: Complete response or bounded SSE events
A->>L: Non-stream: hash, sign, append, flush, fsync
L-->>A: Non-stream durable evidence status
A->>Q: Optional bounded response analysis
A-->>C: Non-stream response + portable MMR proof headers
A-->>C: Stream events through bounded queue
A->>L: Stream terminal summary, sign, append, flush, fsync
L-->>A: Terminal commit complete
A-->>C: Protocol terminal marker

O ciclo de vida estrito é:

1. Autenticar o chamador e atribuir um identificador de solicitação.
2. Aplicar limites de tamanho da solicitação e canonicalizar a representação da solicitação.
3. Aplicar controles de WAF, comportamento de sessão, egress e limite de taxa.
4. Rejeitar em caso de falha de um controle obrigatório, em vez de enfraquecer silenciosamente o caminho de segurança.
5. Encaminhar para o provedor upstream configurado.
6. Para chamadas não streaming, capturar a resposta, calcular hashes canônicos, assinar a evidência, anexar ao WAL, liberar e executar `fsync` antes de retorná-la.
7. Para chamadas SSE, retransmitir eventos lógicos sanitizados por meio de uma fila limitada com contabilização de bytes. Calcular hash incrementalmente dos bytes exatos emitidos; na terminação, confirmar um resumo terminal assinado antes de emitir o marcador terminal do protocolo. O cabeçalho inicial de streaming é, portanto, `X-Aegis-Evidence-Status: pending-terminal`, não `durable`.
8. Executar enriquecimento opcional de resposta por meio de um caminho de worker limitado após o registro autoritativo existir.

## Contrato principal

| Controle | Comportamento implementado | Evidência e limite |
|---|---|---|
| Durabilidade da evidência | Para chamadas governadas não streaming, o proxy principal confirma a evidência de solicitação/resposta antes de retornar e emite `X-Aegis-Evidence-Status: durable`. O streaming SSE começa com `pending-terminal`; um resumo terminal assinado é confirmado antes do marcador terminal do protocolo, e a prova é recuperada após a terminação. | `tests/test_p0_release_gates.py`, `tests/test_proxy_streaming.py`, testes de caminho de falha do proxy e testes de integridade do WAL. O sistema de arquivos e o provedor de armazenamento de destino ainda exigem validação de implantação. |
| Erros terminais duráveis | Respostas upstream não-2xx, caminhos de circuito aberto e falhas de rede usam o caminho de evidência de erro durável quando o limite de evidência está disponível. | `tests/test_enterprise_durable_evidence.py` e evidência da versão v3.1.0. Uma falha de armazenamento após a admissão é um incidente operacional com falha fechada, não uma resposta bem-sucedida. |
| Integridade da cadeia | Os nós de auditoria vinculam predecessor, hash da solicitação, hash da resposta, raiz de Merkle, assinatura e metadados de esquema. | `aegis/core/crypto_audit.py` e `verify_integrity()`. A detecção de adulteração não é o mesmo que armazenamento externo imutável. |
| Assinatura forte | Ledgers estritos rejeitam o fallback efêmero Ed25519. HMAC-SHA256, PKCS#11 configurado ou assinatura nativa configurada devem satisfazer a política selecionada; a interface HSM legada agora falha fechada em vez de derivar uma chave de software. | Testes de assinante e portões de inicialização estritos. Testes PKCS#11 simulados são apenas evidência de adaptador, HMAC é simétrico, e nenhuma interoperabilidade HSM, não exportabilidade de chave, validação FIPS ou não repúdio de terceiros é estabelecida. |
| Rotação de chaves | O assinante empresarial suporta um keyring HMAC atômico e versionado com uma chave ativa, chaves de verificação históricas, expiração explícita e metadados `key_id` não secretos. | `aegis_server/crypto/keyring.py`, `tests/test_keyring_rotation.py`. Evidência de implantação com três réplicas permanece necessária para uma alegação de produção. |
| Limite de taxa | A limitação distribuída com suporte Redis falha fechada quando o backend está indisponível; a limitação em memória de desenvolvimento não é um substituto de produção. | Testes do limitador de taxa e configuração de implantação. O comportamento Redis/TLS/HA depende da implantação. |
| Identidade empresarial e vinculação de locatário | O candidato não lançado deriva principais imutáveis de mapeamentos de chaves de API configurados, alegações OIDC estritas ou certificados mTLS explicitamente fixados. Os cabeçalhos de locatário/sessão não selecionam o locatário de evidência ou a chave de cota. | `aegis/auth/`, `aegis/proxy/dependencies.py` e testes de integração de autenticação. IdP, terminador TLS, ciclo de vida de certificados e aceitação Redis permanecem dependentes da implantação; a fonte mTLS atual é o modo de fixação de folha, não validação PKI universal. |
| Arquivamento de segmento finalizado | Segmentos JSONL WAL rotacionados recebem manifestos versionados e podem ser enviados por meio do adaptador opcional S3 Object Lock com verificação de SHA-256, versão, modo de bloqueio e retenção. A aceitação opcional RFC 3161 requer verificação OpenSSL contra um arquivo CA explícito. | `aegis/storage/`, `aegis/anchoring/` e testes focados. Isso não é um WORM regulatório, garantia de admissibilidade legal ou tempo externo sem aceitação do destino. |
| Telemetria segura para privacidade | Eventos de segurança de esquema fechado omitem texto de prompt/resposta/token, embeddings, identificadores brutos de locatário/sessão, nomes de assinantes e strings de exceção; um spool SQLite limitado opcional exporta para codificações SIEM suportadas. | `aegis/telemetry/` e testes de sentinela de privacidade. Entrega downstream, retenção, controle de acesso e SLOs operacionais são externos. |
| Relatório de capacidades | `aegis.crypto` expõe um inventário legível por máquina que distingue estados implementado, runtime opcional, stub e validação externa necessária. | `aegis/crypto/capabilities.py` e testes focados. A API ZK atual é um stub de teste não real, provas MMR portáveis crescem O(log n), e nenhuma validação FIPS é reivindicada. |
| Limite de atestação TEE | Os nós de dispositivo TEE são relatados apenas como descoberta. Relatórios legados de autoria do chamador são rejeitados; um verificador injetado pode fornecer alegações normalizadas autenticadas para avaliação de política de medição exata, assinante, nonce, frescor, debug, TCB e dados de relatório. | `aegis/core/tee_manager.py` e testes de módulo de hardware. O repositório não implementa um carregador de enclave, análise de cotações de fornecedor, validação de certificado/colateral, confidencialidade do host raiz ou aceitação de atestação de destino. |
| Limite de privacidade diferencial | Um primitivo interno de contagem Laplace usa sensibilidade um e um CSPRNG do sistema para uma liberação sob adjacência de registro adicionar/remover-um. | `aegis/core/dp_analytics.py` e testes determinísticos. Nenhum endpoint HTTP DP é publicado; liberações repetidas exigem um contador durável, identidade estável de conjunto de dados/consulta, memoização e limites de contribuição revisados que não são implementados aqui. |
| Limite de capacidade de fuzzing | O fuzzing está disponível somente quando `cargo`, `cargo-fuzz`, um workspace privado, um manifesto analisável limitado e todos os arquivos de alvo regulares confinados exatos existem; o estado de execução distingue limpo, artefato de crash, erro de ferramenta, timeout e indisponível. | `aegis/core/fuzzing_harness.py` e testes focados. A árvore atual não tem workspace cargo-fuzz ou harness Kani, cobertura medida permanece indisponível e testes limitados não são prova exaustiva. |
| Contexto de IA consultivo | `AGENTS.md`, `llms.txt` e `.aegis_ai_context/` fornecem navegação do repositório e limites de alegação para assistentes de codificação. | Esses arquivos são dados consultivos: eles não podem substituir autorização, estabelecer comportamento em runtime ou transformar código-fonte mesclado em uma versão. |
| Limites de solicitação | Corpos superdimensionados são rejeitados antes do processamento normal do aplicativo. | Testes de versão P0/P1. Os limites devem ser dimensionados para o provedor implantado e a política de streaming. |
| WAF | Normalização NFKC, remoção de largura zero, bloqueios de padrões críticos, guarda de profundidade estrutural e análise local ponderada são executados no limite do aplicativo. | `tests/data/waf_corpus_v1.json` e `tools/security/run_waf_corpus.py`. A análise HTTP/2 de ingresso está fora do limite do aplicativo. |
| Egress | Listas de permissões canônicas rejeitam esquemas, userinfo, portas malformadas, formulários não suportados e endpoints não aprovados. | `aegis/proxy/egress_guard.py` e testes. Isso não substitui firewall, namespace, NetworkPolicy ou controles de egress em nuvem. |
| Controles de kernel | A inicialização estrita pode exigir capacidades Seccomp e LSM/AppArmor/SELinux e rejeita aplicação ausente fora do modo sandbox explícito. | `aegis/core/seccomp_guard.py`, `aegis/core/lsm_guard.py`, testes de implantação. O kernel de destino ainda precisa de testes de aceitação. |
| Enriquecimento de resposta | A análise é limitada, observável e serializada por sessão quando necessário. É opcional e não pode enfraquecer o contrato de evidência durável. | Testes de analisador e fila. O comportamento da fila sob saturação real de I/O é descrito no runbook de backpressure. |
| Prova de inclusão portátil | Cada novo registro de ledger armazena uma prova `aegis-mmr-inclusion-v1` autocontida, digest de folha, picos ordenados e raiz. Respostas não streaming retornam estas como cabeçalhos `X-Aegis-MMR-*`; chamadas em streaming expõem um link de prova pós-terminal autenticado. | Vetores dourados entre linguagens e testes de replay/adulteração do WAL. Uma prova válida estabelece inclusão na raiz MMR declarada; ela não estabelece por si só carimbo de tempo externo, retenção ou admissibilidade legal. |

## Início rápido para avaliação local

O caminho local é para desenvolvimento, testes e replay de evidência. Não é um perfil de implantação de produção.```bash
git clone https://github.com/JuanLunaIA/aegis-latent-core.git
cd aegis-latent-core
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --require-hashes -r requirements.lock
python -m pip install --no-deps -e .
python -m compileall -q aegis aegis_server
pytest -q

`development` é o único modo não estrito aceito no modelo de configurações atual; o valor mais antigo `permissive` e o comando `uvicorn aegis.main:app` estão obsoletos. Nunca coloque chaves de provedor, tokens de portador, segredos de assinatura, registros WAL ou cargas de clientes no controle de versão.

## SDKs de código-fonte mesclado

A distribuição Python de código-fonte mesclado em [`sdk/python`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/sdk/python) é uma integração plug-and-play que subclasseia os clientes oficiais da OpenAI e da Anthropic. Os tipos de modelos de solicitação/resposta existentes e as APIs de recursos síncronos/assíncronos são preservados enquanto os cabeçalhos de tenant, sessão e autenticação de portador da Aegis são injetados na construção. O ingresso nativo `/v1/messages` da Anthropic requer `AEGIS_PROVIDER=anthropic`; ele preserva o formato de resposta Anthropic Messages em vez de traduzi-lo para objetos OpenAI.

O pacote TypeScript de código-fonte mesclado compatível com edge em [`sdk/typescript`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/sdk/typescript) verifica provas `aegis-mmr-inclusion-v1` com Web Crypto e fornece wrappers nativos do provedor e opções de construtor em vez de redeclarar cargas de provedores. Os pacotes oficiais da OpenAI e da Anthropic são dependências pares, portanto seus recursos nativos, parâmetros de solicitação, modelos de resposta, iteradores de streaming, novas tentativas e tipos de erro permanecem autoritativos. Ambos os SDKs consomem os mesmos vetores de prova congelados em `sdk/shared/`.

O candidato não lançado do SDK Python também inclui adaptadores de callback LangChain e LlamaIndex com privacidade minimizada. Os fluxos de publicação são desabilitados, a menos que os pré-requisitos externos de editor confiável, ambiente, tag assinada e variáveis de repositório sejam configurados. Consulte [`docs/DEVELOPER_INTEGRATIONS_GUIDE.md`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/docs/DEVELOPER_INTEGRATIONS_GUIDE.md).```python
from aegis_sdk.openai import OpenAI

client = OpenAI(
    aegis_api_key="gateway-token",
    gateway_url="https://aegis.internal",
    tenant_id="tenant-42",
)
response = client.chat.completions.create(
    model="gpt-4.1-mini",
    messages=[{"role": "user", "content": "hello"}],
)

`AEGIS_DASHBOARD_API_KEY` é exclusivo do servidor e nunca é serializado nos bundles do navegador. O endpoint de exportação exige o escopo `audit:export` quando escopos por chave estão configurados. Cada ZIP limitado contém um `manifest.json` JCS RFC 8785, um `ledger_slice.cbor` canônico em DAG-CBOR identificado por CIDv1, `merkle_proof.json`, `audit_certificate.pdf` e `VERIFY.sh`. O certificado é um relatório técnico de integridade, não uma certificação ou conclusão de admissibilidade legal.

## Caminho de implantação estrito

O modo estrito é a postura de produção pretendida. Ele exige autenticação, evidência durável, assinatura forte, corpos de requisição limitados, um backend distribuído de limitação de taxa, armazenamento durável e os controles de kernel configurados. Use um gerenciador de segredos e monte o WAL em um caminho durável e legível apenas pelo proprietário.```bash
export AEGIS_SECURITY_ENFORCEMENT_MODE=strict
export AEGIS_API_KEYS='replace-with-a-secret-manager-reference'
export AEGIS_SIGNING_KEY='at-least-32-bytes-of-secret-material'
export AEGIS_RATE_LIMIT_BACKEND=redis
export AEGIS_REDIS_URL='rediss://redis.internal:6380/0'
export AEGIS_REQUIRE_DISTRIBUTED_LIMITER=true
export AEGIS_REQUIRE_DURABLE_EVIDENCE=true
export AEGIS_REQUIRE_LSM=true
export AEGIS_REQUIRE_SECCOMP=true
export AEGIS_MAX_REQUEST_BODY_BYTES=1048576
export AEGIS_BACKEND_URL='https://llm.internal.example/v1'
export AEGIS_WAL_PATH='/var/lib/aegis/aegis.wal.jsonl'

O protocolo do keyring, a janela de sobreposição, a expiração, o rollback e os critérios de aceitação de três réplicas estão em [`docs/operations/KEY_ROTATION_RUNBOOK.md`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/docs/operations/KEY_ROTATION_RUNBOOK.md). Um caminho de keyring não é um gerenciador de segredos; a implantação ainda deve estabelecer custódia, controle de acesso, entrega atômica, backup, destruição e auditabilidade.

## Modelo de evidência e assinatura

O ledger local é um WAL JSONL somente de acréscimo com uma cadeia limitada em memória e segmentos arquivados opcionais. Cada registro contém hashes de requisição e resposta, encadeamento de cadeia, uma raiz Merkle, metadados de assinatura e o identificador da requisição. O WAL é descarregado e sincronizado antes que o caminho de resposta durável seja concluído.

As opções de assinatura suportadas dependem da implantação:

| Assinante | Limite apropriado | Limitação importante |
|---|---|---|
| HMAC-SHA256 | Implantações self-hosted de nó único ou com segredo compartilhado | Chave simétrica; todo verificador que detém a chave também pode assinar. HMAC é clássico, não resistente a quantum. |
| Assinante com suporte a HSM/Vault | Implantações empresariais que exigem isolamento de chave ou custódia remota | Disponibilidade, política, TLS/mTLS, rotação e verificação offline exigem evidências próprias da implantação de destino. |
| Assinante nativo ML-DSA-65 | Ambientes que compilam e carregam o backend Rust real | O artefato candidato retido de 1M de amostras não encontrou diferença significativa de tempo para `sign` (`p=0.8521504207157158`), mas não atingiu o limite para `verify` (`p=0.0`); nenhuma alegação de tempo constante é aprovada. Consulte [`docs/security/PQC_CONSTANT_TIME.md`](https://github.com/juanlunaia/aegis-latent-core/blob/HEAD/docs/security/PQC_CONSTANT_TIME.md). |

O Aegis não fabrica assinaturas ML-DSA quando o backend nativo está indisponível. Ele reporta o backend como indisponível e exige uma política explícita de fallback real. Um resultado de tempo com `p > 0.05` significaria apenas que vazamento estatisticamente significativo não foi detectado sob o experimento nomeado; não provaria execução em tempo constante.

## Semântica de backpressure e falha

Evidência durável é um invariante de caminho crítico. Sob armazenamento ou parada de `fsync`, o caminho de requisição pode bloquear ou rejeitar de acordo com os limites configurados; ele não deve descartar silenciosamente evidência autoritativa. A fila de enriquecimento pode rejeitar trabalho opcional, mas uma política de fila não pode transformar uma resposta aceita governada em uma resposta não registrada.

O harness determinístico de injeção de falhas é:```bash
PYTHONPATH=. .venv/bin/python tools/benchmarks/run_backpressure_stall.py \
  --duration-s 0.25 --offered-rps 10000 --fsync-delay-ms 2 --max-workers 64 \
  --output evidence/backpressure_stall_report.json