AGA MCP Server

Governança de tempo de execução criptográfica para agentes de IA. 20 ferramentas. Artefatos de política selados, medição contínua, prova à prova de adulteração. Ed25519 + SHA-256.

GitHubExperimente este MCPPatrocinado

Documentação

AGA - Artefatos de Governança Atestados

Registros de decisão verificáveis para agentes de IA: cada decisão registrada de chamada de ferramenta é um recibo assinado e encadeado por hash, exportado em pacotes de evidência que um revisor pode verificar offline contra o formato publicado. A verificação estabelece a integridade dos recibos presentes, não que toda ação foi registrada.

Status: implementação de referência publicada, antes da validação piloto independente. O gateway emite pacotes clássicos Ed25519-SHA256-JCS. A CLI @attested-intelligence/aga-verify@2.2.2 publicada verifica esse perfil clássico; em um pacote v2/híbrido, ela reporta FALHOU porque não implementa esse perfil. O pacote também expõe um composto ML-DSA-65 + Ed25519 como perfil de biblioteca, e aga-proxy verify pode verificá-lo. Os verificadores de referência têm seu próprio comportamento para perfis não suportados. Esses são componentes diferentes, não um verificador intercambiável. A procedência da construção diz respeito à construção publicada; não é correção em tempo de execução nem uma auditoria de segurança externa.

Status de tempo de execução. Desde 3.5.0, uma medição solicitada após o TTL do artefato ativo expirar o move para TERMINATE; delegate_to_subagent também recusa após a expiração. Nada verifica o TTL em um cronograma, e o pacote exportado não registra essa transição. Não faça downgrade para a obsoleta 3.3.3 como caminho de avaliação. Desde 3.6.0, aga-proxy honra AGA_GATEWAY_KEY / AGA_GATEWAY_KEY_FILE; o upstream stdio pode herdar essas variáveis. Leia os problemas conhecidos e THREAT_BOUNDARY.md antes de qualquer avaliação em tempo de execução.

# This package IS the AGA MCP server (TypeScript, runs over stdio). Use it from any MCP client:
npx -y @attested-intelligence/aga-mcp-server@3.6.2

Os exemplos de tempo de execução abaixo identificam o pacote 3.6.2 observado, não uma implantação de produção recém-aprovada. Revise os problemas conhecidos primeiro; uma avaliação sintética isolada é necessária antes de considerar um piloto. Prefira o caminho do verificador estático para a primeira verificação.

Um SDK complementar em Python (aga-governance) está documentado na seção SDK Python abaixo.

Verifique você mesmo (não confie na nossa palavra)

Você não precisa aceitar nada disso por fé. O repositório inclui o verificador de referência, os vetores canônicos e pacotes de exemplo, para que você possa verificar um offline agora mesmo, sem rede e sem retorno para nós:

git clone https://github.com/attestedintelligence/aga-mcp-server
cd aga-mcp-server
# A canonical SEP bundle verifies; a one-byte-tampered copy is rejected.
node aga-receipt-spec/verify/verify-sep.mjs fixtures/valid_minimal.json   # OVERALL: VERIFIED (integrity only; no key pinned)
node aga-receipt-spec/verify/verify-sep.mjs fixtures/tampered.json        # OVERALL: FAILED

A CLI @attested-intelligence/aga-verify publicada concorda no corpus clássico testado conforme o harness o fornece. npm run conformance:cross-stack (primeiro: npm run build && npm --prefix independent-verifier run build) prova que seis configurações de verificador v1, abrangendo três toolchains independentes (JavaScript, Go e Python, incluindo um caminho puro-stdlib, sem criptografia de terceiros), concordam nos 54 casos de nível de objeto. Os cinco verificadores de análise de arquivo também concordam nos 7 casos de bytes brutos/análise de arquivo (61 no total). O mecanismo no servidor é somente biblioteca, recebendo objetos analisados em vez de bytes brutos de arquivo, portanto não executa os casos de análise de arquivo; seis configurações não concordam em todos os 61 e isso não afirma mais que concordam. npm run conformance:cross-stack-v2 prova que dois oráculos genuinamente independentes em linguagem (@noble/JS e CIRCL/Go) concordam no corpus composto v2. Para uma reprodução de fonte e construção (construa o pacote você mesmo, reproduza o tarball publicado byte por byte, re-execute cada portão), veja o REVIEWER_GUIDE.md (um caminho de autoatendimento comando por comando), REPRODUCIBILITY.md e o passo a passo SKEPTICAL_AUDITOR.md. Esta versão carrega procedência de construção SLSA, verificável com npm audit signatures.

O Que Isso Faz

Isso é construído para equipes que enviam produtos de IA agêntica para serviços financeiros e seguros, no momento em que a revisão de risco de fornecedor, risco de modelo ou auditoria interna de um cliente pergunta o que seu agente fez e como alguém saberia.

Chamadas de ferramentas cobertas roteadas através de aga-proxy são avaliadas contra sua política configurada. Cada decisão registrada (PERMITIDO ou NEGADO) assume a forma de um recibo de governança assinado e vinculado por hash; o problema conhecido 7 abaixo descreve chamadas recusadas sem recibo. aga-proxy também assina o SHA-256 do JSON canônico de sua política em cada recibo; veja KNOWN_LIMITATIONS.md para o que esse campo vincula. Os recibos são coletados em pacotes de evidência que qualquer pessoa com o formato publicado e a chave pública pode verificar offline, sem retorno para nós.

Registre. Prove. Verifique.

Escopo: um pacote verificado prova a integridade dos recibos presentes: cada um é autêntico, corretamente ordenado, incluído no Merkle e (quando uma chave é fixada) vinculado à procedência. Isso não prova a não omissão (que toda ação que o agente tomou foi registrada); a completude é limitada pela evidência de adulteração do ponto de interceptação, que está fora do pacote. Veja KNOWN_LIMITATIONS.md para o limite honesto completo, e THREAT_BOUNDARY.md para o detalhe por campo.

Uso com Claude Desktop

Adicione à sua configuração MCP do Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "aga": {
      "command": "npx",
      "args": ["-y", "@attested-intelligence/aga-mcp-server@3.6.2"]
    }
  }
}

Claude pode então selar artefatos, medir integridade, gerar pacotes de evidência e verificá-los offline através de linguagem natural.

Persista a chave de assinatura (faça isso primeiro)

Por padrão, o gateway assina com uma chave efêmera que gira a cada reinicialização. Isso é suficiente para uma primeira olhada, mas a procedência do pacote de evidência não pode ser fixada entre reinicializações (e o servidor avisa sobre isso no stderr). Defina uma semente Ed25519 estável de 64 hex para que a procedência permaneça fixável:

Desde 3.6.0 isso se aplica a ambos os binários. aga-proxy lê as mesmas duas variáveis através do mesmo resolvedor e imprime a chave pública ativa na inicialização para que você possa fixá-la fora de banda; --ephemeral torna uma chave descartável uma escolha declarada. Em 3.5.0 e anteriores, aga-proxy ignorou ambas as variáveis silenciosamente; uma chave que você definiu não teve efeito e nenhum aviso foi impresso, então evidência de tal proxy é verificável em integridade, mas não fixável em procedência entre reinicializações. Veja DEPLOYMENT.md §2.

# generate a seed once (32 random bytes, hex)
node -e "console.log(require('node:crypto').randomBytes(32).toString('hex'))"

Forneça via AGA_GATEWAY_KEY, ou AGA_GATEWAY_KEY_FILE (um caminho para a semente). No Claude Desktop, adicione um bloco env:

{
  "mcpServers": {
    "aga": {
      "command": "npx",
      "args": ["-y", "@attested-intelligence/aga-mcp-server@3.6.2"],
      "env": { "AGA_GATEWAY_KEY": "<your-64-hex-seed>" }
    }
  }
}

Mantenha a semente em segredo e fora do controle de versão; veja DEPLOYMENT.md para manuseio de chaves. Uma semente no ambiente de um cliente agente não é um domínio de confiança separado, e o upstream stdio pode herdar as variáveis relacionadas à chave (problema conhecido 3). Reinicializações com a mesma chave não preservam o ledger em memória: exporte e verifique antes de parar.

Ferramentas MCP (15)

Categoria	Ferramentas
Identidade	`get_server_info`, `get_portal_state`
Ciclo de vida	`init_chain`, `attest_subject`, `revoke_artifact`
Medição e decisão	`measure_integrity`, `measure_behavior`, `verify_chain`
Evidência	`generate_evidence_bundle`, `verify_bundle_offline`
Privacidade	`request_claim`, `list_claims`
Delegação	`delegate_to_subagent`
Auditoria	`get_receipts`, `get_chain_events`

measure_behavior é somente detetive por padrão: observa padrões de uso de ferramentas e registra uma constatação de deriva assinada e comprovável, mas não bloqueia. A aplicação (deriva → quarentena) é opcional via enforce=true e desativada por padrão. Decisões de governança rígidas (PERMITIDO/NEGADO) são tomadas pelo portal/PEP, não pelo monitor comportamental.

Início Rápido: verifique um pacote offline

Um pacote que este pacote emite (via ferramenta MCP generate_evidence_bundle) é um pacote SEP canônico. Verifique-o offline, sem rede e sem retorno para nós:

# Published verifier CLI. Obtain and authenticate the expected key outside the bundle before running.
npx -y @attested-intelligence/aga-verify@2.2.2 evidence-bundle.json --pubkey <gateway-public-key>

# Or, from a clone of this repo, the zero-dependency reference verifier (Node 18+) checks its supported profile; parser/pin behavior can differ:
node aga-receipt-spec/verify/verify-sep.mjs evidence-bundle.json --pubkey <gateway-public-key>

A CLI @attested-intelligence/aga-verify publicada é o caminho enviado (a antiga 1.0.0 forjável é obsoleta); o verify-sep.mjs de referência fornece outra implementação a partir de um clone do repositório; a concordância de veredito é limitada aos casos testados, não a todos os bytes de entrada. Sem --pubkey você obtém um resultado somente de integridade (issuerVerified=false); forneça uma chave esperada não vazia de um canal confiável separado para autenticar essa chave de assinatura; o mapeamento para uma organização depende desse canal. Um --pubkey final sem valor cai para sucesso somente de integridade em 2.2.2. Veja THREAT_BOUNDARY.md §3.7. Um verificador de navegador hospedado está vinculado em Links.

O algoritmo de referência §6 é implementado em três linguagens: JavaScript (aga-receipt-spec/verify/verify-sep.mjs), Go (verify.go, stdlib crypto/ed25519) e Python (verify.py, Ed25519 RFC-8032 puro-stdlib). Um harness entre stacks (npm run conformance:cross-stack; primeiro: npm run build && npm --prefix independent-verifier run build) prova que todos os três, mais o mecanismo no servidor e aga-verify, concordam nos casos canônicos publicados conforme o harness os fornece (casos de objeto são re-serializados; casos de bytes brutos são separados). Fora desse corpus, as implementações diferem, incluindo algumas semânticas de parser e pin. O perfil composto v2 (ML-DSA-65+Ed25519-SHA256-JCS) é mantido no mesmo padrão por um segundo harness (npm run conformance:cross-stack-v2): um mecanismo @noble/JavaScript e um oráculo CIRCL/Go, duas toolchains genuinamente independentes, produzem vereditos idênticos no corpus v2 fixado, e o verificador v1 de referência (verify-sep.mjs/verify.py/verify.go) retorna UNSUPPORTED_PROFILE (código de saída 3) em um pacote v2, sinalizando "perfil não implementado" em vez de um "inválido" enganoso. (A CLI aga-verify publicada não implementa essa tricotomia de perfil: em um pacote v2 ela retorna FALHOU (código de saída 1). Use o código de saída 3 como sinal de perfil não suportado apenas com os verificadores de referência.)

Mapeamento de nomes de verificação entre implementações

O verificador de referência JS e o SDK Python (aga-governance) decompõem a mesma verificação de sete etapas de forma diferente. Vereditos gerais e códigos de saída concordam em todos os 61 casos do corpus de conformidade conforme o harness entre stacks os fornece (casos de nível de objeto re-serializados, então grafias de float chegam como inteiros; medido em aga-governance 0.3.2 em 2026-09-25) e nos 10 células re-provas em 2026-07-01 (pacotes intactos e adulterados com chaves não fixadas, corretas e erradas). Nos bytes literais do arquivo do caso leaf_index com grafia float do corpus (0.0), aga-governance 0.3.2 reporta FALHOU onde o JS de referência, aga-verify, Go e os verificadores de referência Python reportam VERIFICADO; veja https://attestedintelligence.com/spec. A sub-verificação que reporta uma dada adulteração pode diferir:

Verificação de referência JS	Campo de resultado Python	O que cobre
`structural`	`algorithm_valid` + partes de `bundle_consistent`	id do algoritmo, boa formação da chave, contagens de recibo/prova
`receipt_signatures`	`receipt_signatures_valid`	Ed25519 sobre bytes canônicos do recibo
`chain_and_ordering`	`chain_integrity_valid`	vinculação de folha anterior, timestamps canônicos não decrescentes (ids não são campos de ordenação e não são verificados)
`merkle_and_bijection`	`merkle_proofs_valid`	recálculo de folha, caminho de raiz única, bijeção de índice
`signed_checkpoint`	`checkpoint_valid`	raiz assinada pelo gateway + contagem + vinculação de cabeça de cadeia
`envelope_consistency`	`envelope_consistent`	envelope `gateway_id`, `generated_at`, `merkle_root` vs conteúdo assinado (`bundle_id`, `schema_version`, o envelope `policy_reference` e `offline_capable` são não assinados e não verificados)
`gateway_key_match` (com `--pubkey`)	`gateway_key_match` / `provenance`	chave do emissor fixada

Diferença de decomposição conhecida: a referência JS recalcula cada folha Merkle a partir do conteúdo completo do recibo, então uma adulteração na assinatura do recibo também falha em merkle_and_bijection; o verificador Python expõe a mesma adulteração em receipt_signatures_valid, chain_integrity_valid e bundle_consistent enquanto seu merkle_proofs_valid pode permanecer verdadeiro. Nenhum é mais permissivo: o pacote falha em ambas as pilhas, saída 1. Um --pubkey KEY que não seja 64 caracteres hexadecimais minúsculos é um erro de uso (saída 2) na referência JS, aga-verify e no SDK Python, e um pin de 64 hex que não seja um ponto de curva válido é honrado, falha ao corresponder e faz o pacote falhar (saída 1). Escrito como --pubkey=KEY, o pin é ignorado pela referência JS, aga-verify, verify.go e v2/verify-v2.go, e por verify.py quando segue o caminho do pacote (somente integridade, saída 0), e é lido pelo SDK Python. Outros verificadores também diferem. O mecanismo no servidor (a exportação ./verify do pacote, que verify_bundle_offline chama) trata um pin que não seja uma chave bem formada para o perfil do pacote (para um pacote v1, um ponto de ordem pequena ou uma codificação não canônica) como ausência de pin e retorna VERIFIED com pinned: false. v2/verify-v2.go faz o mesmo e imprime integrity only; no key pinned (saída 0). Um valor de 64 hex que não seja um ponto de curva conta como bem formado, então ambos o tratam como pin e o pacote falha. Os verificadores de referência Go e Python em aga-receipt-spec/verify/ tratam um pin que não seja 64 hex minúsculos da mesma forma e imprimem integrity only; no key pinned (saída 0). Leia pinned antes de aceitar um VERIFIED como proveniência; em CI, passe a chave após um espaço e verifique se a saída diz proveniência verificada. Um --pubkey fornecido sem valor também é tratado como ausência de pin (saída 0, somente integridade) por aga-verify, verify-sep.mjs, verify.py, verify.go e v2/verify-v2.go, e é um erro de uso no SDK Python. Outras diferenças dizem respeito ao pacote em vez do pin, e https://attestedintelligence.com/security lista as medidas, incluindo quais rótulos de algoritmo cada verificador deixa sem verificação; fora do corpus de conformidade, os verificadores diferem em ambas as direções. Dois exemplos, onde o lado com falha falha de forma fechada: uma prova leaf_index escrita como um float integral (1.0) relata FAILED no aga-governance 0.3.2 e VERIFIED nos outros, e chaves de objeto fora do Plano Multilíngue Básico (possível apenas em um valor de campo não string, que nenhum produtor enviado emite) classificam de forma diferente em verify.py, verify.go, v2/verify-v2.go e aga-governance do que nos verificadores JavaScript, então tal pacote relata VERIFIED em JavaScript e FAILED em Go e Python. Isso aguarda a próxima versão revisada.

Como Funciona

AI Agent                  AGA Proxy                      Verifier
   |                          |                              |
   |-- tools/call ----------->|                              |
   |                    [Evaluate Policy]                    |
   |                    [Sign Receipt]                       |
   |                    [Chain to Previous]                  |
   |<-- PERMITTED/DENIED -----|                              |
   |                          |                              |
   |                    [Export Bundle]                       |
   |                          |--------- evidence.json ----->|
   |                          |                  [Verify Signatures]
   |                          |                  [Verify Chain + Order]
   |                          |                  [Verify Merkle Tree]
   |                          |                  [Verify Signed Checkpoint]
   |                          |                  [PASS / FAIL]

Proxy de Governança MCP

Execute o AGA como um proxy na frente de um servidor MCP que ele inicia como um processo filho stdio (o transporte stdio padrão), ou um que ele alcança com um POST JSON-RPC simples (--upstream-url; sem sessão HTTP Streamable ou manipulação SSE). A porta do agente do proxy fala JSON-RPC 2.0 delimitado por nova linha sobre TCP bruto, não stdio ou HTTP Streamable. Um cliente MCP stdio precisa de um relay que você fornece (algumas linhas que canalizam stdin para a porta e a porta para stdout); nenhum é enviado. Um cliente com script pode falar esse enquadramento diretamente. Cada solicitação tools/call com um nome de ferramenta string não vazio e argumentos que o proxy pode canonicalizar é avaliada contra a política e produz um recibo assinado, exceto as chamadas que o problema conhecido 7 abaixo descreve como recusadas sem um. Outros métodos que não são benignos são encaminhados com um recibo de passagem assinado e não são avaliados por política, e métodos de protocolo benignos (initialize, initialized, ping, tools/list, prompts/list, resources/list, resources/templates/list, logging/setLevel, completion/complete e notifications/*) não produzem recibo (THREAT_BOUNDARY.md seção 3 item 2). Leia os problemas conhecidos abaixo antes de expor a porta.

# Start the proxy (the `aga-proxy` bin) in front of an upstream MCP server.
# stdio upstream = the default stdio transport (the upstream is a child process, not network-reachable).
npx -p @attested-intelligence/aga-mcp-server@3.6.2 aga-proxy start \
  --upstream "npx -y @modelcontextprotocol/server-filesystem /tmp/test" --profile permissive

permissive registra cada tools/call que avalia (o problema conhecido 7 descreve as exceções) e não nega nada por motivos de política. standard e restrictive permitem apenas nomes de ferramentas de exemplo genéricos, então negam todas as ferramentas que este servidor de exemplo expõe; para permitir algumas ferramentas do seu servidor e negar o resto, passe um arquivo --policy que as nomeie.

Exportando o pacote de evidências de um proxy em execução

O proxy registra recibos em seu próprio processo e mantém o livro-razão SEP na memória. Para tornar esse livro-razão ativo acessível de um shell separado, aga-proxy start abre um canal de controle somente loopback: um listener HTTP vinculado a 127.0.0.1 (nunca uma interface roteável), em sua própria porta (padrão 18801, substituível com --control-port), distinto da porta do proxy voltada para o agente (18800). Ele expõe apenas rotas de leitura (/export, /status, /receipts); nada nele altera política ou estado. Ele não verifica o cabeçalho Host ou Origin de uma solicitação, então uma página da web em um navegador no mesmo host pode ler suas respostas por meio de rebinding de DNS, a menos que o navegador bloqueie (problema conhecido 12). O proxy escreve a porta de controle escolhida em ~/.aga-proxy/control.json ao lado de proxy.pid.

Uma invocação separada de aga-proxy export lê esse arquivo e busca o mesmo pacote assinado que o proxy em execução emitiria:

# Terminal A: start the proxy in front of an upstream MCP server
npx -p @attested-intelligence/aga-mcp-server@3.6.2 aga-proxy start \
  --upstream "npx -y @modelcontextprotocol/server-filesystem /tmp/test" --profile permissive

# (First, drive at least one tools/call through the proxy from your MCP client; an empty
#  ledger has no receipts to checkpoint, and the export reports there is nothing to export.)
# Terminal B: export the live ledger from a different shell, then verify it offline
npx -p @attested-intelligence/aga-mcp-server@3.6.2 aga-proxy export -o evidence.json
npx -y @attested-intelligence/aga-verify@2.2.2 evidence.json --pubkey <gateway-public-key>

Exporte e verifique antes de parar o proxy: aga-proxy stop encerra o processo sem exportar, e a cadeia na memória vai junto (o problema conhecido 9 cobre o tempo de exportação e a limitação da cadeia).

Se nenhum proxy estiver em execução, aga-proxy export imprime no running proxy found; start it first, or export from within the session e sai com código não zero; nunca emite um pacote vazio ou placeholder. Dentro da sessão do servidor MCP, você também pode chamar a ferramenta generate_evidence_bundle e salvar o JSON retornado.

Livro-razão na memória: o pacote exportado é o registro criptográfico durável, mas a cadeia ativa no processo não sobrevive a um reinício do proxy. Este fluxo torna o livro-razão ativo acessível de outro processo; ele não adiciona persistência entre reinícios, que precisa do backend persistente (SQLite) e permanece no roadmap (veja KNOWN_LIMITATIONS.md).

O proxy intercepta solicitações tools/call, avalia-as contra a política carregada (um arquivo JSON ou um perfil embutido; o SHA-256 do seu JSON canônico é assinado em cada recibo) e gera um recibo SEP assinado para cada decisão (exceto as chamadas que o problema conhecido 7 abaixo descreve como recusadas sem um). Chamadas permitidas são encaminhadas ao servidor downstream; chamadas negadas retornam um erro MCP e nunca o alcançam. Cada decisão é vinculada por hash e ancorada em checkpoint em um pacote à prova de adulteração. (Métodos diferentes de tools/call não são avaliados por política, mas os não benignos são registrados como recibos de passagem assinados para auditabilidade, e um chamador de biblioteca pode passar uma lista de negação de métodos (denyMethods) para rejeitá-los; o CLI aga-proxy não tem flag para isso; veja THREAT_BOUNDARY.md §3.2.)

Três perfis de política embutidos:

permissive - audit_only: não nega nada por motivos de política e registra cada tools/call que avalia (padrão); as recusas de falha fechada abaixo e o problema conhecido 7 ainda se aplicam
standard - uma lista de permissões de dez nomes de ferramentas de exemplo genéricos (filesystem_read, shell_execute, web_search e outros) com limites de taxa e negações por substring em dois deles; toda outra ferramenta é negada, então as ferramentas de um servidor real precisam de um arquivo --policy
restrictive - uma lista de permissões de três nomes de ferramentas de exemplo genéricos com limites de taxa mais baixos e um prefixo de caminho em um; toda outra ferramenta é negada

Como o padrão (permissive) é somente auditoria, iniciar com uma política audit_only imprime um banner de stderr alto afirmando que cada chamada é permitida e registrada e nenhuma chamada é negada nesse modo. Nenhuma chamada é negada por motivos de política, mas o proxy ainda recusa, com falha fechada, um tools/call sem nome de ferramenta ou com argumentos que não pode canonicalizar (aninhados além de 100 níveis, por exemplo), e assina um recibo DENIED para cada; um nome de 0, false, null ou uma string vazia conta como ausência de nome. A negação por política precisa de --profile standard ou restrictive, ou um arquivo --policy no modo allowlist ou denylist. No modo denylist, uma política nega cada ferramenta que lista como um objeto cujo valor allowed está ausente ou é falso (false, 0, null ou uma string vazia); qualquer outro valor allowed permite a ferramenta, incluindo a string "false", e também uma entrada listada que seja ela mesma false, 0, null ou uma string vazia em vez de um objeto. Em 3.6.0 a 3.6.2, também nega uma ferramenta não listada nomeada como uma propriedade de objeto embutida, como constructor. Aplica os limites de taxa das ferramentas listadas que permite; regras de caminho e padrão se aplicam apenas no modo allowlist e verificam apenas argumentos string de nível superior (problema conhecido 10). Um arquivo --policy no modo audit_only permite cada chamada; um com qualquer outro modo, ou nenhum, nega cada tools/call, e em 3.6.0 a 3.6.2 um no modo allowlist ou denylist cujo membro constraints está ausente ou nulo recusa, sem recibo e sem resposta, cada tools/call que tenha um nome de ferramenta e argumentos que o proxy possa canonicalizar (problema conhecido 7). Um valor --profile não reconhecido é um erro grave (saída 2 listando os nomes válidos), nunca um fallback silencioso para permissive.

Verificação (SEP 3.0 canônico; algoritmo normativo §6 em `aga-receipt-spec/verify/verify-sep.mjs`)

Piso estrutural - O pacote declara Ed25519-SHA256-JCS, chave pública bem formada (todas as codificações de ordem pequena + y ≥ p não canônico rejeitados), receipts.length > 0, contagem de provas = contagem de recibos
Assinaturas de recibos - Ed25519 sobre JSON canônico de perfil JCS, chave classificada (campo de assinatura excluído)
Cadeia + ordenação - O previous_receipt_hash de cada recibo = folha do recibo anterior; carimbos de data/hora não decrescentes
Provas Merkle - Recalcule cada folha a partir do conteúdo do recibo, percorra irmãos/direções até uma raiz, os índices de folha formam a bijeção completa 0..N-1
Checkpoint assinado - Verifique o checkpoint assinado pelo gateway que vincula merkle_root, leaf_count e o topo da cadeia (isso torna a construção sem prefixo segura contra truncamento)
Proveniência (quando uma chave é fixada) - public_key == expected key; caso contrário, somente integridade é relatada

Primitivas Criptográficas

Primitiva	Propósito
Ed25519	Assinaturas de recibos
SHA-256	Encadeamento de hash, árvores Merkle, cálculo de folhas
Perfil JCS (JSON canônico de chave classificada)	Assinatura determinística (canon é byte-compatível com o verificador de referência)
Árvores Merkle	Vinculando todos os recibos a uma única raiz verificável

Gateway ao Vivo

Um gateway de demonstração é implantado no Cloudflare Workers (uma implantação separada que pode rastrear sua própria versão; trate-o como um espelho de conveniência e sempre verifique o que ele retorna offline contra uma chave fixada, não como o artefato canônico):

# Check status
curl https://aga-mcp-gateway.attested-intelligence.workers.dev/health

# Download a static demonstration bundle (not a live export)
curl https://attestedintelligence.com/sample-bundle.json -o evidence-bundle.json
# Static sample only. Use the separately published sample pin, not a key read from this file.

SDK Python

Status, verificado no PyPI em 2026-09-28. A versão atual é aga-governance 0.3.2. A versão 0.3.1 corrigiu o crash de bomba de profundidade; 0.3.0 foi removida por esse crash. Ambos os arquivos 0.2.6 agora também foram removidos, mas isso não repara cópias instaladas. Use a versão atual revisada ao avaliar pacotes não confiáveis e retenha suas limitações documentadas de parser e veredito. O verificador de referência JavaScript e aga-verify não têm esse crash de bomba de profundidade em Python.

pip install "aga-governance==0.3.2"

from aga import AgentSession

with AgentSession(gateway_id="my-gateway") as session:
    session.record_tool_call(
        tool_name="search_web",
        decision="PERMITTED",
        reason="tool in allowlist",
        request_id="req-1",
    )
    bundle = session.export_bundle()
    result = session.verify()
    assert result["overall_valid"]

Suíte de Testes

Testes automatizados em TypeScript e Python, além de um corpus de conformidade:

Servidor MCP TypeScript: 428 testes automatizados (vitest), incluindo regressões de negação comprovável e monitor comportamental
Corpus de conformidade SEP: npm run test:conformance (válido → VERIFIED, negativos → FAILED)
SDK Python complementar: o pacote PyPI aga-governance publicado separadamente (instalado e verificado por smoke test aqui; sua suíte pytest completa é executada a partir da árvore de origem). O smoke test importa o pacote e imprime sua versão. Ele não exercita o verificador.

npm test                              # TypeScript tests (vitest)
npm run test:conformance              # SEP conformance corpus
pip install "aga-governance==0.3.2" && python -c "import aga; print(aga.__version__)"   # Python SDK smoke check

Benchmarks

A determinismo do formato de recibo é reproduzível aqui: npm test executa os vetores entre linguagens, e npm run conformance:cross-stack (primeiro: npm run build && npm --prefix independent-verifier run build) mostra as seis configurações do verificador v1 (em três toolchains independentes: JS, Go, Python) concordando nos 54 casos de nível de objeto do corpus canônico de 61 casos. Os 7 restantes são casos de análise de bytes brutos/arquivos executados pelos cinco verificadores de análise de arquivos, já que o motor no servidor nunca recebe bytes brutos. npm run conformance:cross-stack-v2 mostra os dois oráculos v2 em linguagens independentes concordando no corpus composto.

Estrutura do Projeto

src/
  sep/                 # Canonical SEP evidence engine: single source of truth (canon, merkle, receipt, checkpoint, bundle, verify)
  core/                # Governance primitives (portal, artifact, attestation, disclosure, delegation, behavioral) + internal continuity-chain profile
  crypto/              # Internal continuity-chain crypto: Ed25519 (node:crypto), SHA-256/blake2b, salt
  proxy/               # MCP governance proxy (transparent interception + policy evaluation; emits SEP bundles)
  middleware/          # Governance PEP wrapper (records a signed PERMITTED/DENIED receipt per governed call)
independent-verifier/  # @attested-intelligence/aga-verify: standalone SEP verifier, zero AGA imports
scenarios/             # Demo scenarios (SCADA, autonomous vehicle, AI agent) that emit SEP bundles
tests/                 # TypeScript test suite (428 automated tests)

Problemas conhecidos em 3.6.0 a 3.6.2 e nos verificadores publicados

3.6.1 e 3.6.2 alteram apenas a documentação e o número da versão; o runtime é o da 3.6.0. Os itens 1 a 4 foram reproduzidos em 2026-09-23 no @attested-intelligence/aga-mcp-server 3.6.0 instalado via npm, e dizem respeito ao gateway aga-proxy. O item 5, adicionado em 2026-09-25, diz respeito aos verificadores e foi reproduzido em 2026-09-25 nas versões atuais. O item 6, também adicionado em 2026-09-25, diz respeito ao aga-proxy com um upstream HTTP e foi reproduzido em 2026-09-25 na 3.6.2. O item 7, também adicionado em 2026-09-25, diz respeito a mensagens tools/call que o aga-proxy recusa sem um recibo e foi reproduzido em 2026-09-25 na 3.6.2 (seu caso de mensagem superdimensionada foi adicionado e reproduzido em 2026-09-26). Os itens 8 a 12, adicionados em 2026-09-26, dizem respeito a texto não ASCII, ao custo de exportar evidências, ao que as verificações de política verificam, a resultados de ferramentas superdimensionados e ao canal de controle; cada um foi reproduzido em 2026-09-26 na 3.6.2, assim como os casos de memória e porta Windows adicionados ao item 1 naquele dia. A mesma lista é mantida em https://attestedintelligence.com/security.

A porta do agente escuta em todas as interfaces de rede, sem autenticação. Qualquer pessoa que consiga alcançar o host nessa porta pode enviar chamadas governadas através do proxy. O proxy também não define limite no número de conexões, então, embora a mensagem não finalizada de cada conexão seja limitada (item 7), a memória que elas ocupam juntas não é: na versão 3.6.2, dez conexões que cada uma enviou 7,5 MiB sem encerrar uma mensagem elevaram o conjunto de trabalho do proxy de 68 MiB para 392 MiB enquanto permaneceram abertas, e uma chamada governada em outra conexão ainda foi respondida. No Windows, um processo em execução sob a mesma conta de usuário do proxy pode vincular 127.0.0.1 na mesma porta enquanto o proxy escuta, e um cliente local que se conecta a 127.0.0.1 então alcança esse processo em vez do proxy, sem verificação de política e sem recibo (medido na versão 3.6.2 com ambos os processos sob uma conta). Bloqueie o tráfego de entrada para a porta no firewall do host, ou admita apenas o agente com política de rede; no Windows, não execute nada não confiável sob a conta do proxy e verifique, enquanto o proxy está em execução, que seu processo é o único ouvinte na porta. A porta de controle está vinculada ao loopback; veja o item 12.
Dois clientes que reutilizam um id JSON-RPC através de um proxy podem receber os resultados de ferramentas um do outro. Solução alternativa, medida na versão 3.6.0: dê a cada cliente seu próprio intervalo de ids, ou execute um proxy por cliente. Com ids disjuntos, cada resultado alcançou o cliente que o solicitou.
Quando a chave de gateway é fornecida através de AGA_GATEWAY_KEY (com ou sem --ephemeral) ou AGA_GATEWAY_KEY_FILE, o upstream stdio herda essa variável (a semente, ou o caminho do arquivo), então o upstream fica dentro do domínio de confiança da chave. Solução alternativa, medida na versão 3.6.0: execute sem nenhuma das variáveis. O upstream então não vê nenhuma, mas o proxy assina com uma chave por processo que não pode ser fixada entre reinicializações.
O modo --upstream-url encaminha JSON-RPC bruto sobre HTTP POST com apenas um cabeçalho content-type. Ele não implementa o transporte MCP Streamable HTTP (o cabeçalho Accept, os cabeçalhos de metadados de solicitação e o tratamento de event-stream), então um servidor HTTP MCP em conformidade com a especificação rejeita suas solicitações. Solução alternativa: faça uma ponte para o servidor via stdio.
Um arquivo de pacote pode repetir um nome de campo em qualquer lugar: em um recibo, no checkpoint ou no envelope. Por exemplo, um "decision": "PERMITTED" forjado pode ser colocado antes do "decision": "DENIED" assinado, ou um checkpoint forjado leaf_count antes do assinado. Os verificadores publicados (aga-verify 2.2.2, aga-governance 0.3.2, o verificador neste pacote e os verificadores de referência em aga-receipt-spec/verify/) e a página /verify do site leem a última ocorrência, e quando ela contém o valor genuíno, eles relatam VERIFIED, com proveniência quando a chave está fixada. Eles não rejeitam o arquivo, então uma ferramenta ou uma pessoa lendo a primeira ocorrência pode ver um valor que nunca foi assinado. Medido no pacote de amostra público, fixado à chave de amostra: com o nome repetido inserido em um recibo, no checkpoint ou no envelope, aga-verify 2.2.2, aga-governance 0.3.2, o verificador neste pacote e /verify relatam VERIFIED, e uma mudança real do valor do checkpoint falha. Solução alternativa: trate a saída analisada do verificador como o conteúdo do registro e rejeite ou sinalize arquivos com nomes de campo repetidos antes de exibi-los. Uma rejeição estrita de nomes de campo repetidos está planejada para a versão revisada.
Uma mensagem pode repetir o membro "method" quando aga-proxy tem um upstream HTTP (--upstream-url). Com tools/call primeiro e outro método por último, aga-proxy lê a última cópia, então ele nunca verifica a chamada de ferramenta contra a política, e encaminha todos os métodos diferentes de tools/call para o upstream HTTP como os bytes exatos que recebeu. Um upstream cujo analisador JSON mantém a primeira cópia de um nome repetido então executa a chamada de ferramenta, mesmo uma que a política nega. O pacote não contém recibo para essa chamada: nada quando o último método é um que o proxy passa sem recibo (como ping, initialize, um método de lista ou uma notificação), e caso contrário apenas um recibo de passagem que nomeia o último método. Um upstream que mantém a última cópia trata a mensagem como o método que o proxy leu. O upstream stdio, o padrão, não é afetado: o proxy re-serializa cada mensagem antes de escrevê-la, então o upstream recebe um método. Medido na versão 3.6.2 do npm em 2026-09-25, com o perfil restritivo e com o perfil permissivo padrão. Solução alternativa: mantenha o padrão stdio, ou faça o upstream HTTP rejeitar qualquer mensagem que repita um nome de membro. Uma rejeição estrita de nomes de membros repetidos no proxy está planejada para a versão revisada.
aga-proxy não registra todos os tools/call que recusa. Ele assina o recibo de um tools/call antes de encaminhar a chamada, então com um upstream stdio uma chamada que ele não pode registrar nunca alcança a ferramenta (para um upstream HTTP, veja o item 6), mas tal chamada não deixa recibo. Esses casos foram medidos na versão 3.6.2 do npm em 2026-09-25, cada um sem recibo e sem resposta ao cliente: um tools/call cujo nome de ferramenta é um número diferente de zero, um array ou um objeto (um nome de 0, false, null ou uma string vazia conta como sem nome e recebe um recibo DENIED e um erro); um cujo nome de ferramenta ou id de string contém um surrogate não pareado (o escape JSON \ud800, por exemplo); sob um arquivo --policy em modo allowlist ou denylist cujo membro constraints está ausente ou é nulo, todo tools/call com um nome de ferramenta e argumentos que o proxy pode canonicalizar; e, sob um arquivo de allowlist, uma chamada que ele permitiria de outra forma que carrega um caminho de string quando o path_prefix dessa ferramenta não é nem uma string nem false, 0 ou null. O proxy inicia com tal arquivo de política, e ele relata cada recusa listada acima apenas em seu próprio stderr. Uma mensagem enviada como um array de lote JSON-RPC ou sem "jsonrpc": "2.0" é recusada de forma diferente: o cliente recebe um erro, e não há recibo. Uma mensagem de 8.388.608 caracteres ou mais (unidades de código UTF-16, cerca de 8,4 milhões), não contando a nova linha que a termina, mas contando um retorno de carro antes dessa nova linha, também recebe um erro e nenhum recibo, e o proxy então fecha a conexão, descartando qualquer resposta ainda devida nela. O limite conta a entrada ainda não dividida em mensagens, então uma mensagem logo abaixo do limite pode ser recusada da mesma forma quando a leitura que a completa também carrega entrada suficiente depois dela para passar do limite; se isso acontece depende de onde as leituras caem. Na versão 3.6.2, quando uma mensagem de 100 caracteres, uma mensagem 58 caracteres abaixo do limite e uma mensagem de 100.000 caracteres foram enviadas em uma única escrita, a primeira foi respondida, a segunda recebeu o erro e a conexão foi fechada; enviadas sem a mensagem de 100.000 caracteres, ou sem a de 100 caracteres, todas as mensagens foram encaminhadas. Esses são os casos medidos, não uma prova de que nenhuma outra entrada faz o mesmo. Solução alternativa: dê a cada arquivo de política um objeto constraints cujos valores path_prefix são strings, e faça o cliente expirar uma chamada que não recebe resposta. Um recibo DENIED e um erro para um nome de ferramenta malformado, e uma verificação do arquivo de política na inicialização, estão planejados para a versão revisada.
aga-proxy pode alterar texto não-ASCII cujos bytes são divididos entre duas leituras. Ele decodifica cada bloco que lê da conexão do agente, e da saída de um upstream stdio, por conta própria, então um caractere dividido entre dois blocos se torna um ou mais caracteres de substituição (U+FFFD). Os argumentos de uma chamada de ferramenta podem então alcançar o upstream alterados, e o hash de argumentos do recibo é o hash dos argumentos alterados; um grande resultado não-ASCII de um upstream stdio pode alcançar o agente alterado. O resultado de um upstream HTTP é decodificado inteiro. Se uma divisão acontece depende de como os bytes chegam, então qualquer mensagem com texto não-ASCII pode ser afetada, e as grandes com mais frequência. Medido na versão 3.6.2 do npm em 2026-09-26: uma divisão forçada dentro de "é" alcançou o upstream como dois caracteres de substituição, e um resultado de 200.000 "€" alcançou o cliente com 15 caracteres de substituição nele. Solução alternativa: envie JSON cujos caracteres não-ASCII são escritos como escapes \uXXXX, então cada byte que o proxy lê do agente é ASCII, e faça um upstream stdio fazer o mesmo; uma divisão forçada da mensagem escapada então chegou intacta. Uma correção está planejada para a versão revisada.
Exportar o pacote de evidências leva tempo que cresce com o quadrado do número de recibos, e aga-proxy não lida com mais nada enquanto isso acontece: toda chamada governada espera até o fim da exportação. Uma chamada encaminhada a um upstream stdio que não respondeu quando uma exportação começa recebe um erro de tempo limite se a exportação terminar mais de 30 segundos após a chamada ter sido encaminhada, embora o upstream a tenha executado e seu recibo diga PERMITTED, então um agente que tenta novamente pode executar a ferramenta duas vezes. Medido na versão 3.6.2 do npm em 2026-09-26 através do GET /export do canal de controle: 2,8 segundos com 1.000 recibos e 17,4 segundos com 2.500, com um tools/call enviado durante a exportação esperando o mesmo tempo; com 4.000 recibos uma exportação levou 43,8 segundos, e uma chamada encaminhada logo antes, que o upstream respondeu em 2 segundos, recebeu o erro de tempo limite. Com 1.000 a 4.000 recibos um pacote compacto levou cerca de 1,7 a 1,9 KB por recibo, aumentando com a contagem. Uma auditoria no mesmo dia mediu 88 a 113 segundos com 5.000 recibos. O tempo de verificação cresce quase linearmente. Solução alternativa: cada exportação cobre todos os recibos desde que o proxy iniciou e não encurta a cadeia, então limite a cadeia reiniciando o proxy em um cronograma: pause os agentes, exporte e verifique, depois reinicie. Uma reinicialização começa uma nova cadeia que não está vinculada à última e redefine as contagens de limite de taxa; com uma chave por processo (--ephemeral, ou nem AGA_GATEWAY_KEY nem AGA_GATEWAY_KEY_FILE definidos) também começa uma nova chave de assinatura, impressa na inicialização, que não pode ser fixada entre reinicializações (item 3). Exporte fora de períodos ocupados, e exporte e verifique antes de qualquer parada, porque a cadeia viva é mantida em memória e uma parada perde recibos ainda não exportados. Uma correção que deixa os bytes do pacote inalterados está planejada para a versão revisada.
As restrições de política verificam menos do que seus nomes sugerem. Um path_prefix é verificado apenas quando o valor sob a chave verificada (path, ou as chaves que uma regra lista em path_keys) é uma string, então o mesmo caminho enviado dentro de um array ou um objeto não é verificado. denied_patterns correspondem com distinção de maiúsculas e minúsculas e apenas em argumentos de string de nível superior, então um comando em maiúsculas, ou um dentro de um array ou um objeto aninhado, não é correspondido. Uma chave de restrição que o proxy não reconhece, como um erro de digitação, é ignorada sem aviso, e um valor do tipo JSON errado não é rejeitado: allowed: "false", uma string, permite a ferramenta; no modo denylist uma ferramenta listada como false, null ou 0 em vez de um objeto é permitida; e uma string path_keys não vazia em vez de um array faz a verificação ler cada caractere como um nome de chave, então a chave pretendida fica sem verificação. Os limites de taxa contam por nome de ferramenta em todo o proxy, compartilhados por cada cliente, e no modo allowlist o limite é verificado antes das regras de caminho e padrão, então uma chamada que essas regras negam ainda usa um slot. Medido na versão 3.6.2 do npm em 2026-09-26 com arquivos de política allowlist e denylist: um path_prefix de /home negou "/etc/passwd" e encaminhou ["/etc/passwd"]; um padrão negado de rm -rf negou rm -rf / e encaminhado RM -RF / e o mesmo comando dentro de um array; uma regra escrita como denied_pattern negou nada; allowed: "false" encaminhou a chamada em ambos os modos; uma entrada de lista de negação de false encaminhou a chamada; path_keys: "path" encaminhou /etc/passwd além de um prefixo /home; e, sob um limite de 2 por minuto, duas chamadas negadas por um prefixo /home deixaram uma terceira chamada, para um caminho sob /home, negada pelo limite de taxa, enquanto após uma dessas negações essa chamada foi encaminhada. Solução alternativa: trate regras de caminho e padrão como uma conveniência e não como uma fronteira, restrinja caminhos no próprio servidor upstream e verifique as chaves de um arquivo de política em relação aos nomes de restrição em dist/proxy/types.d.ts. Verificações que falham de forma fechada nessas entradas, e uma verificação do arquivo de política na inicialização, estão planejadas para o lançamento revisado.
Uma resposta de upstream stdio cuja linha JSON tem 8.388.608 caracteres ou mais (unidades de código UTF-16, contando escape JSON e um retorno de carro antes da nova linha, mas não a própria nova linha) é descartada. A chamada já tem um recibo PERMITIDO, e o agente recebe um erro de tempo limite após 30 segundos, então um agente que tenta novamente pode executar a ferramenta duas vezes; o proxy relata o descarte apenas em seu próprio stderr. O limite conta a saída upstream ainda não dividida em linhas, então uma resposta logo abaixo dele pode ser descartada quando a leitura que a completa também carrega saída suficiente depois dela para passar do limite; toda resposta depois dela que começa nessa leitura, possivelmente para chamadas de outros clientes, é descartada junto. Se isso acontece depende de onde as leituras caem. Medido em 3.6.2 do npm em 2026-09-26: um resultado de 9.000.000 de caracteres foi descartado e o agente recebeu o tempo limite após 30,0 segundos, enquanto um resultado de 1.000.000 de caracteres voltou em 31 milissegundos. Através de um proxy em execução, uma linha de resposta de 8.388.607 caracteres foi retornada e uma de 8.388.608 foi descartada; e quando o upstream respondeu a três chamadas em uma única escrita (100 caracteres e 58 abaixo do limite para um cliente, depois 100 para o outro), a primeira foi respondida e as outras duas, uma delas do outro cliente, expiraram, enquanto as mesmas respostas sem a resposta inicial de 100 caracteres foram ambas retornadas. Esses são os casos medidos. Uma resposta de upstream HTTP é lida inteira e não é descartada dessa forma; no Linux, uma no mesmo limite fecha a conexão do agente em vez disso (item 13). Solução alternativa: mantenha os resultados da ferramenta bem abaixo do limite, por exemplo lendo arquivos grandes em partes, e onde os resultados são grandes, execute um proxy por cliente. Um erro retornado imediatamente é planejado para o lançamento revisado.
O canal de controle não verifica o cabeçalho Host ou Origin de uma solicitação. Ele escuta em 127.0.0.1 (porta 18801 por padrão) para que um aga-proxy export separado possa buscar o pacote ao vivo (rotas /export, /status e /receipts). Medido em 3.6.2 do npm em 2026-09-26: GET /receipts e GET /export enviados com o Host e Origin de outro site retornaram 200, e ambos carregaram o caminho do argumento de uma chamada negada em seu motivo de negação. Uma página da web aberta em um navegador no mesmo host pode, portanto, ler os recibos ao vivo e o pacote de evidências através de rebinding de DNS, a menos que o navegador bloqueie solicitações de um site público ao endereço de loopback; qualquer usuário local no host também pode lê-los. Uma página também pode iniciar uma exportação com um GET /export simples sem rebinding, a menos que o navegador bloqueie, e cada exportação retém chamadas governadas enquanto executa (item 9). A CLI não tem opção destinada a desligar o canal; um --control-port de 70000, ou qualquer número acima de 65535, o deixa não iniciado enquanto a governança executa, mas então nenhum comando pode exportar os recibos do proxy em execução. Solução alternativa: não navegue na web no host enquanto o proxy executa, ou execute o proxy em um host onde ninguém navega, e em um host compartilhado com outros usuários trate os recibos ao vivo como legíveis por todos eles. Uma verificação de Host e Origin está planejada para o lançamento revisado.
No Linux, uma resposta de upstream HTTP (--upstream-url) cuja linha JSON, como o proxy a serializa, tem 8.388.608 caracteres ou mais (unidades de código UTF-16, contando escape JSON mas não a nova linha) fecha a conexão do agente. O proxy escreve a linha inteira no socket do agente em uma única chamada. Um kernel Linux com seus buffers de socket padrão aceita apenas parte de uma escrita desse tamanho; o resto sai conforme o cliente lê, mas a linha inteira conta como esperando até que tudo tenha saído, então a proteção do proxy contra um cliente que não lê suas respostas vê mais de 8.388.608 caracteres esperando, incluindo a nova linha, e destrói o socket. A chamada já tem um recibo PERMITIDO e o upstream executou a ferramenta; a conexão do agente fecha no meio da resposta sem mensagem de erro, então um agente que reconecta e tenta novamente pode executar a ferramenta duas vezes; toda outra chamada em andamento nessa conexão é perdida junto; e o proxy não relata nada. Medido em 3.6.2 do npm em 2026-09-26 em um host Linux 6.18 com Node 24 e os buffers de socket padrão (net.ipv4.tcp_wmem 4096 16384 4194304): linhas de resultado de 4.000.000, 8.000.000, 8.388.606 e 8.388.607 caracteres foram retornadas, e linhas de 8.388.608, 8.388.609, 9.000.000, 10.000.000, 12.000.000, 16.000.000, 20.000.000 e 32.000.000 caracteres fecharam a conexão após 3,1 a 5,0 MB da resposta terem chegado; um cliente que não leu nada por 4 segundos recebeu um resultado de 4.000.000 de caracteres e perdeu um de 9.000.000 de caracteres após 2,7 MB. No Windows 11, o mesmo proxy retornou um resultado de 20.000.000 de caracteres, e um de 9.000.000 de caracteres para um cliente que não leu nada por 4 segundos, porque esse kernel aceitou cada escrita inteira. Uma resposta de upstream stdio desse tamanho é descartada em vez disso (item 11). Solução alternativa: mantenha os resultados da ferramenta bem abaixo do limite, por exemplo lendo arquivos grandes em partes. Um erro retornado imediatamente está planejado para o lançamento revisado. Nenhuma versão fixa é nomeada até que uma seja publicada.

Segurança

Consulte SECURITY.md para relatar vulnerabilidades.

Contribuição

Consulte CONTRIBUTING.md para configuração de desenvolvimento e diretrizes.

Licença

MIT. O diretório aga-receipt-spec/ possui sua própria licença Apache-2.0 (consulte aga-receipt-spec/LICENSE).

Attested Intelligence Holdings LLC