Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Ferramentas/GitHubGitHub/rohansx/wardn
Autenticação e AutorizaçãoFerramentas de Criptografia/DescriptografiaSegurança na NuvemDevSecOpsUtilitários e FrameworksDetecção de SegredosGerenciamento de Identidade e Acesso (IAM)Segurança da Cadeia de SuprimentosSegurança de API
GitHubrohansx/wardn

wardn

36317há 21h 47mRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

isolamento de credenciais para agentes de IA. Os agentes nunca veem chaves de API reais - garantia estrutural, não política.

Ver Repositório

wardn

Um firewall de credenciais para agentes de IA.

A alegação principal é estrutural, não política: os agentes recebem tokens de espaço reservado, nunca chaves de API reais. A chave real cruza apenas uma costura de rede — dentro do proxy wardn, a caminho da API upstream — e é removida das respostas antes que cheguem ao agente. Logs, ambiente, janelas de contexto de LLM, arquivos temporários e histórico de shell contêm apenas espaços reservados.```text agent process OPENAI_KEY=wdn_placeholder_a1b2c3d4e5f6g7h8 (useless) agent logs Authorization: Bearer wdn_placeholder_a1b2... (useless) LLM context wdn_placeholder_a1b2c3d4e5f6g7h8 (useless) wardn proxy injects the real key in-flight, single seam (deleted on response) ~/.vibeguard/vault.enc AES-256-GCM(Argon2id(passphrase)) (encrypted at rest)

Esta é a afirmação principal e é defensável hoje contra comprometimento de agente, injeção de prompt, roubo de logs e exfiltração de habilidades.
Leia [docs/THREAT-MODEL.md](https://github.com/rohansx/wardn/blob/main/docs/THREAT-MODEL.md) para a divisão honesta entre o que é coberto e o que não é — incluindo o nível onde a afirmação mais forte de "comprometimento do host não vaza nada" se torna alcançável.

O próprio cofre (criptografado em repouso, chave derivada de senha) é um componente real e a razão pela qual o firewall pode ser executado em uma única máquina. O próximo nível [docs/HOSTED-TIER.md](https://github.com/rohansx/wardn/blob/main/docs/HOSTED-TIER.md) adicionalmente envolve o proxy em um enclave de computação confidencial para que mesmo um VPS totalmente comprometido não possa ler a chave.

[![Crates.io](https://img.shields.io/crates/v/wardn.svg)](https://crates.io/crates/wardn)
[![License](https://img.shields.io/crates/l/wardn.svg)](LICENSE)

## O Problema

Todo framework de agente de IA hoje armazena chaves de API em variáveis de ambiente ou arquivos `.env`. Um agente comprometido, habilidade maliciosa, ladrão comum ou injeção de prompt exfiltrado `Authorization: Bearer sk-...` de um log de LLM obtém acesso total às suas credenciais.```
~/.env              → OPENAI_KEY=sk-proj-real-key      # plaintext, readable by anyone
agent context       → "Use OPENAI_KEY=sk-proj-real-key" # leaked into LLM context window
agent logs          → Authorization: Bearer sk-proj-... # sitting in log files

A Solução: Um Firewall de Credenciais

wardn entrega aos agentes uma string de placeholder inútil e remove a chave real de toda superfície que pode alcançar. As chaves reais são injetadas na camada de rede — uma única costura — e removidas das respostas antes de chegarem ao agente.``` agent environment → OPENAI_KEY=wdn_placeholder_a1b2c3d4e5f6g7h8 (useless) wardn vault → OPENAI_KEY=sk-proj-real-key (encrypted at rest) upstream request → Authorization: Bearer sk-proj-real-key (network transit only) upstream response → ...real keys stripped, placeholders returned... (re-injected on the way back) agent logs → Authorization: Bearer wdn_placeholder_a1b2... (useless) LLM context window → wdn_placeholder_a1b2c3d4e5f6g7h8 (useless)

## Arquitetura```mermaid
flowchart TB
    subgraph Agent["AI Agent Process"]
        A1["Agent Code"]
        A2["ENV: OPENAI_KEY=wdn_placeholder_a1b2..."]
    end

    subgraph Wardn["wardn daemon · localhost:7777"]
        direction TB
        P["HTTP Proxy"]
        MCP["MCP Server\n(stdio)"]

        subgraph Pipeline["Request Pipeline"]
            direction LR
            S1["Identify\nAgent"] --> S2["Resolve\nPlaceholder"] --> S3["Check\nAuth"] --> S4["Rate\nLimit"] --> S5["Inject\nReal Key"]
        end

        subgraph ResponsePipeline["Response Pipeline"]
            direction RL
            R1["Strip Real\nKeys"] --> R2["Replace with\nPlaceholders"]
        end

        subgraph Vault["Encrypted Vault"]
            V1["AES-256-GCM"]
            V2["Argon2id KDF"]
            V3["Placeholder Map\nper agent × credential"]
        end
    end

    subgraph External["External APIs"]
        E1["api.openai.com"]
        E2["api.anthropic.com"]
        E3["..."]
    end

    A1 -- "placeholder token\nin headers/body" --> P
    A1 -. "MCP: get_credential_ref\nlist_credentials\ncheck_rate_limit" .-> MCP
    MCP -. "placeholder token\n(never real keys)" .-> A1
    P --> Pipeline
    Pipeline --> External
    External --> ResponsePipeline
    ResponsePipeline -- "response with\nplaceholders only" --> A1
    Pipeline <--> Vault
    ResponsePipeline <--> Vault

    style Agent fill:#1a1a2e,stroke:#e94560,color:#fff
    style Wardn fill:#0f3460,stroke:#16213e,color:#fff
    style Pipeline fill:#16213e,stroke:#e94560,color:#fff
    style ResponsePipeline fill:#16213e,stroke:#e94560,color:#fff
    style Vault fill:#1a1a2e,stroke:#00d2ff,color:#fff
    style External fill:#0a0a0a,stroke:#533483,color:#fff

Como Funciona```

Agent sends request with placeholder in Authorization header │ ▼ ┌─────────────────────────┐ │ wardn proxy │ │ localhost:7777 │ │ │ │ 1. Identify agent │ │ 2. Resolve placeholder │ │ 3. Check authorization │ │ 4. Check rate limit │ │ 5. Inject real key │ │ 6. Forward request │ │ 7. Strip key from resp │ │ 8. Return to agent │ └─────────────────────────┘ │ ▼ External API (only place real key exists in transit)

## Demonstração

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/12823/1fa6109ffd855ec98c173c5edd2d7ee77f6b0c918a3cdecb1ea5fbfe8326161d.gif" alt="wardn demonstração" width="800">
</p>

## Níveis de Confiança, Honestos

| Nível | Onde | O que garante |
|---|---|---|
| **Auto-hospedado (hoje)** | seu laptop, seu VPS, CI | Cofre criptografado em repouso, alegação de firewall contra agentes. **Não** defende contra root no host. |
| **Hospedado (em breve)** | gerenciado pela wardn ou BYO-cloud | Enclave de computação confidencial (Nitro / SEV-SNP) + atestação remota + fluxo de criptografia para o proxy. Alegação real de "comprometimento do host não vaza nada". |

O nível auto-hospedado é a alegação principal e é enviado hoje. O nível hospedado é o caminho de atualização estrito: custa dinheiro e complexidade operacional, e seu design está em [docs/HOSTED-TIER.md](https://github.com/rohansx/wardn/blob/main/docs/HOSTED-TIER.md). Inventário completo e honesto do que é e não é coberto:

👉 **[docs/THREAT-MODEL.md](https://github.com/rohansx/wardn/blob/main/docs/THREAT-MODEL.md)** — tabela de cobertura / não cobertura, "nenhum cofre de software elimina comprometimento do host" explicitamente destacado, e o caminho de atualização.

## Instalação```bash
# Prebuilt binary (Linux/macOS, amd64/arm64), checksum-verified
curl -sSf https://raw.githubusercontent.com/rohansx/wardn/main/install.sh | sh

# or from crates.io
cargo install wardn

# or Homebrew, once the tap is published (see Formula/wardn.rb)
brew install rohansx/wardn/wardn

Início Rápido```bash

Create an encrypted vault and store your keys

wardn vault create wardn vault set OPENAI_KEY wardn vault set ANTHROPIC_KEY

Set up Claude Code integration (one command)

wardn setup claude-code

Assim é. O Claude Code agora utiliza o servidor MCP do wardn para obter tokens de espaço reservado em vez de ler as chaves reais do seu ambiente.

### O que acontece a seguir

1. O Claude Code chama `get_credential_ref` → obtém `wdn_placeholder_a1b2...` (não a chave real)
2. O agente envia a requisição com o espaço reservado através do proxy wardn
3. O proxy troca o espaço reservado pela chave real, encaminha para a API
4. O proxy remove a chave real da resposta antes de devolvê-la ao agente

A chave real nunca entra na memória, logs ou contexto do LLM do agente.

## Painel Local
Baixar ferramenta