Is hiding a secret from the prompt enough?

No. The model does not need to see the secret text to misuse it. A callable tool may already authenticate with that secret, a shell command may reveal it, or a dependency may read it from the environment. Control the runtime and tool permissions, not just the prompt contents.

Are read-only credentials safe for agents?

Not automatically. Read access can expose customer records, source code, internal tickets, logs, embeddings, infrastructure names, or weaker secrets. It can also help an attacker plan a stronger compromise. Treat read permission as real authority, scope it to the smallest useful resource, and audit its use.

What is the best practical test for reachable credentials?

Run the agent in its real deployment shape and try to enumerate what it can access: environment variables, files, metadata services, mounted tokens, secret stores, and tool-backed APIs. The expected result is not just that the prompt refuses, but that the runtime cannot read or use credentials outside the job.

Credentials an agent can reach

Credentials an agent can reach are all secrets, tokens, keys, service identities, and delegated permissions available to the agent’s runtime, directly or through its tools. They define the real authority of the system, regardless of what the prompt says the agent is allowed to do.

The need for this concept comes from prompt injection and tool misuse. An agent is not only a model producing text. It runs inside an environment with files, network routes, shells, libraries, cloud metadata, mounted tokens, and configuration. If hostile input can steer the agent into using those paths, a harmless-looking task can become a way to read secrets or exercise permissions that were never meant for that task.

Concretely, map every credential the process or its tools can obtain. That includes environment variables, local config, SSH material, CI credentials, service-account mounts, metadata endpoints, secret stores, browser sessions, and tokens passed into API clients. Then split access by tool and job: a ticket triage tool gets its own narrow identity, a database tool gets a scoped read credential, and neither inherits the host’s wider cloud authority.

The trade-off is operational friction. Least privilege means more identities, more token issuance paths, more policy, and more tests. Short-lived and brokered credentials reduce blast radius, but they add expiry handling and failure modes. The honest answer to how far to go is: it depends on the sensitivity of the reachable systems, the autonomy of the agent, and how untrusted its inputs are.

Engineers meet this when packaging agents into workers, containers, CI jobs, MCP servers, internal automations, or support bots. The practical review is to ask what happens if the agent is steered badly. Can it list secrets, read cloud inventory, use a deploy key, query customer data, or call an internal admin API? If yes, remove ambient authority, sandbox the tool, narrow the credential, and log which action used it.

Go deeper

Agents & MCPCredentials an agent can reachKeep an agent's tools from becoming a path to every key in the environment.Open the lesson

Common questions

Is hiding a secret from the prompt enough?: No. The model does not need to see the secret text to misuse it. A callable tool may already authenticate with that secret, a shell command may reveal it, or a dependency may read it from the environment. Control the runtime and tool permissions, not just the prompt contents.
Are read-only credentials safe for agents?: Not automatically. Read access can expose customer records, source code, internal tickets, logs, embeddings, infrastructure names, or weaker secrets. It can also help an attacker plan a stronger compromise. Treat read permission as real authority, scope it to the smallest useful resource, and audit its use.
What is the best practical test for reachable credentials?: Run the agent in its real deployment shape and try to enumerate what it can access: environment variables, files, metadata services, mounted tokens, secret stores, and tool-backed APIs. The expected result is not just that the prompt refuses, but that the runtime cannot read or use credentials outside the job.

Every term