How your AI uses your Stripe key without ever seeing it

Here's the uncomfortable trade every "AI agent" product makes: to do useful work, the agent needs your credentials. To charge a customer, it needs your Stripe key. To deploy, it needs your cloud token. The usual answer is to hand those secrets to the model and hope nothing leaks.

We didn't want to hope. So lodos is built so the leak is structurally impossible, and the build fails if anyone ever breaks that.

The problem with giving a model a secret

Once a plaintext secret enters a language model's context, you've lost control of it. It can surface in the transcript, in a tool call, in a log, in a summary the model writes later, or in an answer to a cleverly worded follow-up. Prompt injection, a malicious instruction hidden in a web page, an email, or a document the agent reads, turns that latent risk into an active exfiltration path.

The honest conclusion is that the model should never see the secret in the first place. Everything else is mitigation on top of a design flaw.

Referenced, injected, audited

lodos handles every credential through three stages.

1. Referenced

Your AI never works with a value. It works with a placeholder:

{{secrets.stripe.sk_live}}

That reference is all the model ever sees: in chat, in a workflow, in a task. It can reason about using the Stripe key without ever holding it.

2. Injected

When a job actually needs the credential, lodos decrypts it locally and passes it to an isolated subprocess as an environment variable, outside the model's view, and gone the moment the job finishes.

# The agent asked to run this; lodos resolved the reference and
# injected the real value into the subprocess environment only.
STRIPE_API_KEY={{secrets.stripe.sk_live}} ./charge-customer.sh

The model sees the line on the left. The subprocess gets the value on the right. The two never meet inside the transcript.

3. Audited

Every access appends to a tamper-evident HMAC chain. The log records that a secret was used, never which value. Field paths are opaque, and any attempt to alter the history breaks the chain.

Why we don't just trust a policy

It would be easy to write "the AI is configured not to reveal secrets" and move on. We think that's worth nothing without enforcement, so we built the guarantee into the release process.

A build-time invariant scan runs on every release and fails the build if any of these is ever violated:

• There is no tool, anywhere, that returns a plaintext secret value.
• There is no raw model-API provider, only embedded Claude Code with your own login.
• There is no eval, Function, vm or child_process on any rendering path.
• Unknown tools fail closed; they're never silently allowed.
• The agent runs with bash explicitly disallowed.
• No single grant can complete the "lethal trifecta" of private data + untrusted content + exfiltration.
• Workflows are declarative only; there is no code path to execute.

If a future commit adds a tool that hands the model a secret, the release simply doesn't ship.

What we refused, and what we shipped instead

The wall forced better designs, not fewer features:

We refused	We shipped instead
A raw model API the AI calls directly	Embedded Claude Code with your own login
Letting the AI run host commands (bash)	Runtime subprocess injection, secret-blind
eval() in workflows	Declarative YAML, no code path to execute
Image-generated decks (cloud egress)	Offline text-decks, zero network

Refusing to leak didn't remove capability. It focused it.

The takeaway

You can give an AI agent real, credentialed work without giving it your credentials. The secret stays encrypted on your machine, enters a subprocess only at the moment of use, and never crosses into the model's context.

That's the whole idea behind lodos: your AI sees your work, not your secrets. Read the full security architecture, or download lodos and give your agent a job instead of a key.