TL;DR: AI coding tools now span editors, IDE extensions, terminal agents, and cloud execution, giving developers more autonomy to inspect repositories, run commands, and return diffs for review, according to Braintrust. The governance challenge is no longer whether teams can use AI in development, but whether review, repository access, and evaluation controls keep pace with agentic execution.
At a glance
What this is: Braintrust's guide shows that AI coding tools are converging on agentic workflows, with the main risk sitting in how much repository access and execution autonomy teams allow before review.
Why it matters: IAM, PAM and software security teams need to align repo permissions, delegated execution and review gates because AI coding assistants can now act across the SDLC faster than traditional approval models.
Context
AI coding tools now sit inside the development workflow rather than beside it. That changes the governance problem from simple code assistance to delegated execution, where a tool can inspect repositories, edit files, run commands, and return changes for human review.
The security question is how much autonomy teams are willing to grant before the control boundary moves. In practice, the intersection with identity appears in repository access, permission modes, cloud agent execution, and the trust placed in machine-authored diffs before merge.
Key questions
Q: What breaks when AI coding agents are allowed to run Git operations on untrusted repositories?
A: The trust boundary breaks because the agent can trigger repository-local behaviour that was never meant to be safe by default. Malicious hooks, nested repositories, and injected instructions can turn a normal checkout into host-level code execution. That risk is highest when the workstation already contains tokens, source code, or internal access.
Q: Why do cloud-based coding agents increase governance risk for software teams?
A: Cloud execution weakens the link between the developer who delegated the work and the system that performed it. That matters because the agent may keep acting after the user has left, under permissions that outlive the original task. The risk is not just faster delivery, but longer-lived authority and weaker accountability for the changes the agent makes.
Q: What are the signs that AI data access is becoming too broad or misapplied?
A: Warning signs include broad or inherited permissions, retrieval paths that expose more data than the AI needs, and agents that can act on information they should only read. If security teams cannot explain why a connection exists, what data sits behind it, or where the output can go, the path is likely too permissive.
Q: How should teams govern agentic coding tools alongside existing IDE workflows?
A: Treat the tool as a governed execution path, not as a plug-in. Keep the repository access model, review rules and release criteria the same regardless of whether the work began in an editor, terminal or cloud agent. The objective is consistent authorisation and auditability across all coding surfaces, so workflow convenience does not create a policy exception.
Technical breakdown
Standalone editors, extensions and terminal agents create different control surfaces
AI coding tools do not all operate at the same layer. Standalone editors like Cursor and Devin Desktop place agentic work inside a primary workspace, IDE extensions such as GitHub Copilot inherit the existing development environment, and terminal agents like Claude Code or Codex can inspect repositories, run commands and return diffs asynchronously. Those differences matter because the security boundary shifts from what code is suggested to what code can be changed, executed and submitted without a developer sitting in the loop the whole time.
Practical implication: Map each tool to the exact control surface it can touch before you allow repository access or delegated execution.
Repository instructions and permission modes become governance controls
Agentic coding is governed less by model capability than by the permissions surrounding it. Repository instructions, hooks, subagents, and shared settings shape what the agent can see and change, while read-only defaults and permission prompts limit action until the user approves. That means the control point is not only the prompt or the model, but the repository policy, identity scope and task boundary that define which operations are allowed during an agent session.
Practical implication: Treat permission modes and repository instructions as policy controls, not convenience settings.
Cloud execution changes the review problem, not just the speed problem
When coding tools can continue in cloud environments, the traditional assumption that a developer is present for every meaningful change no longer holds. The review burden shifts to logs, test output, execution history and branch diffs, because the work may have happened after the developer delegated it. This is where code review and software supply chain thinking meet identity governance: the system that can act on a repository needs a bounded identity, a bounded scope and a traceable execution record.
Practical implication: Require auditable execution history and constrained repo scopes for any background or cloud task.
Threat narrative
Attacker objective: The likely objective is not direct exploitation but governance drift, where delegated coding pathways normalize broader repository access and weaker review discipline.
- Entry begins when a developer delegates repository work to an AI coding tool with broad workspace or cloud access.
- Credential and permission use follow when the tool inherits repository context, can run commands, or is allowed to act through shared settings and cloud agents.
- Escalation occurs when the agent can make multi-file changes, execute tests, and prepare pull requests with limited human intervention.
- Impact is unreviewed or insufficiently reviewed code reaching the main branch, along with the risk of stale permissions and overbroad repository access persisting across sessions.
Breaches seen in the wild
- CrewAI Uncrew GitHub token exposure: A CrewAI provisioning error exposed an admin GitHub token for all its private repositories; Noma reported it and CrewAI fixed it in hours.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic coding tools are turning repository access into a runtime governance problem. The article shows that the relevant control is no longer just who can open the repo, but what the tool can do once it is inside a task. That changes identity governance for software teams because machine-authored changes can now originate from delegated, background execution instead of a human session. Practitioners should govern tool authority as a privileged pathway, not a productivity feature.
Review is becoming a post-execution control, not the primary control. When tools can inspect code, run tests and return diffs asynchronously, human review happens after work has already been done. That means the decisive boundary is the permission set at task start, plus the quality of execution logs and branch controls at task end. Teams that still rely on manual review as the main safeguard are assuming the work remains human-paced when it increasingly is not.
AI coding autonomy creates a developer identity sprawl problem. Each tool can operate under different editor, terminal, cloud, and repository contexts, which makes it easy to lose sight of which identity acted where. This is where NHI governance intersects with software delivery: agent sessions, cloud runners, and delegated tasks all behave like identities with scope, lifespan and audit requirements. Practitioners should treat every agent workspace as a governed non-human identity.
Braintrust's own framing points to an evaluation gap, not just a tooling gap. The article notes that teams building AI features must evaluate what reaches production, which is the right instinct, but the real risk is letting implementation speed outrun measurement discipline. A coding tool that can generate change faster than review can absorb it needs test, log and experiment pipelines that are tied to release decisions. Practitioners should connect agentic coding to measurable deployment assurance, not ad hoc confidence.
Repository review and AI agent authorisation now need the same conversation. The strongest control issue in this article is the combination of agent autonomy and repository reach. If the environment allows cloud agents, task delegation and background execution, the organisation needs explicit rules for when a machine can act, what it can touch, and how that action is recorded. The practitioner conclusion is simple: agent authorisation must be explicit, bounded and auditable.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Agentic coding expands the control boundary from code suggestion to code execution. Teams should expect the most important policy questions to shift toward task scope, repository access and whether background agents are allowed to persist beyond a developer session. The programme impact is immediate: if your review model assumes synchronous human work, it will miss how these tools actually operate.
Developer autonomy now has a machine counterpart. The practical risk is not that AI writes code, but that it can also inspect, execute and package changes across several systems before a person reviews them. That makes agent authorisation, execution logging and branch-level gating the controls that need to mature first.
Braintrust's integrations reinforce a broader signal for practitioners. AI development workflows are moving toward environments where evals, logs and production evidence sit closer to the coding surface itself. Teams should prepare for a future in which release approval depends on whether an AI-generated change is traceable, testable and bounded, not simply whether it was reviewed.
For practitioners
- Define repository-scoped agent permissions Set explicit read, write and execute boundaries for every coding assistant, including cloud agents and terminal-based tools. Do not let editor convenience determine what the agent can access.
- Separate human review from agent execution Require that multi-file edits, command execution and pull request preparation happen under named workflow rules with a mandatory human approval step before merge.
- Inventory every AI coding surface List standalone editors, IDE extensions, terminal agents and cloud runners separately so repository access and telemetry requirements can be assigned per surface.
- Tighten cloud agent task boundaries For background tasks and remote execution, use short-lived credentials, constrained worktrees and logging that preserves the exact commands the agent ran.
- Tie agent output to evaluation evidence Require tests, evals and production logs to support any AI-generated change that reaches deployment, especially when the tool also powers AI features.
Key takeaways
- AI coding tools are no longer just suggestion engines. They now operate as delegated execution paths that can inspect repositories, run commands and hand back diffs.
- The governance problem is shifting from adoption to authorisation. Repository scope, permission modes and execution logs matter more as agentic workflows become normal.
- Teams that keep human review but ignore task boundaries will miss the real control point. The deciding factor is whether the agent's authority is bounded before it starts work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic coding tools act through delegated identity and repository privilege. |
| ASI02 — Tool Misuse | The article centres on tools that can run commands, edit code and act beyond simple suggestions. | |
| Recommendation — Bind every coding agent to least-privilege task scopes and review its effective permissions before execution. Constrain tool permissions so agent commands and file changes stay within an approved task boundary. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Cloud agents and delegated coding workflows depend on how repository and environment access is authenticated. |
| NHI-05 — Overprivileged NHI | The key risk is granting AI coding tools access broader than the task needs. | |
| Recommendation — Require strong authentication for every agent session and separate human credentials from machine access. Audit agent permissions and remove any repository or command access that exceeds the assigned task scope. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Repository access and delegated execution should be limited to the minimum needed for the task. |
| Recommendation — Apply least privilege to all AI coding agents and revoke broad repository rights by default. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Mis-scoped agents can pivot across repositories and use captured access to expand their reach. |
| Recommendation — Map agent sessions to credential access and lateral movement paths in your detection and review process. | ||
Key terms
- Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
- Repository-Scoped Access: Repository-scoped access is the practice of limiting a tool or user to only the codebases and actions needed for a specific task. In agentic workflows, it is the main boundary that prevents broad machine execution from becoming overprivileged access.
- Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
- Cloud Agent: A delegated automation that runs tasks in a remote environment instead of the developer's local machine. Cloud agents can continue after the editor closes, so their access scope, session boundaries, and rollback controls need to be managed like other privileged non-human identities.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for teams that need clearer control boundaries around machine identity, delegated access, and reviewable execution.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org