How to manage credentials for cloud AI agents

The safest way to manage credentials for a cloud AI agent is to make sure the agent never holds them. Keep the real keys in a vault outside the machine the agent runs on. Give the agent a short-lived token issued for this one run, and let a proxy or gateway add the real credential to each request after it leaves the agent's machine. Anything the agent can read, a prompt injection can make it reveal. Putting a key in an environment variable or a config file inside the sandbox therefore hands it to anyone who can get text in front of the agent.

Where do agent credentials leak?

In the places teams put them to get an agent working quickly: config files, environment variables and CI.

GitGuardian's 2026 report counted 28.65 million new secrets in public GitHub commits in 2025, up 34% in a year. Secrets for AI services rose 81%. It also found 24,008 unique secrets in MCP configuration files alone, 2,117 of them still valid. It noted that popular MCP setup guides tell people to paste API keys straight into those files. The same report found that 64% of secrets that were valid in 2022 still work. A leaked key is rarely revoked.

Agents have also been used to steal keys. In August 2025 the malicious Nx packages ran the AI command line tools installed on a developer's machine with their safety prompts turned off, and asked them to search the disk for secrets. GitGuardian counted 2,349 distinct secrets leaked in the first wave, about half still valid when found.

Can an agent keep a secret it can read?

No. This is the point most setups miss.

An agent follows text. If a key sits in its environment, any instruction that reaches the agent can ask for it: a comment on an issue, a pull request title, a tool description. In April 2026 researchers showed that crafted comments and pull request titles could hijack three coding agents running in CI, from Anthropic, Google and GitHub. At Black Hat in August, Novee Security showed that a single GitHub issue, opened by an account with no special access, was enough to reach agent credentials in CI.

The lesson is not that these agents are careless. Any model can be talked into things. So the credential has to be somewhere the agent cannot reach, however it is persuaded.

What should the agent hold instead?

A token you issued, for this run, that is worth little on its own.

The pattern the major cloud agents have settled on is a proxy. In Anthropic's cloud environments for Claude Code, GitHub credentials never enter the session's machine. Git inside it uses a scoped stand-in that a proxy swaps for the real token on the way out. OpenAI's Codex cloud environments work the same way: programs see a placeholder, and the proxy substitutes the real value for allowed destinations. Anthropic's documentation also warns against putting secrets in the environment's variables, which anyone using that environment can read.

The Model Context Protocol writes the same rule into its authorization specification. An MCP server must check that a token was issued for it, and "MUST NOT accept or transit any other tokens". When the server calls an upstream API, it uses a separate credential of its own. The agent's token opens the gateway, and nothing behind it.

How long should an agent's credential live?

As short as the work. A GitHub App's installation token expires after one hour and can be limited to named repositories and permissions. GitHub Actions can exchange an OpenID Connect token for cloud access that is only valid for a single job. AWS tells you to require temporary credentials for workloads, and Google says workload identity federation removes the need for service account keys altogether.

Long-lived secrets are seventh on OWASP's Non-Human Identities Top 10, and secret leakage is second. A key that expires with the run cannot be found and reused next month. We cover the choice between GitHub's token types in how to give an agent GitHub access safely.

Whose credentials is the agent using?

Its own, or a clearly delegated slice of a person's. Never a person's whole key.

OAuth 2.0 Token Exchange, RFC 8693, separates impersonation from delegation. With delegation, the token records both who the agent acts for and that the agent is the one acting. That difference decides whether your audit log says "Priya merged this" or "Priya's agent merged this, on Priya's authority". Only the second lets you find out which agent did what. It is also why each agent needs its own identity. OWASP lists reusing one identity across workloads as its own risk.

How do you take access back?

In one action, before anything else happens. Revoking the agent's token is the fastest kill switch you have, so design for it. Revocation should stop the next tool call immediately, without a redeploy and without waiting for a key to expire. If revoking an agent's access means rotating a shared key that six other systems use, nobody will do it in a hurry, and the agent will keep working while they decide.

A short checklist

• No real credential inside the sandbox. Not in environment variables, not in config files, not in the repository.
• A token per run, issued by you, that a gateway or proxy exchanges for the real credential outside the agent's machine.
• One identity per agent, acting on delegated authority, never a person's whole key.
• Scopes start at read. Widen them deliberately, one level at a time.
• Scan before the run. A secret committed to the repository is in the agent's context the moment it reads the file.
• Revocation is one action, and it is tested.

How does Cognibl handle credentials?

A tool account is connected once, and its credential is stored encrypted. Cognibl's gateway holds it and makes each call. The agent receives the result, never the token that fetched it. A cloud agent runs in its own machine as a non-root user, holding no cloud credential. Its shells are stripped of anything that looks like a credential. It clones and pushes through Cognibl's git proxy under a token issued for its run, and the proxy refuses a push to the base branch. The task directory is scanned for credentials before the run starts. Minting or entering a credential is deliberately not something an agent can do through Cognibl's MCP endpoint, so a key never passes through a model's context. Halting a run revokes its token first. See how cloud agents run without your keys.