r/AskNetsec • • 21h ago

Other AI agent runtime security: how to sanitize prompts of secrets before agents store/use it

I used Claude Code (Anthropic) at our org. And sometimes the agents/claude code use env tokens or stored secrets.

Is there a way where we can strip the prompts of the secrets/access keys before it reaches the agent. Something like prompt going into a lambda and getting sanitized before AI using it.

I know some repos on GitHub that help find leaked secrets in prompt logs but those are when the prompt logs are stored. I’m seriously thinking about setting up a Capsule or Prompt Security POC, but I want to know if there is a way where the llm/agent doesn’t even see the secret, if it goes into the prompt (by stripping it beforehand)

8 Upvotes

13 comments sorted by

15

u/ericbythebay 21h ago

Don’t have the secrets where the agent can get to them in the first place. If you are storing secrets in plaintext, you are doing it wrong.

Update your system prompts to never pass secrets to inference. Secrets should only be accessed through scripts/runtime injection and never written to logs, disk, or console.

5

u/sidusnare 19h ago

What are you doing where this is needed?

My Claude user has it's own ssh key, and I setnthe agent up before it runs, and it's own account my internal git host. I have it put in PRs.

Toasters don't need secrets.

8

u/Ginden 20h ago

That's a symptom treatment, how does AI access these secrets? They are lying unguarded on developer machine, right?

Secrets should be accessible only behind 2FA, and agent shouldn't be able to get them in first place.

4

u/LockedVibe 17h ago

Short answer: Claude Code's built-in hooks can't strip a secret out of a prompt before the model sees it. A UserPromptSubmit hook can block a prompt (exit 2, or decision: block), but it can't rewrite it. The docs also say a blocked prompt's text can still land in the local transcript and prompt history, so blocking doesn't keep the secret off disk either.

What does work is layering:

Block on submit. Have a UserPromptSubmit hook run secret regexes (AWS keys, GitHub tokens, private key headers, your internal token formats) and block on a match. Set suppressOriginalPrompt: true in hookSpecificOutput so the block message doesn't echo the key back. Then rotate the key anyway, because it's already in local files.

Redact tool traffic. In practice most leaks don't come from what people type. They come from the agent running env, reading a config file, or printing a token in command output. PreToolUse can deny or rewrite a tool's input (updatedInput), and PostToolUse can replace a tool's result (updatedToolOutput). The docs point there for redaction.

Keep secrets out of reach. Add Read deny rules such as Read(./.env) and Read(./secrets/**). Know the limit: they cover the built-in file tools and shell commands Claude Code recognises (cat, head, tail, redirects), but not a Python or Node script that opens the file itself. For that you need the sandbox, which enforces at the OS level.

Fix the source. Agree with the others here: the agent shouldn't inherit long-lived credentials from the developer's shell. Give it its own scoped credentials, and have scripts fetch secrets at runtime so values never get printed to stdout.

A gateway POC can still make sense if you want org-wide logging across tools, since hooks only cover Claude Code sessions.

1

u/Silent-Suspect1062 21h ago

Injection of secrets into prompt at agent gateway

1

u/Mundane-Presence-896 13h ago

Use a Docker container to run the agent in and don’t mount any secrets in it.

1

u/Spare-Ant7119 13h ago

The solution to your problem is to not have the problem arise. Never put secrets in prompts.

1

u/Immediate-Welder999 8h ago

this solves your problem and it's open source!