The config file is rarely where the leak happens

Most teams already know not to commit a .env file. The leaks that actually hit AI workflows happen one layer up, in places code review does not usually look: a system prompt that includes a connection string for context, a tool definition that embeds an API key as a default parameter, or a retrieval step that pulls a support ticket containing a customer's access token into the context window.

Once a credential is inside the prompt or the retrieved context, it is no longer just configuration. It is text the model can read, reason about, and in some failure modes, echo back in a response, a log line, or a trace that gets forwarded to an observability tool outside your control.

Logs and traces are a second copy of your secrets

Debugging an agentic workflow usually means turning on verbose tracing: full prompts, full tool-call arguments, full responses. That trace is often shipped to a third-party observability or analytics platform by default, which means any secret present in the prompt or a tool call now has a second home with its own retention policy and its own access list.

OWASP's guidance on secrets management is blunt about this pattern: secrets that sit in plaintext in configuration, logs, or container definitions are one misconfigured access grant away from exposure, and the fix is to keep secrets out of anything that gets persisted or shipped elsewhere by default.

  • Redact known secret patterns before a trace leaves your process, not after.
  • Treat your trace and observability store as a system that needs its own access review.
  • Assume anything in a prompt can appear in a log, a replay, or a support ticket.

Inject credentials at call time, not at build time

The structural fix is the same one that already applies to normal backend services: a workflow step should receive a credential from a secrets manager at the moment it calls a tool, not carry that credential baked into a prompt template, a workflow definition, or a config file checked into source control.

OWASP's Secrets Management Cheat Sheet frames this as retrieving secrets from a dedicated store at runtime rather than hardcoding them anywhere upstream, and the same separation applies whether the caller is a human-written function or a model-driven tool call. If a tool call needs a key, the orchestration layer should resolve it just before the call and never hand it to the model as part of the instructions.

Rotation is your backstop for the leak you have not found

No review process catches every path a secret can take through an agentic system, especially once retrieval, multi-step planning, and third-party tools are involved. Short-lived, automatically rotated credentials shrink the value of a leak that has already happened but has not been noticed yet.

OWASP's own rotation guidance applies directly here: regularly rotating secrets limits how long a stolen credential stays useful, and restarting an application does nothing to invalidate one that is already loose. For an AI workflow, that means scoping each tool's credential as narrowly as possible and rotating it on a schedule independent of whether you believe it has leaked.