Part of the AI coding agent security checklist

Developer OPSEC: what your laptop and your AI agents give away

Operations security, OPSEC, is knowing which of your information would help an attacker and keeping it out of their reach. For a developer, that information is mostly credentials. A laptop keeps many of them in plaintext, and AI coding agents add copies of their own.

Checked against NIST, OWASP, the Claude Code, AWS, npm, Docker, GitHub CLI, OpenSSH and 1Password documentation, and the research under Sources. Published 6 October 2026.

01 / Meaning

What OPSEC means for a developer

NIST's glossary defines OPSEC as a process that denies potential adversaries information about your capabilities and intentions, in five steps. On one laptop, they look like this.

Critical information The credentials that let someone act as you: cloud keys, API tokens, SSH keys, package registry tokens, and the sessions AI tools keep. Then the code and data those reach.

Threats Malware running as you, such as an infostealer. A dependency or repository whose setup runs code. A lost or shared machine. And an agent that runs a command because a file or a web page told it to.

Vulnerabilities Credentials in plaintext files that any process you start can read, and the copies of them in shell history and agent transcripts.

Risk What each credential could do in the wrong hands, and for how long. A read-only token that expires tomorrow is a small risk. An admin key with no expiry is not.

Countermeasures Fewer copies, narrower tokens, shorter lives, and a check of what is already on disk: the rest of this guide.

02 / Laptop

Where credentials sit on a developer laptop

The usual places. Unless a tool keeps its secret in the system keychain, any process running as you can read it.

Where	What it holds
`~/.aws/credentials`	The AWS access keys you gave aws configure, for each profile.
`~/.ssh/`	Private keys. A key with no passphrase works for whoever copies the file; ssh-keygen -p sets one on an existing key.
`~/.npmrc`	Registry tokens, as _authToken lines scoped to each registry.
`~/.docker/config.json`	Registry credentials, base64-encoded rather than encrypted, unless a credential store is set up.
GitHub CLI	Its token goes to the system credential store, or to a plain text file when it cannot use one or you pass --insecure-storage. gh auth status says which.
`.env`	Each project's application secrets, in plaintext beside the code.
`~/.bash_history`, `~/.zsh_history`	Any token typed or pasted into a command line.
`~/.claude.json`, `.mcp.json`	MCP servers, with any API key written into their configuration. A project's .mcp.json is meant to be committed.

The last row is not hypothetical. GitGuardian's State of Secrets Sprawl 2026 found 24,008 unique secrets in public MCP configuration files, 2,117 of them valid. And on 8 September 2026 Gen Digital reported that infostealers have added AI tools to what they collect: access tokens, MCP configurations and prompt histories. One of them, CallbackBeaver, added Cursor and Claude to its collection scope, and Gen Digital saw more than 5,000 samples of it in 30 days.

ls -la ~/.aws ~/.ssh ~/.docker     what is there, and who can read it
grep -l _authToken ~/.npmrc        an npm token on disk
gh auth status                     where the GitHub CLI keeps its token

03 / Agents

What AI coding agents add

An agent runs commands as you, so it can read every file above. And it keeps its own record of what it read.

Claude Code writes every message, tool call and tool result to a transcript under ~/.claude/projects. Its documentation is plain about it: transcripts are not encrypted at rest, file permissions are the only protection, and if a tool reads a .env file or a command prints a credential, that value is written to the transcript. Claude Code deletes them after 30 days by default. Codex, Gemini CLI, GitHub Copilot CLI and others keep their own, each in its own folder: the history guide lists where.

So one cat .env leaves the value in two places it was not before: the model's context, and a file in your home folder. The OWASP AI Agent Security Cheat Sheet lists this among its key risks, as credentials included in agent context or logs. Claude Code's Bash commands also inherit the environment it was started in, secrets included, so a token exported in that shell is in reach of every command it runs.

Agents leak into commits too. GitGuardian measured a 3.2% secret-leak rate in public commits made with Claude Code's help, against 1.5% across all public GitHub commits, and says the figure does not put the cause on the tool alone.

Where Claude Code and the other agents keep their history →

04 / Check

See what is already there

Start with what takes a minute: which agents kept history here, what they ran, and which credentials they left in it.

$ uvx ranwhat check

ranwhat sources                  which agents left history on this machine
ranwhat check                    what they ran, and the secrets they left; changes nothing
ranwhat clean --no-interactive   the secrets alone, with what to rotate

ranwhat reads the agents' history only. For your code and the rest of your home folder, run a general secret scanner as well: gitleaks dir scans a directory, and trufflehog filesystem scans files and directories. TruffleHog tests what it finds against each provider's API to mark it verified; --no-verification turns that off.

gitleaks dir -v ~/code
trufflehog filesystem ~/code --no-verification

05 / Rotate

Rotate first, then clean up

A credential found in a transcript or a history file has already been readable. Masking the copy does not change that.

Rotate Create the replacement, move what uses the old key to it, then revoke the old one. The checklist has AWS's and Stripe's sequences.

Check use Look in the provider's own record for use you do not recognise: CloudTrail and last-used data on AWS, the audit log on GitHub, request logs on Stripe.

Then mask ranwhat clean masks the copies in agent transcripts after a backup. The backups still hold the values, so delete them once the transcripts look right.

After malware Gen Digital's advice after an infostealer infection: from a clean device, revoke AI-service sessions, rotate API keys and the credentials MCP connections use, and review connected applications and account activity.

06 / Keep out

Keep secrets out of files the agent can read

Every plaintext copy you do not make is one less to find, rotate and mask later.

References 1Password's op run reads a .env file whose values are secret references, and passes the real values only to the command it runs, as environment variables, for as long as that command runs. An agent that reads the file sees references.

Not the agent Run it around the command that needs the secret, not around the agent: a secret in the agent's environment is in reach of every command it runs.

MCP configs Claude Code expands ${VAR} in .mcp.json, so an API key need not be written into a file that is shared or committed.

Rules Deny Claude Code's reads of .env files, turn on the sandbox, and list your credential files in sandbox.credentials with mode deny. Put them in your user settings so they cover every project. A project's settings can add deny entries, but Claude Code honours mask entries only from user or managed settings, or a file passed with --settings.

Typing one read -rs NAME takes a pasted token without echoing it or writing it to shell history.

app.env

AWS_ACCESS_KEY_ID="op://development/aws/Access Keys/access_key_id"
AWS_SECRET_ACCESS_KEY="op://development/aws/Access Keys/secret_access_key"

op run --env-file="./app.env" -- aws s3 ls   the values exist only for this command

Deny rules and the sandbox for .env files, in full →

07 / Tokens

Shrink what each token can do

A credential you cannot keep secret should at least be worth little to whoever copies it.

The OWASP Non-Human Identities Top 10 names the failures: secret leakage (NHI2), over-privileged identities (NHI5) and long-lived secrets (NHI7). Give each agent its own tokens, scoped to its task and with an expiry, rather than your own. ranwhat scan scores what a set of credentials allows, read-only, and marks the grants that were never used wherever the provider keeps a record.

AI agent token scopes, provider by provider →

08 / Checklist

The checklist.

One line each, in the order worth doing them. Each points back to its section.

01 Run uvx ranwhat sources to see which agents kept history here. Check
02 Run uvx ranwhat check, and rotate anything it finds before you mask it. Rotate
03 Scan your code and home folder with Gitleaks or TruffleHog. Check
04 Look through ~/.aws, ~/.ssh, ~/.npmrc, ~/.docker and your MCP configs: what is in plaintext, and who can read it. Laptop
05 Put a passphrase on every SSH private key. Laptop
06 Replace .env values with secret references, and inline MCP keys with ${VAR}. Keep out
07 Deny agent reads of .env and turn on the sandbox. Keep out
08 Set how long Claude Code keeps history on purpose. Agents
09 Give each agent its own scoped, expiring tokens. Tokens
10 After any suspected malware, rotate from a clean device, AI-service sessions and MCP credentials included. Rotate

09 / Scope

What ranwhat covers, and what it does not.

ranwhat covers the agents' side of the laptop, after the fact.

Covers sources: which coding agents kept history here. watch: what they ran. clean: the credentials in their transcripts, masked only when you ask. scan and live: what a set of credentials allows.

Does not Search your shell history, ~/.aws, ~/.ssh or the rest of the disk for secrets, manage secrets, or block anything while an agent works. A general secret scanner, a secrets manager and the agent's own rules and sandbox do those.

Network Reads locally. live and --pull-usage ask only the provider that issued each token. update fetches the capability catalogue for Plus subscribers and sends only the subscription token.