AI agents now hold API keys and database credentials that used to belong only to people or pipelines. They carry service tokens too, often with fewer restrictions than a human user would ever get. A 2026 Palo Alto Networks survey of 2,930 cybersecurity decision-makers across 20 countries found an average of 109 machine identities for every human identity in the organizations surveyed, and 79 of those 109 were AI agents. The survey shows how fast non-human identity has turned into an access-management problem.
Most organizations issue agent credentials the same way they issue a laptop to a new hire: create an account, grant broad access so nothing breaks, move on. That approach holds up for people, because a human employee will typically pause and check before taking an action that could cause damage. It holds up less well for a system that acts on whatever instruction looks most convincing in the text it just read.
This article covers the credential side of agent security: how to issue, scope, and audit the secrets an autonomous agent or LLM-based tool needs, without handing it a standing master key. It leans on Passwork's DevOps secrets model, which already answers most of this question for CI/CD pipelines. An agent's credential footprint sits much closer to a pipeline's than to a person's.
Key takeaways
- Agents already outnumber employees. 109 machine identities per human, 79 of them AI agents (Palo Alto Networks, 2026).
- Every agent gets its own service account. Shared accounts erase attribution the moment something goes wrong.
- Scope permissions to the task. A single API permission plus the narrowest vault access decides whether a compromise costs one credential or the whole fleet.
- Match token lifetime to runtime. 15-60 minutes for task-based agents, up to 4 hours for always-on ones.
- Static config files leak most often. GitGuardian found 24,008 secrets exposed in public MCP config files in 2025 alone.
- Keep raw credentials in an isolated tool-execution layer. A credential broker can implement this boundary, provided the model-facing agent never receives the secret.
- Filtering and scanning add friction rather than authorization. Comment and Control bypassed Copilot Agent's filtering, secret scanning, and network allowlist, while CamoLeak used GitHub's Camo proxy as a separate exfiltration channel. These cases support a brokered authorization boundary, but don't prove it can stop prompt injection on its own.
- One identity per agent makes revocation surgical. Disable one compromised account while every other agent keeps running.
- Rotation still takes a process you run yourself. Passwork covers accounts, access, tokens, and audit logs as the foundation.
Why AI agent credentials need different controls
A script follows the same code path every time, so you can scope its access before it ever runs. An AI agent picks which tool to call based on text it reads at runtime, and some of that text can come from an attacker. OWASP (Open Worldwide Application Security Project) names this failure mode LLM06:2025, Excessive Agency: unexpected, ambiguous, or manipulated model output can trigger harmful actions when an agent has excessive functionality, permissions, or autonomy.
Prompt injection is text crafted to override an agent's instructions. It's one way this manipulation happens, not the only one. Two disclosures from the past year show what it looks like in practice: Comment and Control (April 2026) exfiltrated live tokens from three coding agents through a hidden GitHub comment, and CamoLeak (October 2025) used a hidden pull request to make GitHub Copilot Chat leak private repository data through an image-proxy channel. In both cases an agent held tool access, a live credential sat within reach, and untrusted text made the agent treat it as an instruction. Rule 6 covers the mechanics of both.
The 7 rules for securing AI agent credentials
These rules apply the access discipline DevOps teams already use for pipeline secrets to an actor that decides its own next move. Most of them run on controls that mature secrets and identity platforms already offer. What changes is where to draw the boundary between what the agent can request and what it's allowed to hold.
Rule 1: Give every agent its own service account
A service account is a login created for an automated system rather than a person, with its own role and its own token pair, independent of any employee. Every production agent needs one. Sharing a single account across multiple agents erases attribution. When something goes wrong, the log says "the agent" instead of telling you which run, which task, or which deployment caused it.
Passwork's guide to service accounts and API tokens makes this the first rule for any automation, agents included: never authenticate a script or agent with a personal account. A personal account's permissions are usually broader than the job needs. Its actions log under an employee's name instead of the automation's, and revoking access means editing someone's personal profile instead of deleting a dedicated account.
| Account | Purpose | Access |
|---|---|---|
| agent-support-triage-ro | Reads CRM tickets, drafts replies | Read only, helpdesk vault |
| agent-deploy-approval | Reviews and approves deployments | Read only, infrastructure vault |
| agent-cred-rotator | Rotates secrets on schedule | Read and edit, both environments |
Name accounts by function, not by number. agent-support-triage-ro tells an on-call engineer what the account does six months from now. agent-3 tells them nothing.
Rule 2: Scope permissions to the task
OWASP's guidance on Excessive Agency reduces to two movesreduces to two moves:
- enforce least privilege by limiting the agent to the minimum tools and permissions required and independently enforcing authorization in downstream systems;
- require human approval before high-impact actions.
In Passwork, build the agent's role around a single permission called Use API, with user management, LDAP integration, and SSO administration switched off — the same API-driven access model DevOps teams already use for secrets. Grant vault and folder access separately, at the narrowest level the task requires: read only unless the agent's job is to write, folder-level rather than vault-level when it only needs a subset.
A support bot that reads one helpdesk credential has no reason to share a role with a deploy agent that touches production database credentials, even if one shared role is easier to set up. If an agent is compromised, that scoping decision separates a one-credential incident from a fleet-wide one.
Rule 3: Match token lifetime to how long the agent runs
An agent that fires once per task, to answer a ticket or review a pull request, behaves like a short CI (continuous integration) job. It doesn't behave like a person logging in for the day, so its credentials shouldn't last as long as a person's session.
Passwork issues a token pair: an accessToken used on every API request, and a refreshToken that requests a new pair once the access token expires. Recommended lifetimes scale with the job:
| Use case | Access token | Refresh token |
|---|---|---|
| Task-based agent (fires once per job) | 15-60 minutes | 1 day |
| Always-on agent | 1-4 hours | 30 days |
| Scheduled or manually triggered script | 1 hour | 7 days |
These are Passwork's own recommended ranges, not a universal standard. Check your platform's default token lifetime before assuming it matches these numbers. Defaults are usually set for convenience, not for a short-lived agent task, so shortening them is a deliberate step you take, not one you inherit.
In Passwork 7.6.0 and later, you can rotate the full token pair, the access token alone, or the refresh token alone. Rotating the full pair invalidates both previous tokens. Rotating only the refresh token invalidates the previous refresh token but leaves the current access token valid until it expires on its own. Build your revocation testing around whichever mode you use. Store refresh tokens as high-value, long-lived secrets, using a secure secret store or platform-provided secure storage; RFC 9700 provides useful protection principles, even though Passwork documents these as API session tokens rather than OAuth tokens.
Rule 4: Keep credentials out of repositories and MCP configuration files
Agent credentials often leak from plaintext files sitting in the agent's own working directory. GitGuardian's State of Secrets Sprawl 2026 report found 24,008 unique secrets exposed in MCP (Model Context Protocol) configuration files on public GitHub during 2025. GitGuardian's scanners confirmed 2,117 of them still worked at the moment of detection. Across public GitHub as a whole, 28.6 million hardcoded secrets appeared in commits during 2025, a 34% jump over 2024. Secrets tied to AI services grew 81% to over 1.27 million, including more than 113,000 leaked DeepSeek API keys.
MCP is an open-source standard that lets AI applications connect to external tools and data sources. Trend Micro's research on MCP server configurations found that roughly 48% of the servers it reviewed recommend passing credentials through a .env file. Hardcoding into a plaintext JSON config is the common alternative. Both approaches put several secrets in one file the agent's own process can open.
Reference the variable name in config, and get the actual value from a secrets platform at process start instead of from a file the agent can read directly:
{
"mcpServers": {
"internal-api": {
"command": "node",
"args": ["./server.js"],
"env": { "API_TOKEN": "${API_TOKEN}" }
}
}
}
This fixes the static-file problem but doesn't decide who fetches the actual value or where that value goes once fetched. Rule 5 covers that part.
Rule 5: Route every credential through an isolated tool-execution layer
Removing a secret from a repository or MCP config file matters, but it isn't the whole fix if that value then lands straight in the agent's own runtime. A developer knows not to paste an API key into a chat window. An agent has no equivalent instinct. Once a secret enters a tool response, a debug line, or a reasoning trace the model produces, it can resurface anywhere that text gets logged, cached, or replayed.
The safest approach is to keep secrets in the tool-execution layer, implemented here as a credential broker or tool-execution service, where the model cannot see them. The agent asks a dedicated tool to perform a specific task, such as checking deployment status or fetching a record. The tool uses the secret to complete the task and returns only the result to the agent.
To provide secrets when a process starts, without storing them in plaintext files such as mcp.json or .env, use passwork-cli exec.
passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" – ./start-agent.sh
The passwork-cli exec utility loads secrets into a child process only while that process is running. It does not write them to disk or include them in the command output. The key principle is to keep credentials at the tool level, where they stay outside the model’s context and any text the LLM can read.
Keeping the secret out of model context closes one disclosure path. A prompt-injected agent can still ask the broker to perform an operation it's technically authorized to make, just at the wrong time or on the wrong record. The broker needs its own policy checks in front of the secret store, and Rule 6 covers what happens when an injection still gets that far.
This also limits damage from filesystem access on its own. An agent process that can read a .env file pulls the credential straight into its working memory, and no file permission stops that once the agent itself is doing the reading. Routing through a broker the agent can call but not inspect enforces the boundary that Rule 4 starts.
Rule 6: Treat output filtering as a backstop, not your main defense
On 15 April 2026, researcher Aonan Guan and Johns Hopkins researchers Zhengyu Liu and Gavin Zhong published Comment and Control: three proof-of-concept demonstrations against Claude Code Security Review, Gemini CLI Action, and GitHub Copilot Agent. Each used a different injection surface, a pull request title, an issue comment, a hidden HTML comment, to expose runner secrets like ANTHROPIC_API_KEY and GITHUB_TOKEN.
Anthropic rated its own finding 9.4 CVSS, above the critical threshold. None of the three vendors assigned a CVE or published a security advisory. Don’t rely on a CVE feed to catch the next one: it returned nothing for a confirmed, critical, remotely triggerable credential leak in three widely deployed agents.
The Copilot Agent case shows why filtering alone doesn't hold. Guan's report describes three defenses in front of Copilot Agent: variable filtering, diff-based secret scanning, and a network allowlist. The demonstrated chain got past all three, reading secrets through a route the filter missed, encoding values past the scanner, and exfiltrating through a GitHub endpoint the allowlist already permitted.
CamoLeak, an earlier Copilot Chat vulnerability, shows that this risk is not limited to agent runners or CI secrets. Researcher Omer Mayraz found it in Copilot Chat in June 2025 and published details on 8 October 2025: hidden pull request content caused Chat to encode private repository data into image requests routed through GitHub's Camo proxy. Mayraz rated it CVSS 9.6. GitHub mitigated the issue, tracked as CVE-2025-59145, by 14 August 2025.
Output filters, scanning, and egress allowlists reduce the chance a leak succeeds, but none of them can authorize or block a tool request on their own. Treat them as backstops. Pair them with independent downstream authorization, argument validation, narrow single-purpose tools, and human approval for high-impact actions.
Rule 7: Log every action and keep revocation isolated to one identity
Passwork's activity log records events in CEF (Common Event Format), suitable for forwarding to a SIEM (security information and event management platform) over syslog. Documented fields include the event code (for example, item_created), a severity rating, a description, the acting user's ID and login, and the client IP. Passwork's event forwarding documentation covers the full field list for both Linux syslog and Windows Event Viewer.
A dedicated service account attributes every logged operation to a single automation identity. That's one reliable piece of the picture on a bad day. Reconstructing what one specific agent run actually did still means correlating your broker logs, downstream service logs, and egress logs across the same time window.
The value shows up regardless. When an agent does something nobody planned, whether it followed an injected instruction or misread a task, a per-agent service account tells you which identity, which session, and which secrets it touched, without cross-referencing a shared token against timestamps. Revocation stays isolated too: disable that one account's tokens, and every other agent keeps running. That's a stronger argument for separate accounts than any dashboard.
Building agent credential controls with Passwork
Passwork provides the core controls for managing agent access. For AI agents, these controls can be organized around five areas:
- Give each agent function a dedicated service account. Separate accounts keep agent access isolated and activity attributable.
- Apply least privilege through roles and granular ACLs. Limit each account to the vaults, folders, and operations required for its task. Standardized role and ACL templates can simplify provisioning at scale.
- Treat credential rotation as an end-to-end workflow. Replace the credential in the target system, update it in Passwork, revoke the old credential, and verify that old access has ended. GitGuardian found that more than 64% of credentials confirmed as valid in 2022 were still valid in January 2026.
- Use dynamic credentials where required. Workloads that need short-lived credentials generated on demand may require a dynamic-secret or credential-leasing service alongside the vault.
- Connect agent activity to the wider monitoring stack. Verify the monitoring capabilities of the Passwork edition and version in use, and forward activity records to a SIEM where event correlation or near-real-time alerting is required.
AI agent credential checklist
Run through this eight-check gate before an agent touches a real credential in production.
- Dedicated identity. Does this agent have its own service account or workload identity, separate from every other agent and every human?
- Least privilege. Have you limited its role, vault or folder access, and resource scope to what the task actually needs?
- Read-only default. Have you disabled write, deletion, and external communication unless the task specifically requires them?
- Token lifecycle. Have you matched the access-token lifetime to the length of a run, with refresh tokens protected and revocable?
- No static exposure. Have you confirmed the credential is absent from repositories,
.envfiles, MCP config, and every other file in the agent's working tree? - Broker boundary. Does a separate, isolated broker hold the secret while the model-facing agent receives only a minimized result?
- Tested safety controls. Have you tested output handling, argument validation, and egress restrictions against adversarial input, rather than assuming they work?
- Verifiable containment. Can you correlate agent, broker, and downstream logs, and revoke the affected identity without disrupting any other agent?
What this means for your team
Scoping an agent's role to Use API and minimum vault access is a config change. Most secrets platforms already support it. The engineering work sits in the layer around it: a broker between the agent and the secret store, output filtering as a backstop against leaks, and audit logs that let you revoke one identity without touching the rest.
Start with the agent that has the broadest access in your environment today, and cut its role down to what the job requires.
Frequently asked questions
Should an AI agent reuse our existing CI/CD service account?
No. The pipeline's access was scoped for deployment, and an agent doing something else inherits permissions it never needed. Sharing an account also merges two actors into one audit identity, which is the distinction you'll need during an incident. Give each function, per environment, its own account.
What token lifetime should an agent credential have?
Match it to how the agent runs. Agents that fire once per task fit the same 15-to-60-minute access token window Passwork recommends for short CI jobs. Always-on agents can justify 1 to 4 hours. Anything longer is a standing credential wearing a short-lived label.
Can we keep the vault token in the MCP config file?
That's exactly the file class where GitGuardian found 24,008 exposed secrets on public GitHub in 2025. Reference the variable name in the config file, keep the actual value out of it, and fetch the value at process start through a credential broker, using a tool like passwork-cli exec.
Does a password vault prevent prompt injection?
No. A vendor claiming otherwise is overselling. You mitigate prompt injection at the agent's architecture level: narrow tools, a boundary between instructions and ingested content, independent authorization at the downstream system, and human approval on high-impact actions. A vault limits how far a successful injection can reach, and it tells you afterward exactly which credentials were touched.
How many AI agents does a typical company already run?
A 2026 Palo Alto Networks survey of 2,930 cybersecurity decision-makers found an average of 109 machine identities per human identity, including 79 AI-agent identities per human, across the organizations surveyed. That's a survey average, not a guarantee that every company individually has more agents than employees, but it's a reasonable signal that agent identity has outgrown ad hoc management in most environments.
Do the GitHub Copilot and CamoLeak incidents mean these agents are unsafe to use?
No. Both were researcher-disclosed proof-of-concept findings, and the vendors involved responded to them. They show that filtering and scanning are only part of the defense: injection chains can bypass them or use separate exfiltration paths. That’s why the broker boundary in Rule 5 matters regardless of which vendor’s agent you run.
Passwork Team
Passwork Team
Passwork Team
Table of contents
Table of contents
Self-hosted password manager for business
Passwork provides an advantage of effective teamwork with corporate passwords in a totally safe environment. Double encryption and zero-knowledge architecture ensure your passwords never leave your infrastructure.
Learn more