When a coding agent runs as you, it holds your credentials and your permissions. Anything it can be tricked into doing happens in your name, and your logs cannot tell your actions from its. The fix is a separate, narrowly scoped identity for each agent.
What does "runs as you" mean in practice?
Most coding agents start from your terminal or editor. They inherit your shell environment, your Git credentials, your cloud sessions and your SSH keys. The agent does not need to be malicious. It only needs to read a file, web page or issue that contains instructions it follows. OWASP's Top 10 for Agentic Applications for 2026, reviewed by more than 100 experts, was written for this kind of system: agents that plan, act and decide across workflows.
Why does this matter for the supply chain?
Developer credentials are what supply chain attackers go after. In the April 2026 campaign described by The Hacker News, the credential stealer in the compromised Bitwarden CLI package targeted developer secrets, GitHub Actions environments and the configuration of AI coding tools. Whatever an agent can read on your machine, so can malware running beside it. Anthropic's report on an AI-run espionage campaign also describes an agent harvesting credentials as one phase of an intrusion.
What goes wrong specifically?
- Excess authority. You can push to production branches. The agent can too.
- Blind audit trails. Git history and cloud logs show you, not an agent acting on your behalf. Review after an incident cannot separate the two.
- Prompt injection. Text in a dependency, README or issue tells the agent to run a command or send data out.
- Credential reach. Tokens in environment variables and dotfiles are readable by anything you run.
- Long sessions. A session open for days accumulates context and access.
What does a better design look like?
Give the agent its own identity. A service account or machine identity, with a separate token, scoped to one repository or one environment, with a short lifetime. Log it as itself. Require human approval for pushes, deployments and permission changes.
Constructed example: a developer lets an agent fix a failing test. The agent reads a vendored dependency whose README includes a hidden instruction to print environment variables to an external URL. Running as the developer, it can see a cloud key and a package registry token. Running as its own identity, with no cloud key, no registry token and egress limited to the package mirror, the same injection finds nothing worth stealing and nowhere to send it.
How do you roll this out without blocking developers?
Start with the highest risk accounts and tasks: production access, release publishing and cloud administration. Move those to dedicated agent identities first. For everyday coding tasks inside a sandbox, keep the convenience but remove the long-lived secrets.
Offer a simple path. If getting a scoped agent token takes a day and a ticket, developers will keep using their own. If it takes a command and five minutes, they will switch. The tooling matters as much as the policy.
What to do
- Inventory the agents and tools your team runs and which credentials each can reach.
- Create a dedicated identity per agent or per task, with the minimum scope.
- Remove long-lived tokens from environment variables and dotfiles on developer machines.
- Use short-lived credentials that expire in hours.
- Limit outbound network access from agent sessions.
- Require approval for destructive or privileged actions.
- Log agent actions under the agent's identity, and review them.
- Treat all fetched content as untrusted data, not as instructions.
Safeguard offers agent identity and an MCP Guardrail for agents that call tools through MCP, plus policies and gates for pull requests. These limit what an agent can do. They are one layer, and your own credential hygiene still matters.
Quick check
Is running the agent in a container enough?
It helps with filesystem access, but if you mount your credentials or share your network, the agent still has them. Scope the identity too.
Do agents need their own accounts?
For anything beyond throwaway work, yes. A separate identity gives you scope, revocation and a log that names who acted.
Sources
- OWASP Top 10 for Agentic Applications for 2026
- The Hacker News, Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign (23 April 2026)
- Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign
Last reviewed: 18 October 2026.
