Notifications
Clear all
Topic starter
27/08/2026 2:11 pm
TL;DR: Coding agents are now writing more code, taking more actions, and operating across developer environments that AppSec teams were not built to monitor individually, according to GitGuardian. The practical problem is not only policy drift but enforceable control drift: teams need deterministic guardrails around credentials, egress, sandboxing, and action approval, or the lethal trifecta becomes a repeatable exposure pattern.
NHIMG editorial — based on content published by GitGuardian: Securing Coding Agents Across Your Team
Questions worth separating out
A: Security teams should separate the authority to request work from the authority to execute it, then scope each agent to the minimum repositories, tools, and pipeline stages needed for its task.
Q: Why do coding agents increase the risk of secret leakage?
A: Coding agents expand the places where a secret can be exposed, including chat logs, local files, terminal history, and provider retention.
Q: What breaks when agent tool access is governed only by guardrails?
A: Guardrails can shape model behaviour, but they do not reliably deny execution.
Practitioner guidance
- Standardise agent permission modes Define one approved set of permission defaults for IDE, CLI, and headless coding agents, then lock those defaults into policy-as-code so individual developers cannot weaken them ad hoc.
- Separate secrets detection from secrets exposure Place secrets scanning, sandboxing, and egress controls in the same workflow so an agent cannot both discover a credential and transmit it through an allowed channel without being blocked.
- Scope MCP server access like workload identity Require publisher verification, narrow tool scope, and short-lived credentials before allowing an MCP server into the development estate, especially where the server can touch production-adjacent data.
What's in the full article
GitGuardian's full whitepaper covers the operational detail this post intentionally leaves for the source:
- Standardised permission-mode patterns for IDE and CLI agents that can be deployed across a team.
- Action-level hooks and sandboxing guidance for reducing risky agent behaviour without relying on manual review.
- Publisher verification, scoped credentials, and OIDC patterns for MCP servers and headless agents.
- A team security checklist for coding agents, CI/CD pipelines, and credential hygiene.
👉 Read GitGuardian's guide on securing coding agents across your team →
Coding agents across IDEs and MCP servers: are controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
27/08/2026 2:12 pm
Coding-agent governance is now an NHI control problem, not a policy exercise. Once a non-human actor can read code, invoke tools, and transmit data, the security model has to move from human compliance to enforced runtime boundaries. Written rules help, but they do not stop secrets from being read or tools from being called. Practitioners should treat coding agents as governed non-human identities whose permissions must be constrained where the action occurs.
A few things that frame the scale:
- 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.
- Our research shows that organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
A question worth separating out:
Q: Who should own coding agent risk, AppSec or IAM?
A: Both, because the problem spans application workflow and identity governance. AppSec owns the runtime guardrails and detection points, while IAM owns the credential scope, lifecycle, and trust boundary. The article makes clear that coding agents cannot be safely managed by either team in isolation.
👉 Read our full editorial: Securing coding agents at team scale without expanding credential risk
