Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
wardn — isolamento delle credenziali per agenti AI. Gli agenti non vedono mai le vere chiavi API - garanzia strutturale, non politica. | Kitploit
Strumenti/GitHubGitHub/rohansx/wardn
Autenticazione e AutorizzazioneStrumenti di Crittografia/DecrittografiaSicurezza CloudDevSecOpsUtilità e FrameworkRilevamento SegretiGestione Identità e Accessi (IAM)Sicurezza della Supply ChainSicurezza delle API
GitHubrohansx/wardn

wardn

3633719 giorni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

isolamento delle credenziali per agenti AI. Gli agenti non vedono mai le vere chiavi API - garanzia strutturale, non politica.

Vedi Repository

wardn

Un firewall per le credenziali per agenti AI.

L'affermazione principale è strutturale, non di policy: gli agenti ricevono token segnaposto, mai chiavi API reali. La chiave reale attraversa un solo confine di rete — all'interno del proxy wardn, durante il percorso verso l'API upstream — e viene rimossa dalle risposte prima che raggiungano l'agente. Log, ambiente, finestre di contesto LLM, file temporanei e cronologia della shell contengono solo segnaposto.```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)

This is the load-bearing claim and it's defensible today against agent
compromise, prompt injection, log theft, and skill exfiltration.
Read [docs/THREAT-MODEL.md](https://github.com/rohansx/wardn/blob/main/docs/THREAT-MODEL.md) for the honest split
between what is covered and what isn't — including the tier where the
stronger "host compromise leaks nothing" claim becomes reachable.

The vault itself (encrypted at rest, passphrase-derived key) is a real
component and the reason the firewall can run on a single machine. The
upcoming [docs/HOSTED-TIER.md](https://github.com/rohansx/wardn/blob/main/docs/HOSTED-TIER.md) tier additionally
wraps the proxy in a confidential-compute enclave so even a fully
compromised VPS cannot read the key.

[![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)

## The Problem

Every AI agent framework today stores API keys in environment variables or
`.env` files. A compromised agent, malicious skill, commodity stealer, or
prompt injection exfiltrating `Authorization: Bearer sk-...` from an LLM
log gets full access to your credentials.```
~/.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

La soluzione: un firewall per le credenziali

wardn consegna agli agent una stringa segnaposto inutile e rimuove la chiave reale da ogni superficie raggiungibile. Le chiavi reali vengono iniettate a livello di rete — una singola giuntura — e rimosse dalle risposte prima che raggiungano l'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)

## Architettura```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

Come Funziona```

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)

## Demo

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

## Livelli di Fiducia, Onestamente

| Tier | Dove | Cosa garantisce |
|---|---|---|
| **Self-host (oggi)** | tuo laptop, tuo VPS, CI | Vault crittografato a riposo, protezione firewall contro gli agenti. **Non** difende contro root sull'host. |
| **Hosted (in arrivo)** | gestito da wardn o BYO-cloud | Enclave di calcolo confidenziale (Nitro / SEV-SNP) + attestazione remota + flusso di crittografia verso il proxy. Affermazione reale "il compromesso dell'host non rivela nulla". |

Il livello Self-host è la rivendicazione portante ed è disponibile oggi. Il livello Hosted
è il percorso di aggiornamento rigoroso: costa denaro e complessità operativa, e
il suo design è in [docs/HOSTED-TIER.md](https://github.com/rohansx/wardn/blob/main/docs/HOSTED-TIER.md). Inventario completo e onesto
di cosa è e non è coperto:

👉 **[docs/THREAT-MODEL.md](https://github.com/rohansx/wardn/blob/main/docs/THREAT-MODEL.md)** — tabella copre / non copre,
"nessun vault software elimina il compromesso dell'host" chiamato chiaramente, e
il percorso di aggiornamento.

## Install```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

Avvio Rapido```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

Ecco fatto. Ora Claude Code utilizza il server MCP di wardn per ottenere token segnaposto invece di leggere le chiavi reali dal tuo ambiente.

### Cosa succede dopo

1. Claude Code chiama `get_credential_ref` → ottiene `wdn_placeholder_a1b2...` (non la chiave reale)
2. L'agente invia la richiesta con il segnaposto attraverso il proxy wardn
3. Il proxy sostituisce il segnaposto con la chiave reale, inoltra all'API
4. Il proxy rimuove la chiave reale dalla risposta prima di restituirla all'agente

La chiave reale non entra mai nella memoria dell'agente, nei log o nella finestra di contesto dell'LLM.

## Dashboard locale
Scarica lo strumento