Your coding agent has your keys
What can your AI coding agent access? Practical guidance on permissions, secrets, execution boundaries and human approval in development workflows.
Key Takeaways
- An agent running commands may inherit credentials, environment variables, repository permissions and network access from its execution context. Its authority depends on those permissions, not on how capable it seems.
- Excessive authority is a design problem before any attack, because a mistaken command or an injected instruction can reach further than the task needs.
- Review four boundaries before an agent does more than suggest code: identity, execution, secrets and approval.
- An agent-generated summary is not independent evidence; protected branches, independent review and separate deployment gates still matter.
- Map one real agent-enabled workflow end to end: what the agent can read, run and change, which credentials it uses and who approves each step.
Imagine giving a new developer access to your source code, cloud credentials, CI/CD pipelines and production environment on their first day. You probably wouldn't. You would explain the boundaries, grant access for a specific task and keep sensitive actions behind reviews.
Now look at how some coding agents enter the engineering workflow. Someone starts a session on an already authenticated workstation. The agent can read files, run commands, install packages and call connected tools. The credentials belong to a human, but the commands may no longer come directly from that human.
We have spent decades learning to limit human access. It would be odd to forget those lessons precisely when the work becomes more automated.
Where the authority comes from
A model suggesting code in an editor is a different risk from an agent running that code in a shell. The latter has an execution context. It may inherit environment variables, cached credentials, repository permissions and network reachability. Whether it can deploy, read secrets or modify infrastructure depends on those permissions, not on how confidently it describes its intentions.
Take a hypothetical team using GitHub and a cloud-based deployment pipeline. A developer asks an agent to refactor an API endpoint, update tests and open a pull request. The agent only needs access to the target repository, a temporary branch and a disposable test environment. But the session runs on a machine with a cloud CLI already authenticated to a production account.
No malicious intent is required for that to be a poor design. A mistaken command can have wider consequences than the task warrants. If the agent also reads untrusted repository instructions or a compromised tool response, an attacker may try to turn the agent's legitimate tool access into an unintended action. The precise attack path depends on the environment; the excessive authority is visible before any attack succeeds.
Trust is not a permission model
We describe AI tools as helpful, capable or reliable. Those are observations about performance, not reasons to issue credentials. A coding agent preparing a pull request generally does not need production deployment rights. Nor should a test-writing task require organisation-wide repository access simply because the developer launching it happens to have that access.
I would review four boundaries before enabling an agent to do more than suggest code.
Identity. Can you distinguish the agent's actions from the developer's? Where the platform permits, use a dedicated identity and narrowly scoped, revocable credentials. Attribution should survive the end of the chat session.
Execution. Are commands running in a disposable environment or on a workstation full of internal access? Isolation and controlled network access do not eliminate every risk, but they limit what an unexpected command can reach.
Secrets. Which credentials can the process see, including those inherited indirectly through tools or environment variables? Keep production secrets out of general coding sessions unless a narrowly justified task requires them.
Approval. Can the same automated workflow propose, approve and deploy its own changes? Protected branches, independent review and separate deployment gates matter because an agent-generated summary is not independent evidence that a change is safe.
Try this with one actual workflow
Choose an agent-enabled task already used by your team. Draw the path from request to deployed change. At each step, note what the agent can read, execute and modify, which credentials it uses, who approves the next step and which records remain afterwards. You do not need a new framework to discover that an agent can see an unnecessary secret or that a deployment approval can be bypassed.
Equally, an unanswered question is not automatically a vulnerability. It is a boundary that has not been demonstrated. Decide whether it matters, assign an owner and test the control in the real workflow.
Where this lands for your team
A generic checklist cannot tell you whether a coding agent's permissions are appropriate for your particular repositories and release process. That takes a look at how the work actually happens. At CyberMentee, we're shaping an AI Development Security Health Check around that practical mapping: access, execution, review and the gaps worth fixing first. If this is a live question for your engineering team, I'd be interested to compare notes on your workflow.
The model is new. Least privilege isn’t.
Sources and further reading
Founder of CyberMentee. 15+ years of hands-on security work in banking, telecommunications and critical infrastructure, and 8 years teaching developers at Óbuda University and in his own courses. About the founder
