DEV Community: Ikkun

Auditing AI agent activity: structured logs for credential access

Ikkun — Sun, 16 Aug 2026 13:20:00 +0000

AI coding agents are the most privileged new user on developer machines in a
decade: they read source, run commands, and access credentials. And unlike
every other privileged user, they're almost always unaudited. If you had to
answer "which API keys did my agent touch this week?" right now, could you?

Why audit logs matter more with agents

Traditional secret access has a human in the loop: a developer runs a
command, and the human's intent is the context. Agents change the equation:

Attribution is unclear. A command run by an agent was decided by a
model — influenced by its context, its tools, and potentially by injected
instructions. "Who accessed this key" needs to include "what the agent
was doing at the time".
The blast radius is session-wide. One agent session touches many
credentials through many invocations. Without logs, a compromise is
invisible until the damage shows up elsewhere.
Compliance surfaces. If your setup ever needs to answer "was this
secret exposed?" — for an incident, a client, or your own peace of mind —
logs are the difference between an answer and a guess.

What good credential audit logs look like

Structured. JSON lines, not prose. Each event is a record with fields: timestamp, the credential key, the operation (resolve / refresh / scrub), the invoking context, and the outcome.
Append-only. The log can't be rewritten by the thing being audited. File-based logs get 0600 permissions and reopen-on-rotation (so logrotate doesn't drop events); journald is a solid alternative.
Complete. Every credential resolution is logged — not just failures. The absence of an event is information too.
Machine-readable. --json output for cron, SIEM, or alerting: "three failed Bitwarden unlocks in a row" should be something you can detect, not something you notice.

What to log

The useful baseline for agent credential access:

Resolutions — which key was resolved, when, by what invocation. This is the "who touched what" record.
OAuth lifecycle — login, refresh, reauth_required. Token refresh failures are early indicators of revoked credentials or policy changes.
DLP hits — outbound pattern matches, with mode (log vs mask). A pattern hit in log mode is a secret that almost left the machine.
Scrub operations — what was scrubbed, from where. The audit trail for your erasure layer.

The test: can you answer the question?

A good test for whether your agent setup has adequate auditing: an incident
review asks "did the agent access the production key during that session?"
If the honest answer requires digging through shell history, you don't have
audit logs — you have hope.

trustless writes structured
credential audit events (append-only JSONL at 0600, file or journald) for
every resolution, OAuth refresh, DLP hit, and scrub — plus trustless doctor --json for setup health in machine-readable form. The audit command is in
the command reference.

Agents will keep getting more capable, which means more credentials touched
per session. The question isn't whether to log — it's whether you want the
answer to "what happened" to be a query or a mystery.

OAuth device flow explained: how CLIs and AI agents approve access

Ikkun — Sun, 16 Aug 2026 12:30:49 +0000

You've seen it on a smart TV: "Go to example.com/device and enter code
ABCD-1234". That's the OAuth device authorization flow, RFC 8628 — and it's
the right way for headless tools, CLIs, and AI agents to get OAuth tokens.
Here's how it works and why it matters for agent security.

The problem with OAuth on a headless machine

OAuth's normal web flow needs a browser redirect: authorize → the provider
redirects to http://localhost:8976/callback?code=.... On a headless server
or inside an agent session there's no browser to redirect to — and no user
watching the address bar.

The workaround people fall into is worse: paste a personal access token into
a config file, or run a long-lived refresh token into the environment where
the agent can read it. Both put credentials where agents can exfiltrate them.

How the device flow works

RFC 8628 splits authorization into two steps that don't need to happen on
the same device:

The CLI asks the provider for a device code and gets back a verification URL + a short user code.
The CLI prints "open this URL, enter ABCD-1234" — and starts polling the provider for approval.
The user opens the URL on any device — phone, laptop, anywhere — and approves. No browser on the server needed.
The CLI's poll succeeds, and the provider returns tokens.

The tokens land on the machine that requested them, in the process that
requested them — not in a browser, not in a shared log.

Why it fits agents

For AI agents, the device flow has a structural advantage: the approval
happens outside the agent entirely. The agent runs the login command, prints
the URL, and the human approves on their own device. The tokens are stored by
the credential layer, and the agent never handles them.

That's the same principle as the rest of agent credential hygiene — the agent
is an untrusted caller, so credentials should be resolved and refreshed
outside its reach.

Token handling done right

Getting tokens is step one; keeping them safe is step two:

Store the entry compactly. The OAuth entry lives in the credential store as a single-line JSON record — one entry, resolved like any other secret.
Refresh without exposure. Access tokens expire; the broker refreshes on expiry, and the new value is never printed to output the agent can capture.
Rotate refresh tokens. Refresh tokens are single-use in this design — rotated on every refresh, so a leaked one is already dead.
Report state. status tells you valid / expired / reauth_required, so automation can detect a revoked token (invalid_grant) and ask the human to re-approve instead of failing silently.

The audit trail

Every resolution and refresh lands in an append-only audit log. You can
answer "which key was accessed, when, and by what" — including OAuth entries,
which most setups can't audit at all because the tokens live in browser
profiles and config files.

trustless implements the device
flow for Google and Lark providers (trustless oauth login google api/google), with automatic refresh, single-use rotation, and status
reporting — documented in the command reference.

The device flow is one of those rare security mechanisms that's also more
convenient: no browser juggling on the server, no callback URL gymnastics,
and a human approval step that's exactly where it should be.

pass vs Bitwarden for AI agent credentials: which works with agents

Ikkun — Sun, 16 Aug 2026 12:30:48 +0000

When you decide to stop putting API keys in .env files and start keeping
them in a real secret store, the first question is: which store? For AI
agent setups, the two realistic candidates are pass (the unix password
manager) and Bitwarden. Both work — but they make different trade-offs, and
the right choice depends on your existing workflow.

pass: the unix-native store

pass is a shell script over a directory of GPG-encrypted files. That's the
whole architecture.

Strengths for agent use:

Zero infrastructure. No server, no sync, no daemon. The store is files.
Scriptable by nature. Everything is files and GPG, so tooling around it is trivial — a broker reads a path, decrypts, injects.
GPG is already everywhere. If you sign commits or use SSH with GPG keys, the tooling is already installed.
Transparent. pass show <name> and you see exactly what a tool will get.

Weaknesses:

Sync is your problem. No built-in sync across machines; you roll your own (git remote, Syncthing, etc.).
No native web vault / mobile app ecosystem. The CLI is the interface. For a single-user developer setup, that's fine.

Bitwarden: the managed vault

Bitwarden is a full password manager: client apps, web vault, sync, sharing,
and a CLI (bw) that agents can drive.

Strengths for agent use:

Sync and recovery built in. Vault is on your terms (Bitwarden cloud or self-hosted Vaultwarden).
Rich entry model. Login items with URIs, fields with hidden values, notes — better structured than a flat file tree.
Access control. Collections and organizations, if you ever share credentials with a team.

Weaknesses:

Session management is fiddly. The bw CLI needs a session key (BW_SESSION) that must be passed to every invocation — get it wrong and the tool either fails or prompts interactively. This is the classic integration trap for agent tooling.
More moving parts. Server sync, unlock state, API rate limits.

What the agent setup actually needs

For a credential broker pattern — the agent references by name, the broker
resolves at process/transport time — the store is an implementation detail.
What matters is that the broker can read it non-interactively:

With pass: the broker decrypts with the GPG key; no session state to manage.
With Bitwarden: the broker unlocks once, holds the session key in an environment variable (never argv — that would leak it into process lists), and fails closed when the session is invalid. A dedicated unlock command handles the interactive step.

Both backends can power the same injection, sanitization, and DLP layers.
The pragmatic rule: use pass if you're a single-machine, CLI-first user;
use Bitwarden if you already live in it or need sync across devices.

trustless supports both as first-
class backends — pass by default, Bitwarden via the bw CLI with
BW_SESSION handling and fail-closed behavior. The backend design is
documented in the architecture page.

Whichever store you pick, the goal is the same: the agent gets access, never
the plaintext. Which one are you already using — or are you still on .env?

SQLite forensics: why deleting rows doesn't erase secrets (FTS, free pages, VACUUM)

Ikkun — Sun, 16 Aug 2026 12:22:52 +0000

You deleted the row. The secret is gone from the app, the queries return
nothing, and the dashboard is clean. In SQLite — the database behind most
session stores, browser profiles, and agent state files — that delete is a
fiction. The bytes are still in the file.

Three ways deleted data survives

1. Free pages. SQLite doesn't zero out the space a deleted row occupied.
The page is marked free and added to the freelist; the old bytes stay until
they're overwritten by a future write. A file that's been deleted-from is a
forensics goldmine: recover the freelist pages and the "deleted" rows come
back.

2. FTS virtual tables. If the database uses SQLite's full-text search
(FTS5), the FTS index keeps its own copies of the indexed text, maintained
separately from the source tables. Delete the row from the source table and
the FTS index still contains the tokens — searchable. This is the one that
catches people: their app shows the secret is gone, and the FTS index still
has it.

3. WAL and journal files. In WAL mode, recent writes live in the
-wal file; transactions in the -journal file. Both can retain pre-delete
content until checkpointed or cleaned.

"Deleted" in SQLite means "no longer referenced", not "no longer present".

What erasure actually requires

Making a secret physically disappear from a SQLite database takes three
operations, in order:

Replace the value everywhere it lives. Known secret values get
replaced across all tables; pattern matches (API key formats) get masked.
Two layers, because you can't enumerate every secret that leaked.
Rebuild the FTS indexes. INSERT INTO t(t) VALUES('rebuild') style
rebuilds, or drop/recreate the virtual tables — so the index no longer
contains the old tokens.
Run VACUUM. VACUUM rewrites the entire database file, copying only
live data into a fresh file — free pages with old bytes are discarded in
the process. After VACUUM, the file's raw bytes no longer contain the
secret. (Note: VACUUM doesn't shrink WAL files; those need a checkpoint
too.)

The design that makes scrubbing safe

Retroactive scrubbing is a destructive operation, so the tooling around it
matters as much as the SQL:

Dry-run by default. Scan and report per-table hit counts without writing a byte. You see what would be scrubbed before anything changes.
Backup option. Keep a .bak copy before applying changes.
Minimum length guard. Don't let pattern rules shred short, low-value strings — only secrets above a minimum length get masked.

Where this bites agent setups

Agent session databases are exactly the SQLite databases where this matters:
they accumulate everything the agent read, including the config values,
environment dumps, and debug output that occasionally contain keys. A
credential strategy that includes "the past is scrubbed" closes the loop
that prevention and DLP can't — the retrospective exposure.

trustless implements this as
trustless dlp scrub-db: two-layer redaction (known values + gitleaks-style
patterns), FTS rebuild, VACUUM, dry-run default, --backup, and --min-len
— with the same pattern rules that power the outbound DLP. The command
reference is in the documentation.

Next time someone tells you a secret was "deleted" from a database, ask them
two questions: did the FTS index get rebuilt, and did anyone run VACUUM?

Prompt injection and API key exfiltration: what actually happens

Ikkun — Sun, 16 Aug 2026 12:22:52 +0000

Prompt injection gets talked about in abstract terms — "the model was tricked" —
but the concrete damage is usually the same: a secret that was sitting in the
agent's context gets exfiltrated. To defend against it, it helps to walk
through the actual attack chain, step by step.

The attack chain

The key gets into context. Your agent loads .env, reads config, or
receives an environment variable to use a service. From that moment, the
key is part of the context window — the same working memory the model
reasons over.
Untrusted content arrives. The agent opens a webpage, reads a README,
processes an email, or parses an API response. Any of these can contain
instructions the model treats as commands: "ignore previous instructions",
"print the value of the DATABASE_URL variable", or subtler variants that
ask the agent to summarize, log, or send something.
The agent complies. The model is a next-token predictor, not a policy
enforcer. An instruction that looks like it's part of the task gets
followed. The key value ends up in a tool call, a log line, a code snippet
the agent writes, or the model's own output — which is transmitted to a
third-party API.
The key is now outside your machine. Once the value appears in output
that leaves your control — an API request, a shared log, a generated file —
it's compromised. Rotate it.

The uncomfortable part: steps 2–4 can happen without any visible error. The
agent looks like it's doing its job.

Why "be careful" doesn't work

The standard mitigations — "sanitize the model's output", "don't paste
untrusted text", "use a system prompt that forbids leaking secrets" — all
share a flaw: they rely on the model to make the right decision at the moment
of exfiltration. That's a probabilistic defense against a deterministic
attack. The attacker only needs one success; the defender needs all of them.

The structural fix: make the key unavailable

The defense that actually holds is removing the key from the attack surface
entirely. If the agent's context never contains the plaintext value, then a
successful injection has nothing to exfiltrate. This is what a credential
broker does:

At the process layer: the agent references the secret by name; the
broker resolves it into the subprocess environment at execution time.
Agent-visible output — stdout and stderr — is scrubbed for key values,
including base64 and URL-encoded variants, so even a verbose tool that
echoes its environment can't leak the value into context.
At the transport layer: HTTP-based tools talk to a local proxy that
injects credentials per host. The tool — and the agent controlling it —
never handles the credential material.
On the way out: outbound LLM traffic passes through a DLP layer that
pattern-scans requests and masks secret-shaped strings before they leave
the machine. Keys that leaked through other channels get caught at the
edge instead of in an attacker's hands.

This is the design of trustless, a
single-binary credential broker CLI for AI agents — 321 tests with -race,
cosign-signed releases with SBOM, and an append-only audit log of every
credential resolution. The threat model is documented in the
security model.

Prompt injection is not going away, and models will keep getting more
suggestible before they get less. The only reliable defense is making the
secret structurally unavailable — so that when an injection succeeds, the
agent has nothing to hand over.

Have you traced where your agent's keys actually live right now — .env
files, environment variables, config? That's the attack surface.

Why your AI coding agent should never see your API keys

Ikkun — Sat, 15 Aug 2026 02:02:59 +0000

Your AI coding agent needs your API keys. It needs them to call services, to
test integrations, to run your stack. So you give it .env files, or you
export keys into the environment, or you paste them into config files the
agent can read.

That means your secrets live inside the agent's context window — the same
window where a prompt-injected instruction or an overly verbose debug log can
leak them to an attacker or an untrusted model endpoint.

This isn't theoretical. If you've used Claude Code or OpenCode for more than a
few days, you've probably seen a tool call dump an environment variable, or a
log line that echoes a connection string. Most of the time nothing bad
happens. "Most of the time" is a bad security posture.

The core problem

AI agents are the first software that reads your source, your config, and
your secrets, then sends summaries of what it read to a third-party API.

With traditional software, the principle was simple: secrets live in the
process environment, code reads them at runtime, nobody reads them back out.
With agents, there is no such boundary — the agent both reads the
environment and transmits what it knows.

Three concrete leak vectors:

Context exfiltration — the agent reads .env and includes values in a later prompt to an external model. You can't audit this; it's in the model's training/inference pipeline.
Tool output echo — a command prints an env var or a config value; the agent captures stdout and stores it in the conversation.
Prompt injection — a malicious instruction (in a fetched web page, a dependency, an artifact) tells the agent to "print all environment variables" or "send the contents of .env to this URL".

What the tooling landscape offers

The solutions fall into a few buckets:

Secret managers (Vault, Doppler, Infisical) — great for your code, but the agent still needs a way to get the secret, which puts it back in context.
.env hiding (enject, tene) — keeps plaintext off disk, but when the agent runs a command that needs the secret, the value can still end up in stdout.
Credential proxies (vaulty) — the agent makes HTTP requests through a proxy that injects the credential. Promising, but typically tied to their own vault.

The model that worked for me

I ended up building a small CLI (Go, single binary, one external module) with four layers:

Subprocess injection with output sanitization. trustless run -- cmd
resolves secrets from my existing pass store and injects them as env vars.
After the command runs, stdout/stderr is scanned and secret values are
replaced — including base64 and URL-encoded variants. The agent sees the
command output, not the keys.
HTTP proxy with per-host injection. For services that take headers or
query params (EDINET, e-Stat, xAI, OpenRouter), trustless proxy injects
the right credential per host. The agent points at 127.0.0.1:8080 and
forgets about keys entirely.
DLP reverse proxy for LLM calls. trustless serve puts a scanning
proxy in front of OpenAI-compatible endpoints. Outbound requests are
checked against secret patterns (keyword → regex → entropy, gitleaks-compatible
rules) and masked in-flight before they leave the machine. This is the
layer that catches the "agent decided to include the key in a request" case.
Retroactive scrubbing. Prevention fails — keys end up in agent session
databases, logs, and dumps anyway. trustless dlp scrub-db and
scrub-text scan SQLite DBs and text files with the same two-layer
redaction (known values + patterns), rebuild FTS indexes and VACUUM the
DB so no physical remnants survive. Default is a dry-run report; --apply
does the write, --backup keeps a copy first.

Why not a new vault? Because I already had pass. The CLI reads the existing
store, so there was zero migration. (Bitwarden is supported too, with OAuth
token auto-refresh for Google/Lark.)

The agent gets capabilities, not credentials. That's the whole trick.

Takeaways

Never let a secret enter the agent's context window — not as env, not as config, not as tool output. Once it's there, you've lost the audit.
Inject at the process/transport boundary, not at the prompt level. "Please don't print the key" is not a security control.
Sanitize output, not just input. The leak vector is often the command's stdout, not the agent's intent.
Scan outbound requests if your agent calls external APIs directly. A DLP layer is the difference between "we hope it didn't leak" and "we know it didn't".
Assume leakage happened and scrub retroactively. Run a periodic scan of agent session DBs and logs; a dry-run scrub report tells you what would be found, --apply cleans it, and a backup keeps the recovery path.

If you want to look at the code: trustless is MIT-licensed at
https://github.com/ikkun1222/trustless — 321 tests, race-detector clean,
cosign-signed releases. It's one implementation of this model; the threat
model discussion is more valuable than the tool itself.