AI Agent Security Risks: 7 Leaks on My Own Machine

AI agent security risks are usually discussed in the abstract. So this week I stopped reading and ran the audit on my own Mac, expecting to find nothing. I was wrong, and the thing that bit me was not the file every security blog warns about.

Netwrix published research on 12 May 2026 covering how 14 AI developer tools store credentials, and the headline finding was that most of them write tokens to predictable plaintext paths in your home directory. I run Claude Code daily, so I checked. What I found reframed how I think about AI agent security risks entirely: the small, known credential files are increasingly well handled, and the real exposure is sitting in a directory nobody audits.

Table of contents

• What AI agent security risks actually look like on a real machine
• Where the research says the credentials live
• Why the transcripts are the interesting part
• The identity framing beats the file-path framing
• What’s worth doing about these risks
• The part I can’t answer
• FAQ

What AI agent security risks actually look like on a real machine

The credential file everyone is worried about wasn’t there. On macOS, Claude Code puts OAuth tokens in the system Keychain, exactly as the research says it should, and ~/.claude/.credentials.json does not exist on my system. Good.

What I found instead was 573 session transcript files in ~/.claude/projects/, totalling 958 MB, spanning 42 days. I scanned them for secret-shaped strings. 23 files contained at least one. Across the set: 6 AWS access key IDs matching the AKIA[0-9A-Z]{16} format, 67 bearer tokens, and 245 hex-32 strings, which is the shape most API keys take.

None of that is a vulnerability. There is no CVE here and no patch to apply. The agent logged what I typed and what my tools returned, which is precisely what a session transcript is for. But I had spent zero seconds thinking about that directory as a place credentials accumulate, and that gap in attention is exactly where the real exposure lives for most working developers.

Where the research says the credentials live

The Netwrix work, by Darryl Baker, is worth reading in full because it is specific about paths rather than gesturing at “AI security risk.” The tool-by-tool findings that matter most:

Claude Code CLI writes OAuth access and refresh tokens to ~/.claude/.credentials.json in plaintext JSON. On Linux the file gets 0600, owner-only. On macOS it goes to Keychain. But under WSL, the Windows-side file inherits the mount’s default 0777, which makes those tokens world-readable to any process on the system. The refresh token is the dangerous half: it’s long-lived and mints new access tokens indefinitely until someone explicitly revokes it.

Continue.dev writes every configured API key straight into ~/.continue/config.json. Environment variable substitution via ${VAR_NAME} is supported but isn’t the default, and the project has acknowledged this in GitHub issue #1729.

Cline keeps MCP settings in an unencrypted JSON file inside VS Code’s globalStorage. VS Code Settings Sync then uploads that file to GitHub. If you have Settings Sync on, your MCP credentials are in someone’s cloud. This is one of the risks that spreads without anyone noticing, because sync is a feature people turn on and forget.

The aggregation problem is the one I’d flag hardest. MCP server configs collect tokens for every connected service into a single file: a GitHub PAT, an Azure DevOps token, a Slack bot token, a database password, all in one place. One read compromises all of them. Netwrix cites Trend Micro finding that 48% of 19,402 MCP server implementations recommend plaintext credential storage. GitGuardian’s State of Secrets Sprawl 2026 analysis found 24,008 unique secrets in public MCP configuration files, 2,117 of them still valid.

There’s also a trap in VS Code’s SecretStorage API, which Copilot and others use. It encrypts secrets in a SQLite database, state.vscdb, with AES-128-CBC. That protects against someone reading the disk offline. It does nothing against a process running as the same user. On my machine that file is mode 0644, world-readable, 290 KB.

Why the transcripts are the interesting part

Here’s my audit, values withheld:

The config files are all locked down at 0600. The directory nobody talks about is the one holding 958 MB of conversation.

That asymmetry is the point, and it is the single most under-rated item on any list of these risks. Credential files are small, known, and increasingly well handled. Vendors are fixing them; my Keychain result is evidence that some AI agent security risks are shrinking. Transcripts are large, ignored, and grow without limit. ~/.claude/projects is 0700, so permissions aren’t the issue. The issue is retention: 42 days of history I never chose and can’t easily reason about.

And a transcript catches things a credential store never would. Anything you paste into a prompt. Anything a tool prints. Run env or cat .env or a failing curl that echoes an auth header, and it’s in the log. My 6 AWS key IDs almost certainly arrived that way, not because any tool mishandled them.

The identity framing beats the file-path framing

GitGuardian’s 2026 State of Secrets Sprawl Report found commits identified as AI-assisted leak secrets at roughly twice the rate of human-written ones (a 3.2% leak rate in Claude Code-assisted commits versus a 1.5% baseline), and that the fastest-growing categories of leaked credentials are now tied to AI services.

Keeper Security’s RSAC 2026 survey puts a number on the governance gap: 46% of respondents said AI tools have access to critical systems and sensitive data, while 76% said those identities aren’t consistently governed under privileged access policies. That governance gap is where most enterprise exposure compounds into a real breach.

Those two figures together explain why path-patching doesn’t finish the job. Ashley D’Andrea, writing for Keeper in The Hacker News this month, makes the argument plainly: treat this as a non-human identity problem, not a model-behaviour one. “AI agents didn’t create secrets sprawl; they exposed how many organizations have poor strategies for machine credential security.”

I think that’s right, with one caveat. The identity framing is the correct long-term answer and it’s also the expensive one. Short-lived scoped credentials and an orchestration layer that brokers them is months of work for most teams. The transcript directory is a ten-minute problem. Do the cheap thing first: the biggest AI agent security risks are the ones you never audit.

What’s worth doing about these risks

Rotate anything you’ve pasted into an agent prompt. Don’t audit and decide, just rotate. You cannot reliably grep your way to certainty across a gigabyte of JSONL, and my hex-32 count of 245 is mostly false positives on hashes and object IDs, which is exactly why the count is useless as a clean bill of health.

Set a retention limit on transcripts. I have not found a documented config option for capping this in Claude Code, so mine is a scheduled delete of anything older than 14 days. If you know of a supported setting, I’d genuinely like to be corrected.

Check whether your transcript directory sits inside a synced tree. ~/.claude is not inside iCloud Drive on a default macOS install, and mine isn’t, but if you’ve moved your home directory contents around or you’re on Dropbox, verify rather than assume. Full-disk encryption protects the stolen-laptop case and does nothing for the synced-backup case.

If you’re on WSL, go check the permissions on the Windows-side credentials file. That 0777 inheritance is the single sharpest finding in the Netwrix research and it’s environment-specific, so it won’t show up in a macOS or native-Linux audit.

Scope your CI secrets per step. The default GitHub Actions config does not scope secrets to individual steps, so ANTHROPIC_API_KEY, GITHUB_TOKEN, and any production secret propagate to every workflow step, including AI coding agents. This is the runtime version of the same problem and it is where the highest-severity issues have actually been exploited in 2026.

Stop pasting secrets into prompts. Obvious, and I did it anyway, six times, by running commands whose output contained keys.

If you want the full picture of how coding agents behave once they have permissions, I wrote about the kill switch hiding in your coding agent’s permissions, and about what an LLM gateway actually does for a coding agent when you route multiple providers through one key.

The part I can’t answer

If you run agents in CI, transcripts land on runners you don’t control, and I can’t find retention documentation from any vendor covering that case. That’s the gap I’d want closed before putting agent credentials anywhere near a shared build environment, and unmanaged CI retention is the AI agent security risks question I’d put to your vendor rather than to a blog.

FAQ

What are the biggest AI agent security risks in 2026?
The most under-rated one is credential accumulation in session transcripts and logs, not the credential config files themselves. Vendors have largely hardened the known token files; the unbounded conversation history is where pasted keys and tool output quietly pile up.

Do AI coding agents actually leak more secrets than humans?
GitGuardian’s 2026 data shows a 3.2% secret-leak rate in Claude Code-assisted public commits versus a 1.5% baseline. That is correlation, not proof of causation, but it shows AI-assisted speed has not removed the underlying credential-hygiene problem.

How do I reduce AI agent security risks quickly?
Rotate anything you have pasted into a prompt, cap transcript retention (mine deletes anything older than 14 days), verify your agent directories are not inside a synced folder, and scope CI secrets per step rather than per repo.

Sources: Netwrix research on AI credential storage (Darryl Baker, 12 May 2026); GitGuardian AI coding agents credential security; The Hacker News on secrets sprawl as an identity problem; GitGuardian 2026 State of Secrets Sprawl. File counts and permissions quoted above come from a scan of my own macOS machine on 26 September 2026; no credential values were read or recorded.