Your API Keys Never Enter the Agent Container
The short version
On KiwiClaw's Standard plan, the container your agent runs in never holds a provider API key. It holds a signed token that is only valid against KiwiClaw's LLM proxy, and the proxy holds the provider credentials. An agent that reads every file it can reach finds no Anthropic, OpenAI, or Moonshot key, because there isn't one to find.
Why this is the question worth asking
An AI agent with shell access is a program that reads files and runs commands on your instruction — and sometimes on someone else's. Prompt injection is the case that matters here: a web page, a README, or an email the agent reads can carry instructions the agent then follows. If the credentials that pay for your model calls sit on the same filesystem as the agent, then read a file and send it somewhere is a single tool call away.
That makes "where do the keys live" a more useful security question than "is there a sandbox". A sandbox limits where a compromised agent can go. Credential placement decides what it finds when it gets there.
How self-hosted agents usually hold credentials
Most self-hosted agent runtimes keep provider keys in a dotfile next to the agent — a .env, a JSON credential file, or environment variables in the agent's own process. That isn't carelessness. It is the only available design when the agent process is also the thing calling the provider API. The consequence is that the agent can read its own credentials, and any control trying to prevent that runs inside the process being controlled.
Some projects say so directly. Nous Research's Hermes Agent — an MIT-licensed personal agent, and a well-engineered one — documents the limit in its own source. The code in agent/file_safety.py that keeps the file-reading tool away from credential paths carries this comment:
This is NOT a security boundary. The terminal tool runs as the same OS user with shell access; the agent can still cat auth.json or cat ~/.hermes/.env and exfiltrate the file... Treat any user-visible framing around this as 'may help' rather than 'stops attackers.'
The project's SECURITY.md is equally plain: it describes Hermes as "a single-tenant personal agent" and states that "the only security boundary against an adversarial LLM is the operating system." We quote it because it is the clearest published statement of a property that holds for most self-hosted agent setups, not because it is unusual. Nous documents the design accurately; the design is the normal one.
Redaction does not close this gap either, and good projects know it. Log redaction protects against shoulder-surfing and screenshots. It does not stop a program that can base64-encode a file before printing it, and the agent is the thing choosing the command.
Quotations read from hermes-agent v0.20.0 at commit 01a1037 on 2026-08-05. File paths and defaults move between releases — check the current version before relying on any of this.
How KiwiClaw routes model calls instead
KiwiClaw separates the component that needs a provider key from the component that runs your agent.
- You never send us provider keys on the Standard plan. KiwiClaw holds pooled provider credentials, and they live in the LLM proxy — a separate service, on separate infrastructure from tenant containers.
- Your agent gets a per-tenant token instead. When the runtime is provisioned, the control plane mints an HS256-signed JWT carrying your tenant ID, account ID, and plan, with an expiry plus an issuer and audience that only KiwiClaw's proxy accepts. It is re-minted automatically before it lapses.
- The container's model config points at the proxy, with that token sitting where an API key would normally go.
- The proxy does the privileged part. It verifies the token, refuses suspended agents, atomically reserves account-wide managed usage, and only then attaches an internal provider credential and forwards the request.
// The model provider block inside a Standard-plan container
{
"baseUrl": "https://<kiwiclaw-llm-proxy>/v1/anthropic",
"apiKey": "${KIWICLAW_PROXY_TOKEN}"
}KIWICLAW_PROXY_TOKEN is the entire secret the container receives. If it leaks, it buys the holder metered calls against your own plan limits through our proxy, and nothing at all at Anthropic, OpenAI, or Moonshot. A leaked provider key, by contrast, is a blank cheque on your provider account until somebody notices.
What lives where
| Inside your agent container | In the KiwiClaw LLM proxy | |
|---|---|---|
| Provider API keys (Standard plan) | No | Yes — pooled, never sent to containers |
| Per-tenant proxy token | Yes, as an environment variable | Verified on every request |
| Model request and response bodies | Yes | Pass through, streamed |
| Usage and credit accounting | No | Enforced before the request is forwarded |
| Your files, skills, and browser profile | Yes | No |
If you bring your own keys, read this part
BYOK is the honest exception, and we would rather put it on this page than let you find it later.
The point of BYOK is to use your own provider account, your own rate limits, and your own billing relationship. That requires your agent to call the provider directly, which means your key is delivered into your container's runtime configuration. It is encrypted with AES-256-GCM in our database and decrypted only to build that configuration — but once it is in your container, it is within reach of the agent running there, exactly as in any self-hosted setup.
So the claim in this page's title is specific rather than universal. On the Standard plan the container never sees a provider key. On BYOK it does, by design, because that is what BYOK is. If you run BYOK, treat the key the way you would treat one handed to a program that reads untrusted input: scope it to a dedicated project, set a spend cap with the provider, and rotate it if you see activity you don't recognize. If you want the isolation property itself, the Standard plan is how you get it.
What this protects against, and what it doesn't
- Protects: an agent talked into reading and exfiltrating its own credentials finds a tenant-scoped proxy token, not a provider key.
- Protects: a compromised skill, MCP server, or dependency inside the container has the same reach as the agent — and there is no provider key on disk or in the environment for it to take.
- Protects: blast radius. A leaked tenant token spends metered capacity under your own caps and can be re-issued. It does not unlock a provider account.
- Doesn't protect: everything else in your container. Files, notes, browser sessions, and tokens for third-party services you connect are in there because your agent needs them.
- Doesn't protect: your prompts and data from reaching a model provider. Sending them is what running a model call is.
- Doesn't protect: the container from itself. Kernel-level isolation with gVisor, dropped capabilities, egress controls, and approval-gated execution are separate layers — see the security page for what each one covers and where the gaps are.
The honest caveat
No system is unhackable, and a vendor who tells you otherwise is selling. The claim on this page is narrower and checkable: on the Standard plan, the credential your agent could steal is not the credential that matters. That is a property of the architecture rather than a promise about our vigilance, which is exactly why it is worth building on.
For the rest of the picture: KiwiClaw is not SOC 2 certified, does not sign HIPAA BAAs, and does not claim your use is compliant with any particular regime. The security page lists the controls that are live today with the gaps set out beside them.
Frequently Asked Questions
Can my KiwiClaw agent read my provider API key?
On the Standard plan there is no provider key in the container to read — it holds a per-tenant token that is only valid against KiwiClaw's LLM proxy. On BYOK your own provider key is delivered into your container so the agent can call your provider account directly, so there the answer is yes, by design.
What happens if my agent's proxy token leaks?
It authenticates as your tenant to KiwiClaw's LLM proxy and does nothing else. The proxy verifies it on every request, refuses suspended agents, and atomically reserves account-wide managed usage before forwarding anything. Tokens carry an expiry and are re-minted automatically; contact us if you want one rotated immediately.
How is this different from just using environment variables?
The difference is what the secret unlocks. An environment variable holding a provider key is a working provider credential wherever it ends up. The token in a KiwiClaw container is only meaningful to our proxy, and only within your own plan limits.
Does KiwiClaw see my conversations?
On the Standard plan model requests pass through the LLM proxy, because that is where the provider credential is attached. Operational access is limited to what running the service requires, and the security page describes those controls and their limits. If you need a specific data-flow picture for a vendor review, ask us for one.
Doesn't this just mean I have to trust KiwiClaw instead?
Yes, and that is a fair way to frame it. Self-hosting means trusting your own machine's boundary and trusting the agent not to leak a key it can read. Managed hosting means trusting us with pooled provider credentials that never enter tenant containers. Neither option is free of trust; pick the failure mode you can live with.