TenantGuard

TenantGuard

Instalação • Início rápido • Recursos • Referência da CLI • Servidor MCP • Comparar • FAQ

Encontre a lacuna de isolamento entre locatários na sua plataforma de agentes de IA multi-locatário auto-hospedada antes que um auditor — ou um atacante — o faça.

Instalação

npm install -g tenantguard-cli

Esta é a instalação recomendada. O pacote npm tenantguard-cli (atualmente 0.2.0, renomeado do antigo tenantguard, que está obsoleto) inclui o binário de plataforma correspondente como um optionalDependency npm (verificado por cosign no momento da publicação, então não há etapa de verificação separada para você) e coloca um comando tenantguard no seu PATH.

Cobertura de plataformas: macOS em Intel e Apple Silicon, Linux em x64 e arm64, e Windows em x64 e arm64.

go install github.com/RudrenduPaul/TenantGuard/cmd/tenantguard@v0.2.0

go install funciona em todas as plataformas suportadas pelo Go e não depende de nenhum estado de publicação de registro, então é a alternativa caso sua plataforma não esteja coberta acima.

Você também pode pular o pacote de nível superior e instalar um pacote binário de plataforma única diretamente:

npm install tenantguard-darwin-arm64   # swap for your platform: darwin-x64, linux-x64, linux-arm64, win32-x64, win32-arm64
./node_modules/tenantguard-darwin-arm64/bin/tenantguard scan --demo

Python (pip / uvx)

pip install tenantguard-cli
uvx --from tenantguard-cli tenantguard scan --demo

O pacote PyPI, tenantguard-cli, vive neste repositório sob python/ e é construído e testado no CI. Sua versão atual é 0.1.6, que baixa e executa a compilação v0.2.0 do mesmo binário de GitHub Releases que os pacotes npm usam, verificando o SHA-256 checksums.txt do release na primeira execução (ele próprio verificado por assinatura Sigstore antes que qualquer digest interno seja confiável) e armazenando em cache o binário verificado localmente depois disso. Isso é um limite de confiança diferente dos pacotes npm, que incorporam um binário verificado por cosign no momento da publicação e não precisam de download em tempo de execução; a verificação de checksum do wrapper PyPI é a garantia equivalente para um caminho que precisa buscar o binário na máquina do usuário final.

Versões do PyPI até e incluindo 0.1.2 enviaram um bug que fazia pip install tenantguard-cli ter sucesso, mas tenantguard scan --demo falhar na primeira execução com could not parse checksums.txt.pem as a PEM certificate (o wrapper não estava decodificando em base64 os ativos de release de certificado/assinatura produzidos por cosign antes de analisá-los). Isso foi corrigido no tenantguard-cli 0.1.3, publicado no PyPI em 2026-08-03; pip install tenantguard-cli agora instala uma ferramenta funcional sem etapas extras.

Início rápido

tenantguard scan --demo

Saída real capturada:

TenantGuard: Tenant-Isolation Audit
Target: /var/folders/m0/5tzdd47n6znb166d4w3m2q0c0000gn/T/tenantguard-demo-488625596

[FAIL]  TA01 sandbox/workspace mount path is not scoped per-tenant (no ${TENANT_ID} placeholder and no explicit scoped_per_tenant declaration)
  .../deployment.yaml:12
  Maps to: goclaw#1163 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA02 MCP tool URL targets a private/loopback/reserved address (via real CIDR containment on a literal or DNS-resolved IP) without a verified, IP-pinned SSRF validator or an explicit host allowlist entry. CAVEAT: a PASS trusts the deployment's own pins_resolved_ip/validates_private declaration -- TenantGuard cannot verify the real validator actually pins the resolved IP for the connection itself, so DNS-rebinding/TOCTOU risk persists if that declaration is inaccurate
  .../deployment.yaml:22
  Maps to: goclaw#1070 | HIPAA Sec164.312(e)(1) Transmission Security (provisional)

[FAIL]  TA03 cron binding's target agent does not belong to the declaring tenant
  .../deployment.yaml:35
  Maps to: goclaw#1217 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA04 exec tool denies direct env dump but not indirect env reads (e.g. jq $ENV), or allows credential-chain leakage via allow_chain_exec (goclaw#1033)
  .../deployment.yaml:25
  Maps to: goclaw#1227 | HIPAA Sec164.312(a)(2)(iv) Encryption/Decryption (provisional)

[FAIL]  TA05 exec-approval allow-always entry is keyed on basename only, not a full path scope
  .../deployment.yaml:30
  Maps to: goclaw#1216 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA09 sandbox fail-closed posture not declared (sandbox.on_unavailable must be "fail_closed")
  .../tenantguard-demo-488625596:0
  Maps to: goclaw#246 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA10 agent does not explicitly declare a per-agent config override (workspace restriction or sandbox config), risking silent inheritance of an undeclared global default
  .../deployment.yaml:40
  Maps to: goclaw#145 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA13 MCP/CLI bridge does not declare HMAC-signed context headers (bridge.hmac_enabled and bridge.context_headers_signed)
  .../tenantguard-demo-488625596:0
  Maps to: goclaw#91 | HIPAA Sec164.312(e)(1) Transmission Security (provisional)

[FAIL]  TA06 cron binding does not declare that its store layer captures/replays the human creator's sender identity at fire time
  .../deployment.yaml:35
  Maps to: goclaw#1129 | HIPAA Sec164.312(b) Audit Controls (provisional)

[FAIL]  TA07 sandbox container privilege is not hardened (root user by default, full host-env passthrough, tmpfs missing noexec/nosuid/nodev, or a dangerous Linux capability added)
  .../deployment.yaml:12
  Maps to: goclaw#1014 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA11 channel/session device identity is shared across channel_instances declaring different tenants
  .../deployment.yaml:54
  Maps to: goclaw#1064 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA11 channel/session device identity is shared across channel_instances declaring different tenants
  .../deployment.yaml:57
  Maps to: goclaw#1064 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA15 channel_instances entry does not declare reload_strategy: differential, so any single create/update/delete on that entry triggers a full stop/restart of every running channel instance across all tenants (no per-instance fingerprint/diff step). CAVEAT: a PASS trusts the deployment's own reload_strategy declaration -- TenantGuard cannot verify the real InstanceLoader actually performs a differential (fingerprint-diffed) reload rather than the destructive full rebuild, so a mismatched declaration would still scan clean
  .../deployment.yaml:54
  Maps to: goclaw#1147 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[FAIL]  TA15 channel_instances entry does not declare reload_strategy: differential, so any single create/update/delete on that entry triggers a full stop/restart of every running channel instance across all tenants (no per-instance fingerprint/diff step). CAVEAT: a PASS trusts the deployment's own reload_strategy declaration -- TenantGuard cannot verify the real InstanceLoader actually performs a differential (fingerprint-diffed) reload rather than the destructive full rebuild, so a mismatched declaration would still scan clean
  .../deployment.yaml:57
  Maps to: goclaw#1147 | HIPAA Sec164.312(a)(1) Access Control (provisional)

[PASS]  1 check(s) clear

Summary: 14 FAIL, 1 PASS
Findings map to confirmed open goclaw issues where applicable. HIPAA citations are provisional, see README.

O fixture incluído é deliberadamente ruidoso: ele existe para exercitar quase todas as regras de uma vez. TA08 (criptografia de armazenamento de credenciais) e TA14 (isolamento de perfil de recursos por agente) são verificações por entrada que só disparam contra entradas providers e resource_profiles na configuração verificada, e este fixture declara zero entradas de qualquer tipo, então ambas as regras não têm nada para avaliar e não produzem nenhuma descoberta, nem PASS nem FAIL. TA16 (SSRF de conexão de provedor) é o mesmo tipo de verificação por entrada contra entradas providers, então também não produz nada neste fixture. A única linha mostrada como aprovada, "1 check(s) clear," é TA12 (recuperação de proprietário/administrador), que os valores owner_ids e has_recovery_command do fixture são deliberadamente definidos para satisfazer. O código de saída é 1, já que há descobertas presentes; veja Referência da CLI para o contrato completo de códigos de saída.

Verifique uma implantação real e emita SARIF para varredura de código:

tenantguard scan --target ./deployment --format sarif --sarif-out tenantguard-report.sarif

Ou emita JSON simples, para um script ou agente que prefira analisar um array plano de descobertas em vez de um documento SARIF:

tenantguard scan --target ./deployment --format json

Recursos

O TenantGuard verifica a configuração de uma implantação de agentes de IA multi-locatário auto-hospedada contra 16 regras, cada uma derivada de um modo real e confirmado de falha de isolamento entre locatários. Cada regra é fail-closed: uma configuração não declarada ou ambígua é uma violação, não uma aprovação silenciosa.

Limites de isolamento entre locatários

Regra	O que ela detecta
TA01	Um mount de sandbox/workspace é uma violação a menos que seu caminho carregue o placeholder de escopo ${TENANT_ID} ou scoped_per_tenant seja explicitamente declarado como true. Mapeia para goclaw#1163.
TA03	O target_agent de um binding de cron deve pertencer ao locatário que declarou o binding; uma referência pendente ou entre locatários falha de forma fechada. Mapeia para goclaw#1217.
TA11	Sinaliza duas entradas channel_instances que compartilham o mesmo device_session_id mas declaram locatários diferentes (por exemplo, uma linha de dispositivo WhatsApp compartilhado). Mapeia para goclaw#1064/#1065.
TA14	Um perfil de recursos por agente (navegador/contêiner) é uma violação a menos que seu caminho contenha o placeholder ${TENANT_ID}. Mapeia para goclaw#778.
TA15	Sinaliza uma entrada channel_instances que não declara explicitamente reload_strategy: differential; um valor não declarado ou full ambos significam que qualquer create/update/delete único nessa entrada aciona uma parada/reinício destrutivo de cada instância de canal em execução em todos os locatários. Confia na própria declaração da implantação (o TenantGuard não pode verificar se o loader real realmente faz diff por fingerprint). Mapeia para goclaw#1147.

Exposição de rede e credenciais

Regra	O que ela detecta
TA02	Sinaliza uma URL de ferramenta MCP salva que aponta para um endereço privado/loopback/reservado, usando net.cidr_contains real em um IP literal ou resolvido por DNS (não correspondência de string), a menos que a implantação declare ambos validates_private e pins_resolved_ip (ou o host seja explicitamente permitido na allowlist). Documenta a limitação de DNS-rebinding/TOCTOU explicitamente. Mapeia para goclaw#1070.
TA04	Sinaliza uma ferramenta exec que nega leituras diretas de env-dump, mas não leituras indiretas (por exemplo, jq $ENV), e independentemente sinaliza qualquer ferramenta com allow_chain_exec: true, já que variáveis de ambiente de credenciais vazam para cada comando em uma cadeia de operador de shell. Mapeia para goclaw#1227 e goclaw#1033.
TA08	Uma configuração de provedor é uma violação a menos que declare um algoritmo de criptografia forte reconhecido (atualmente apenas aes-256-gcm) para tokens OAuth/credenciais armazenados. Mapeia para goclaw#65.
TA16	Sinaliza uma URL de conexão de provedor (por exemplo, litellm, bifrost) que aponta para um endereço privado/loopback/reservado, usando a mesma lógica baseada em net.cidr_contains que TA02 aplica a ferramentas MCP, a menos que a implantação declare ambos validates_private e pins_resolved_ip (ou o host seja explicitamente permitido na allowlist). Mapeia para goclaw#1430.

Endurecimento de execução e aprovação

Regra	O que ela detecta
TA05	Uma aprovação de execução "allow-always" baseada apenas no basename, não em um caminho completo, é uma violação, pois pode ser reutilizada contra um executável diferente que compartilha esse basename. Mapeia para goclaw#1216.
TA07	Sinaliza execução root por padrão, passagem completa do ambiente do host, mounts tmpfs sem noexec/nosuid/nodev, ou qualquer capability Linux perigosa adicionada (SETUID, SETGID, CHOWN, SYS_ADMIN, DAC_OVERRIDE, NET_ADMIN, SYS_PTRACE). Mapeia para goclaw#1014, #1015, #524.
TA09	Uma implantação deve declarar explicitamente sandbox.on_unavailable: fail_closed; um valor não declarado é tratado como violação, não como aprovação silenciosa. Mapeia para goclaw#246.

Identidade, auditoria e recuperação

Regra	O que ela detecta
TA06	Um binding de cron cuja configuração não declara captures_creator_identity é uma violação; sem isso, um job de contexto de grupo dispara sob uma identidade system em vez do criador humano real. Mapeia para goclaw#1129.
TA12	Verificação no nível da implantação: uma violação se owner_ids estiver vazio ou nenhum comando de recuperação/redefinição for declarado, arriscando bloqueio permanente do operador. Mapeia para goclaw#954.
TA13	Verificação no nível da implantação: uma violação se bridge_hmac_enabled ou bridge_context_headers_signed não for declarado como true; uma declaração ausente assume não assinado e falha, nunca passa silenciosamente. Mapeia para goclaw#91.
TA10	Proxy de melhor esforço e configuração estática: sinaliza um agente cuja entrada não declara explicitamente has_workspace_restriction_override ou has_sandbox_config_override. Mapeia para goclaw#145.

Outras capacidades verificadas:

• Saída SARIF 2.1.0 (--format sarif), válida por schema, com locais reais de byte/linha e mensagens, pronta para github/codeql-action/upload-sarif e varredura de código do GitHub.
• Saída JSON simples (--format json), uma alternativa leve de schema ao SARIF para um script ou agente que só quer resultados brutos de rule_id/status/file/line sem o modelo de objeto tool/run/rule/taxonomy do SARIF. Diferente do SARIF (que só relata FAIL como um "result"), o modo JSON inclui também todos os PASS, além de uma contagem de summary.fail/summary.pass. Disponível desde v0.2.0. Veja a nota em Referência da CLI.
• Citações HIPAA provisórias em cada descoberta (--control hipaa), mapeadas por regra, marcadas como provisórias (veja FAQ).
• Modo demo sem configuração (--demo) que verifica uma implantação sintética incluída, sem necessidade de configuração de destino.
• GitHub Action (action/action.yml) que instala uma versão fixada via go install e envia o relatório SARIF automaticamente.
• Modo servidor MCP (tenantguard mcp) que expõe o mesmo mecanismo de verificação como uma ferramenta que um agente de IA pode chamar diretamente via stdio, em vez de apenas por um humano digitando tenantguard scan. Disponível desde v0.2.0. Veja Servidor MCP (uso nativo por agente) abaixo.

Referência da CLI

O TenantGuard tem dois subcomandos: scan (a auditoria em si) e mcp (executa o mesmo mecanismo de verificação como um servidor MCP via stdio, veja Servidor MCP (uso nativo por agente)). Não há flag --help ou --version de nível superior; executar tenantguard sem argumentos, tenantguard --help, ou qualquer primeiro argumento diferente de scan ou mcp imprime as linhas de uso abaixo em stderr e sai com 2.

[!NOTE] Nota de versão: --format json e o subcomando mcp mostrado abaixo são enviados na v0.2.0 e posteriores, que é o que npm install -g tenantguard-cli (0.2.0), pip install tenantguard-cli (0.1.6, que baixa o binário v0.2.0) e go install .../cmd/tenantguard@v0.2.0 instalam. Versões anteriores (os pacotes npm 0.1.x e a tag Go v0.1.1) não os têm: --format json é ignorado lá e mcp não é reconhecido como subcomando.

usage: tenantguard scan [--target DIR | --demo] [--format terminal|sarif|json] [--control hipaa]
       tenantguard mcp

Saída de tenantguard scan --help:

Usage of scan:
  -control string
    	compliance framework to cite (hipaa)
  -demo
    	scan a bundled synthetic deployment instead of --target (zero setup)
  -format string
    	output format: terminal, sarif, or json (default "terminal")
  -sarif-out string
    	file to write SARIF output to when --format=sarif (default "tenantguard-report.sarif")
  -target string
    	path to the deployment config directory to scan

Códigos de saída (definidos em cmd/tenantguard/main.go):

Código	Significado
0	Verificação limpa, sem descobertas
1	Verificação executada com sucesso, descobertas presentes
2	Erro de verificação ou uso

Servidor MCP (uso nativo por agente)

[!NOTE] Disponível desde v0.2.0. O subcomando mcp é enviado nos releases npm, PyPI e go install listados em Instalação. Versões anteriores à v0.2.0 não o têm e imprimem um erro de uso se você tentar.

Tudo acima assume um humano digitando tenantguard scan em um terminal. O TenantGuard também roda como um servidor MCP, para que um agente de IA (um assistente de codificação, um agente de operações, qualquer coisa que fale o Model Context Protocol) possa chamar o mecanismo de verificação diretamente como uma chamada de ferramenta, em vez de invocar a CLI e analisar texto.

tenantguard mcp

Isso inicia um servidor MCP em stdio e bloqueia até o cliente desconectar, da mesma forma que qualquer outro servidor MCP baseado em stdio roda sob a supervisão de processo do seu cliente. Ele não aceita flags ou argumentos posicionais. Por baixo dos panos, é um adaptador de protocolo fino (internal/mcpserver) sobre exatamente o mesmo pipeline internal/collector -> internal/policy -> internal/compliance -> internal/report que o subcomando scan da CLI executa; não há lógica separada de avaliação de regras para manter em sincronia.

Ele expõe uma única ferramenta, scan, com três argumentos que espelham as próprias flags da CLI:

Argumento	Mapeia para	Notas
target	--target	Obrigatório. Caminho para o diretório de configuração de implantação a ser verificado.
format	--format	Opcional. json, sarif ou terminal. O padrão é json para MCP (a CLI em si usa terminal como padrão), já que um agente chamador quase sempre quer saída estruturada, não um relatório formatado para humanos.
control	--control	Opcional. Apenas hipaa é reconhecido hoje; um valor vazio também usa hipaa como padrão, alinhado com a CLI.

Para saída json e sarif, o resultado é retornado tanto como texto quanto como MCP StructuredContent, para que um cliente que queira ler campos diretamente (rule_id, status, file, line) não precise reanalisar o bloco de texto. Falhas no nível da ferramenta (um caminho de destino inválido, um erro de carregamento de política) retornam como um resultado de erro MCP normal, não uma falha no nível do protocolo, para que um agente chamador possa tratar "verificação falhou" da mesma forma que trata qualquer outra chamada de ferramenta com falha.

Para registrar o TenantGuard com um cliente compatível com MCP, como o Claude Desktop, adicione-o à configuração de servidores do cliente:

{
  "mcpServers": {
    "tenantguard": {
      "command": "tenantguard",
      "args": ["mcp"]
    }
  }
}

Isso pressupõe que tenantguard já esteja no seu PATH (veja Instalação). Se você o instalou em outro lugar, substitua "command" pelo caminho completo para o binário.

Antes disso, a única forma de executar uma verificação era um humano invocando a CLI diretamente. Com tenantguard mcp, um agente pode chamar scan como ferramenta, obter descobertas estruturadas e agir sobre elas na mesma sessão, sem que uma pessoa leia a saída do terminal e digite o próximo comando manualmente.

Como o TenantGuard se compara

Ferramenta	Foco	Ciente de agentes de IA multi-tenant	Saída SARIF	Número de regras	Maturidade do projeto
TenantGuard	Auditoria de configuração de isolamento de tenant para plataformas multi-agente auto-hospedadas	Sim, projetado especificamente para essa superfície	Sim, verificado (SARIF 2.1.0)	16, todas focadas em isolamento de tenant	Ativo no npm/PyPI (veja os selos acima); três releases com tags no GitHub (v0.1.0, v0.1.1, v0.2.0)
Checkov	Scanner de má configuração geral de IaC/nuvem (Terraform, CloudFormation, Kubernetes, Dockerfile e mais)	Não, o README não menciona plataformas de agentes de IA multi-tenant ou verificações de isolamento de tenant	Sim, verificado (-o sarif)	1.000+, políticas gerais de nuvem/IaC	8,9 mil estrelas no GitHub, estabelecido há muito tempo, mantido ativamente
Conftest	Ferramenta de referência para teste de políticas OPA/Rego para dados de configuração estruturados (mais de 18 formatos de entrada)	Não, é o harness genérico de teste Rego sobre o qual outras ferramentas constroem pacotes de políticas; sem pacote de regras de isolamento de tenant ou de agentes de IA	Sim, verificado (-o sarif, SARIF 2.1.0)	0 embutidas (um motor de teste de políticas, não um pacote de regras)	Projeto OPA de referência estabelecido, mantido ativamente
PolicyGuard	Scanner de má configuração AWS/Azure para Terraform/OpenTofu (Go + OPA/Rego, CLI Cobra, motor OPA em sandbox)	Não, escopo restrito a recursos AWS/Azure do Terraform/OpenTofu; sem menção a sistemas multi-tenant ou plataformas de agentes de IA	Sim, verificado (SARIF 2.1.0 com impressões digitais estáveis + tags CWE)	15+ verificações de recursos AWS/Azure	1 estrela, 2 forks, 4 releases (v0.3.1)
AgentShield	Scanner de segurança para agentes de IA (segredos, permissões, hooks, segurança de servidores MCP, revisão de configuração de agentes)	Não, escopo explícito para o diretório local .claude/ de um único usuário do Claude Code (ambiente de desenvolvimento de usuário único/equipe), não isolamento SaaS multi-tenant	Sim, verificado (--format sarif, SARIF 2.1.0)	102, em 5 categorias	Mais de 1.000 estrelas no GitHub, mantido ativamente (começou em um hackathon de fevereiro de 2026)

O TenantGuard troca amplitude por profundidade: 16 regras é uma fração das 1.000+ do Checkov, e o TenantGuard tem apenas três releases com tags, contra o histórico muito mais longo do Checkov, Conftest e PolicyGuard. O que o TenantGuard tem que nenhum dos outros tem é um pacote de regras projetado especificamente para isolamento entre tenants em implantações de agentes de IA auto-hospedadas, uma superfície que nenhum scanner genérico de IaC cobre e que até o AgentShield, o concorrente de domínio mais próximo, não alcança: ele audita a configuração local de um único desenvolvedor, não o isolamento entre tenants em uma implantação multi-tenant auto-hospedada. Esse é o nicho que o TenantGuard ataca, de forma estreita e proposital.

Benchmarks de precisão/revocação para o próprio conjunto de regras do TenantGuard contra fixtures rotulados ainda não foram publicados; onde um concorrente acima relata um número (ex.: precisão/revocação do PolicyGuard), os valores são citados do próprio README do projeto, não verificados de forma independente aqui.

O que é o TenantGuard e por que ele existe

O TenantGuard é um scanner de política-como-código de linha de comando, escrito em Go e construído sobre OPA/Rego, que audita a configuração de uma plataforma de agentes de IA multi-tenant auto-hospedada em busca de defeitos de isolamento de tenant: a classe de bug em que o agente, sandbox, job cron ou credencial de um tenant pode alcançar ou afetar outro tenant.

O TenantGuard existe porque uma plataforma real e confirmada de agentes de IA multi-tenant (goclaw) teve múltiplos problemas abertos e não resolvidos exatamente nessa categoria, incluindo um mount de sandbox não isolado por tenant, uma lacuna de autorização entre agentes, uma ferramenta exec que vaza segredos por um caminho indireto, um bypass de aprovação baseado em nome de arquivo em vez de um escopo real de caminho, e uma incompatibilidade de validação SSRF em URLs de ferramentas salvas e conexões de provedores de LLM. Nenhum scanner genérico de IaC existente (Checkov, Conftest, PolicyGuard) ou scanner de segurança de agentes de IA (AgentShield) verifica essa categoria específica de falha: isolamento entre tenants em uma implantação multi-agente auto-hospedada. O TenantGuard preenche essa lacuna com 16 regras fail-closed, cada uma rastreável a um problema real e citado.

O TenantGuard não é um scanner genérico de Terraform/Kubernetes e não substitui o Checkov ou o Conftest para má configuração geral de infraestrutura em nuvem. Ele é escopado especificamente para a superfície de isolamento de tenant em implantações de agentes multi-tenant auto-hospedadas.

FAQ

Como o TenantGuard é diferente de um scanner IaC genérico como Checkov ou Conftest? Checkov e Conftest verificam infraestrutura-como-código geral (Terraform, Kubernetes, CloudFormation e similares) para categorias amplas de má configuração. Nenhum deles inclui um pacote de regras para implantações de agentes de IA multi-tenant. As 16 regras do TenantGuard são projetadas especificamente para essa superfície: mounts de sandbox, vínculos cron/agente, registros de ferramentas MCP, conexões de provedores de LLM, aprovações de exec e identidade de canal/sessão, cada uma derivada de um defeito real e citado.

O TenantGuard substitui o OPA ou o Conftest? Não. As regras do TenantGuard são escritas em Rego e o TenantGuard inclui seu próprio caminho de avaliação; ele é um pacote de políticas e CLI de propósito específico, não um harness genérico de teste Rego. Se você precisa testar configuração estruturada arbitrária contra políticas Rego arbitrárias, o Conftest é a ferramenta geral certa. O TenantGuard é a ferramenta certa especificamente para verificações de isolamento de tenant em uma implantação multi-agente.

O que significa a citação HIPAA em cada descoberta? Cada descoberta é anotada com uma citação relacionada da Regra de Segurança HIPAA (ex.: Sec164.312(a)(1) Controle de Acesso) para ajudar a mapear uma descoberta técnica para um controle de conformidade que um revisor já possa acompanhar. Essas citações são marcadas como provisórias: elas indicam um mapeamento plausível entre o controle técnico e a seção HIPAA citada, não uma determinação legal ou de conformidade auditada. Trate-as como um ponto de partida para sua própria revisão de conformidade, não como um substituto para ela.

Um PASS no TA02 (SSRF) significa que a URL da ferramenta MCP está realmente segura contra DNS rebinding? Não totalmente. O TA02 usa contenção CIDR real contra um IP literal ou resolvido por DNS, não correspondência de strings, mas um PASS confia na declaração pins_resolved_ip/validates_private da própria implantação. O TenantGuard não pode verificar de forma independente se o validador real fixa o IP resolvido para a conexão real, então um risco de DNS-rebinding/TOCTOU persiste se essa declaração for imprecisa. Essa limitação está documentada diretamente na regra TA02.

Posso verificar uma implantação real em vez do demo incluído? Sim: tenantguard scan --target <path-to-deployment-config-dir>. --demo existe para que você veja a ferramenta rodando sem configuração antes de apontá-la para uma configuração real.

O TenantGuard produz saída que um pipeline de CI ou a verificação de código do GitHub pode consumir? Sim. --format sarif --sarif-out <file> produz um documento SARIF 2.1.0 válido por esquema com locais de resultados e mensagens reais. A GitHub Action incluída (action/action.yml) executa uma verificação e envia o relatório SARIF via github/codeql-action/upload-sarif em uma única etapa.

Por que o TenantGuard tem tanto --format sarif quanto --format json? O SARIF já não é saída estruturada? Sim, o SARIF é um formato real, padrão e analisável por máquina, e é a escolha certa para integração com CI/verificação de código. --format json existe para um consumidor diferente: um script ou agente que queira analisar rule_id/status/file/line diretamente, sem percorrer o modelo de objetos tool/run/rule/taxonomy do SARIF primeiro. Ele também relata cada PASS junto com cada FAIL, o que o SARIF deliberadamente não faz (os resultados do SARIF representam problemas encontrados, não uma lista de verificação completa), para que um chamador possa responder "o que você verificou" e não apenas "o que você sinalizou" a partir de um único documento. Nota: --format json está disponível desde a v0.2.0, veja a nota sob Referência da CLI.

O que significam os códigos de saída da CLI? 0 é uma verificação limpa sem descobertas, 1 significa que a verificação foi executada com sucesso e encontrou violações, e 2 é um erro de verificação ou uso (incluindo executar tenantguard sem subcomando, ou qualquer subcomando diferente de scan ou mcp).

Existe um pacote npm? Sim, npm install -g tenantguard-cli está ativo (atualmente 0.2.0) e é o caminho de instalação recomendado (renomeado do antigo tenantguard, que está obsoleto). Ele depende de um pacote binário de plataforma correspondente como um optionalDependency npm; todos os seis pacotes de plataforma estão ativos (macOS x64/arm64, Linux x64/arm64, Windows x64/arm64). Veja Instalação acima.

Existe um pacote PyPI? Sim, tenantguard-cli está ativo no PyPI (atualmente 0.1.6, que baixa o binário v0.2.0; código-fonte sob python/, construído e testado no CI). Versões até 0.1.2 inclusive tinham um bug de primeira execução que foi corrigido na 0.1.3 (veja Instalação acima); pip install tenantguard-cli agora funciona imediatamente.

Um agente de IA pode executar o TenantGuard diretamente, sem um humano digitando comandos de CLI? Sim, via tenantguard mcp, que inicia um servidor MCP em stdio expondo o motor de verificação como uma ferramenta scan. Veja Servidor MCP (uso nativo por agentes) acima para a configuração exata do cliente e argumentos da ferramenta, e para as versões que o incluem.

O TenantGuard é uma biblioteca que posso importar no meu próprio programa Go? Não, atualmente não. Tudo fora de cmd/tenantguard (o coletor, mapeamento de conformidade, fixture de demo, motor de políticas e formatação de relatórios) vive sob internal/, que as próprias ferramentas do Go tornam não importável de fora deste módulo. O TenantGuard é distribuído como um binário CLI e uma GitHub Action, não como um pacote Go importável.

Posso usar o TenantGuard em um produto comercial ou de código fechado? Sim. O TenantGuard é licenciado sob a Apache License 2.0, que permite uso comercial, modificação, uso privado e redistribuição, inclusive dentro de um produto proprietário ou SaaS, sujeito aos termos padrão de aviso e atribuição da licença (manter o aviso de direitos autorais e uma cópia da licença, e marcar quaisquer arquivos modificados). Ele vem sem garantia, conforme declarado na licença. Veja LICENÇA para os termos completos e autoritativos.

Contribuindo

Contribuições são bem-vindas. Consulte CONTRIBUTING.md para saber como adicionar uma nova regra; toda regra precisa de um fixture vulnerável e um limpo antes de ser publicada.

Licença

Apache License 2.0. Consulte LICENSE.