Getting started with AI agent security: a 30-minute primer

You installed a coding agent last week. It read your repository, ran your tests, wrote a commit. Then the question arrives a day later: where did my API keys go while that happened?

That gap — using an agent before securing it — is normal. Every agent tutorial covers installation and prompting. Security is the chapter nobody writes. This primer is that chapter: a 30-minute pass over the things that break first, in the order that matters.

What you are actually protecting (10 minutes)

Start with an inventory, because you cannot secure what you cannot name. Walk your home directory with fresh eyes and write down everywhere a credential lives:

1. .env files — in your apps, CI configuration, and the agent’s own project.
2. Config files with tokens baked in: shell rc files, git credentials, tool configs like Claude settings, opencode.json, IDE extensions.
3. Service credentials in docs and shell history — connection strings, session keys, anything a quick search finds.

You do not need to move anything yet. You need a list. Most people finish that walk surprised at how many locations they had forgotten.

Where the agent can pick them up (10 minutes)

The agent is not a normal process. It reads your source and config, then sends what it learned to a third-party model API. Three paths matter:

1. Context. The agent reads .env or a config file, and the values end up inside its context window — out of your control.
2. Tool output echo. A command the agent runs prints an env var or connection string, and stdout lands in the conversation.
3. Outbound traffic. Your agent calls model APIs, and so do the tools written around it. Any request that carries a leaked key leaves your machine.

Prompt injection makes all three worse: a hostile instruction inside fetched content can tell the agent to print or send secrets on its own.

The minimum setup (10 minutes)

Four controls, cheapest first:

1. Inject secrets at the process boundary, not the prompt level. “Please do not print the key” is not a control. A credential broker resolves secrets from the store you already have — pass or Bitwarden — and injects them as environment variables only for the exact command that needs them. The agent sees the command’s output, sanitized of secret values, never the keys themselves.
2. Route tool HTTP traffic through a credential-injecting proxy. Services that take headers or query parameters can be handled per host: the agent talks to a local proxy, the proxy attaches the credential. Your keys never sit in the agent’s config or context.
3. Scan what leaves the machine. For LLM traffic, a DLP reverse proxy in front of an OpenAI-compatible endpoint checks outbound requests with keyword pre-filter, regex, and entropy scoring, and masks matches before they leave. The leak you cannot prevent is the leak you do not detect.
4. Assume leakage and audit anyway. Keep an append-only audit log of when credentials were injected, which hosts were proxied, and what was redacted. Agents leak into session databases and logs; a scrub pass over those files, dry-run first, finds what a normal grep would miss.

What this pass is not

It is not a threat model, and it is not compliance. It is the minimum that stops the common cases: keys in context, keys in tool output, keys in outbound requests. A primer you actually finish beats a framework you postpone.

One implementation of this pattern is trustless, an MIT-licensed credential broker CLI for AI agents at https://github.com/ikkun1222/trustless — one Go module, one static binary, 321 race-detector-clean tests, cosign-signed releases, and it reads the pass or Bitwarden store you already have. The command reference lives at https://trustless-security.com/docs/commands/.

When you look at your own setup, which of the three paths — context, tool output, or outbound traffic — do you think is the one you are leaking through today?