Påloggingsinformasjonsproxy
Dine agenter gjør API-kall.
De bør aldri holde nøklene.
Clavitor Proxy sitter mellom AI-agentene dine og API-ene de kaller. Påloggingsinformasjon injiseres på nettverkslaget — agenten ser, lagrer eller logger aldri den virkelige hemmeligheten. Én binærfil. Én miljøvariabel. Null kodeendringer.
Problemet du allerede har
Hemmeligheter i miljøvariabler
Agentene dine leser OPENAI_API_KEY fra miljøet. Den nøkkelen er synlig i /proc, i krasjlogger, i CI-logger, i hvert verktøy agenten påkaller. Én lekket logglinje, og nøkkelen er offentlig.
Hemmeligheter i agentminne
Selv om agenten henter nøkkelen ved kjøretid, holder den den i minnet for varigheten av prosessen. En kompromittert ferdighet, en promptinjeksjon, en debug-dump — nøkkelen er der for å bli tatt.
Ingen revisjon av hva som ble brukt
Når en API-nøkkel deles som en streng, er det ingen registrering av hvilken agent som brukte den, når, eller til hva. Hvis nøkkelen lekker, roterer du den og håper. Det finnes ingen revisjonsspor.
Problemene vi håper du ikke har
API-nøkler i kildekode
Hardkodet i en konfigurasjonsfil, committet til git, klonet av hver utvikler og CI-runner på teamet. Én offentlig fork, og den er på GitHubs hemmelige skanningsdashboard — eller verre, det er den ikke.
Påloggingsinformasjon i Slack
"Kan du sende meg Stripe-nøkkelen?" Limt inn i en DM, søkbar for alltid, eksportert i ethvert samsvarsarkiv. Slack er ikke et hvelv. Heller ikke e-post, Google Docs, eller en post-it på en skjerm.
.env-filer på hver bærbar PC
Tolv utviklere, tolv kopier av produksjonspåloggingsinformasjon i klartekstfiler som aldri roteres. Én stjålet bærbar PC, én ~/.bash_history-lekkasje, ett overdrevent hjelpsomt sikkerhetskopieringsverktøy — og du roterer hver nøkkel i selskapet kl. 02.00.
Fjern påloggingsinformasjon fra agenten helt.
Proxyen sitter mellom agenten og API-et. Agenten skriver en referanse — clavitor://OpenAI/key — der hemmeligheten skal gå. Proxyen løser den lokalt, injiserer den virkelige påloggingsinformasjonen i HTTPS-forespørselen, og videresender den. Agentens logger viser plassholderen. API-et mottar nøkkelen. Ingenting imellom lagrer den.
Ingen miljøvariabler. Ingen hemmeligheter i agentens minne. Ingen legitimasjon på kommandolinjen. Den virkelige nøkkelen kommer aldri inn i agentens miljø, minne eller logger, så agenten har ingenting å lime inn, skrive ut eller bli overtalt til å avsløre. Det dekker nøkler som rutes gjennom proxyen. Noen som kontrollerer maskinen kan likevel bruke proxyen eller lese nøkkelen fra proxyens minne med root, og en kompromittert agent kan likevel misbruke tilgangen den har fått. Omfang, ratebegrensninger og revisjon begrenser det.
# proxy-auth is the proxy's access token, the file beside the binary
$ export HTTPS_PROXY="http://clavitor:$(cat proxy-auth)@127.0.0.1:1983"
$ curl -H "Authorization: Bearer clavitor://OpenAI/key" \
https://api.openai.com/v1/chat/completions
# The proxy resolved the placeholder. The agent never saw sk-EXAMPLE_not_a_real_key.
# Neither did the logs, the crash dump, or the conversation history.Fungerer med enhver agent som gjør HTTPS-kall: Claude Code, Codex, OpenClaw, CrewAI, LangChain, egendefinerte skript. Sett én miljøvariabel, og agentens API-kall flyter gjennom proxyen. Ingen SDK, ingen plugin, ingen kodeendringer.
Hva som skjer under panseret
Dekrypterer lokalt, per forespørsel
Proxyen henter den krypterte påloggingsinformasjonen fra hvelvet og dekrypterer den på enheten. Klarteksten eksisterer i prosessminnet for én HTTP-forespørsel, deretter er den borte. Ingenting caches. Ingenting skrives til disk. Hver forespørsel dekrypteres ferskt.
Mapper felt til headere
Bearer-tokens, API-nøkler, Basic auth — proxyen mapper hvelvfeltetiketter til de riktige HTTP-headerne automatisk. Eller agenten velger det eksakte feltet med en clavitor://-referanse. Uansett lander påloggingsinformasjonen på riktig sted uten at agenten noen gang ser den.
Omfang, rate limits, revisjon
Hvelvet håndhever omfangsgrenser og rate limits. En agent som får tilgang til for mange forskjellige påloggingsinformasjoner blir automatisk låst. Hver tilgang logges. Inkluder en agent-ID i plassholderen — clavitor://agentid@Entry/field — for revisjonsspor per agent og rate limits gjennom en delt proxy.
Utrulling
Én binærfil. Sidecar til agenten. Ingen nettverksinfrastruktur-endringer.
Enkeltagent-vert
Last ned binærfilen, kjør clavitor-proxy init med registreringsbloben og nøkkelen, sett HTTPS_PROXY på agenten. Ferdig. Proxyen binder til 127.0.0.1:1983 (sidecar til én agent). Den binder ikke til noen annen adresse av seg selv: porten bærer et tilgangstoken i klartekst, så utenfor loopback nekter den å starte med mindre du setter CLAVITOR_PROXY_LISTEN til adressen og i tillegg oppretter en fil bare eieren har tilgang til, med navnet proxy-allow-private, ved siden av binærfilen, noe du bare gjør når den adressen er et betrodd privat nettverk (VPN eller Tailscale).
Multi-agent-vert
Hver agent får sin egen kopi av binærfilen med sin egen sidecar-konfigurasjonsfil. Hver kopi har sitt eget omfang, sine egne rate limits, sitt eget revisjonsspor. Agent A kan ikke se Agent Bs påloggingsinformasjon. Isolasjon etter design.
Hver påloggingsinformasjonsproxy som kjører i skyen — din eller andres — er et mål. Bryt proxyen, få tak i alle kunders påloggingsinformasjon. Det er ikke en teoretisk risiko. Det er forretningsmodellen til enhver påloggingsinformasjonsproxy-som-en-tjeneste.
Clavitors proxy kjører på infrastrukturen din. Dekrypterer lokalt. Legitimasjonen ligger i prosessminnet i løpet av én forespørsel. Ingen skytjeneste holder klartekstnøklene dine. Ingen API-endepunkt serverer hemmelighetene dine. Det finnes ingen skykopi av nøklene dine å kompromittere.
Dine agenter gjør allerede API-kall.
Hold dem i sitt eget spor.
Ditt hvelv, dine omfang, ditt revisjonsspor. Proxyen legger til et nettverkslagshåndhevelsespunkt med null kodeendringer til agenten.
"dybdeanalyse" is acceptable, not wrong enough to flag