AI Agent Security · Software delivery
Coding Agent Security: When an Agent Can Change Production
A coding agent has three capabilities that rarely sit together in one identity: it writes code, it triggers pipelines, and it frequently holds cloud credentials. That combination deserves more than a code review.
The short answer
Coding agent security means separating the capabilities a coding agent tends to accumulate — repository write, pipeline trigger, dependency addition, secret access, infrastructure change and production deploy — so that no single agent identity holds a path from generated text to production effect without a human decision in between. The failure is rarely malicious code. It is an agent with more authority than anyone intended, exercised faster than review can absorb.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸The risk is authority accumulation, not bad code. A coding agent that can commit, trigger a pipeline and hold a deploy credential has a direct path from text to production.
- ▸Human review degrades as a control when volume rises. Ten thoughtful reviews a day is a control; sixty perfunctory approvals is a formality with a git trail.
- ▸Separate the eight capabilities across identities. Propose and merge must not be the same identity, and neither should hold production credentials.
- ▸Generated code introduces dependencies. Every added package is a supply-chain decision, and agents add them without the hesitation a human feels.
- ▸Pipelines are the highest-value target: an agent that can modify pipeline configuration can grant itself everything the pipeline can do.
Source: Mark Alex, Real Biz Digital — Coding Agent Security: When an Agent Can Change Production (https://realbizdigital.net/insights/coding-agent-security/). Reproduce with attribution.
Key takeaways
- 01Never let the same identity author and merge. That single separation removes most of the realistic damage paths.
- 02Keep production credentials out of the agent entirely. Agents propose deploys; pipelines with their own identity execute them.
- 03Treat pipeline configuration as a protected path requiring human approval, regardless of what else the agent may change.
- 04Gate dependency additions on a policy check: provenance, age, maintainer count, and whether an approved equivalent already exists.
- 05Scan agent output for secrets before commit, not after push. Post-push detection means rotation, which nobody does cheerfully.
- 06Measure review depth, not review count. Approvals under thirty seconds on diffs over two hundred lines are a metric worth watching.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What makes coding agents a distinct security problem?
- They accumulate capabilities that are normally separated: writing code, triggering builds, adding dependencies, reading secrets and sometimes deploying. One identity holding all of them has a direct path to production.
- Is code review sufficient?
- Not at agent volume. Review effectiveness falls as diff count rises, and agents generate diffs far faster than reviewers absorb them, so review becomes a formality rather than a control.
- What is the single most important separation?
- Author and merge must be different identities. An agent that can approve its own change has no meaningful constraint on what reaches the main branch.
- Should coding agents hold cloud credentials?
- No. Agents should propose infrastructure changes; a pipeline with its own identity and its own approval gates should execute them.
- What about dependencies the agent adds?
- Gate them on policy: provenance, package age, maintainer count, licence, and whether an approved equivalent already exists in the estate.
- Why are pipelines the highest-value target?
- Because an agent that can modify pipeline configuration can grant itself everything the pipeline can do, which is usually more than the agent was ever given.
- What detections matter most?
- Pipeline configuration changes by an agent, secret-shaped strings in generated diffs, dependency additions, and approvals faster than a human could have read the diff.
The real risk is authority accumulation
Ask what a coding agent can do, then ask what it can cause. The second list is longer, and it is the one that matters.
A coding agent typically starts with repository read and a branch. Then it needs to run tests, so it gets pipeline trigger. Then the tests need a database, so it gets a connection string. Then someone automates the deploy step because the human step was the bottleneck. Each addition is individually reasonable and locally justified.
The end state is one identity that can write code, cause that code to be built, and cause the build to reach production. No individual permission looks alarming. The composition is a direct path from generated text to production effect with no human decision in it.
Key facts
- ▸Rows three, five and eight are the ones that convert a productive assistant into an unbounded actor. They should each require a separate identity and a human decision.
- ▸Row five is the most under-appreciated. Pipeline configuration is code that runs with the pipeline’s authority, which is usually broader than any agent’s.
- ▸Row seven combined with any outbound-capable tool is an exfiltration path that no code review will catch, because the code that reads the secret is legitimate.
| Capability | Typical justification | What it enables in combination |
|---|---|---|
| Repository read | Understand the codebase | Reconnaissance across every secret ever committed |
| Branch write | Propose changes | Nothing alone — the safe baseline |
| Main branch write or merge | Reduce review friction | Unreviewed code reaching the deployable branch |
| Pipeline trigger | Run tests | Executing arbitrary code in the CI environment |
| Pipeline configuration write | Fix broken builds | Granting itself everything the pipeline can do |
| Dependency addition | Implement features | Introducing a supply-chain path nobody assessed |
| Secret access | Integration tests | Exfiltration through any outbound-capable tool |
| Deploy or infrastructure change | Automate delivery | Direct production effect from generated text |
The design principle: no single agent identity should hold a path from proposal to production effect. Where the path exists, a human decision has to sit in it.
Why review stops working at agent volume
Code review is a genuinely effective control at human volume. It is worth being precise about why it degrades, because the answer determines what replaces it.
- ›10-20 diffs per reviewer per day
- ›Author present to answer questions
- ›Reviewer has context on why
- ›Diffs are small and intentional
- ›Effectiveness: high
- ›50-200 diffs per reviewer per day
- ›Author is a process, not a colleague
- ›Context arrives only in the description
- ›Diffs are large and mechanically complete
- ›Effectiveness: falls sharply
- 01Measure approval latency against diff size. Approvals under thirty seconds on diffs over two hundred lines are not reviews, and the distribution tells you honestly whether review is still functioning.
- 02Replace breadth with targeting. Automated gates handle the mechanical properties; humans review the changes that touch protected paths, security-relevant code and pipeline configuration.
- 03Require a change rationale the agent must produce and a human must accept. A description of intent is what a reviewer needs and what a diff cannot supply.
- 04Cap diff size for agent-authored changes. A five-hundred-line agent diff is unreviewable in practice, and splitting it is cheap for an agent.
- 05Make protected paths explicit in the repository: pipeline configuration, authentication code, dependency manifests, infrastructure definitions, migration scripts.
- 06Track the ratio of agent-authored to human-reviewed lines over time. When it climbs past a point your team can absorb, add gates rather than reviewers.
The goal is not to review less. It is to spend the review capacity you have on the changes where a human judgement is the only available control.
Dependencies, secrets and the paths generated code opens
Key facts
- ▸Scan before commit rather than after push. Post-push detection means the secret is in history and rotation is mandatory, which is a slow and unpopular remediation.
- ▸SLSA provenance is a useful frame for dependency intake, because the question “where did this artefact come from and can I verify it” is exactly the question an agent will not ask.
- ▸Protected paths need enforcement outside the agent’s reach. A rule the agent can modify is a suggestion.
- Dependency addition
- Agents add packages without the hesitation a human feels, and without the tacit knowledge that a given ecosystem has typosquatting problems. Gate additions on provenance, package age, maintainer count, download history, licence, and whether an approved equivalent already exists internally.
- Transitive expansion
- One added package can pull in dozens. Policy should evaluate the resulting dependency delta, not just the named package, because the named package is rarely the risk.
- Secret exposure in generated code
- Agents reproduce patterns, including the pattern of an inline credential. Scan diffs for secret-shaped strings before commit, in the agent’s own path, so the finding is a rejection rather than a rotation.
- Secret access for tests
- Integration tests need credentials, and credentials given to an agent are readable by an agent. Use short-lived, scope-limited test credentials against non-production data, never production secrets.
- Generated infrastructure definitions
- Terraform or Kubernetes manifests are code whose effect is infrastructure. Treat them as a protected path, and validate against policy for public exposure, over-broad IAM and missing encryption before they reach a pipeline.
- Pipeline injection
- A modified workflow file executes with the pipeline’s authority. This is the highest-severity path in the list and the one that fully bypasses every other control, because the pipeline can usually do more than the agent.
Notice that four of these six are supply-chain concerns rather than code-quality concerns. Code review is not the control for any of them.
A five-level permission ladder for coding agents
| Level | Requires before granting | Detections that must be live |
|---|---|---|
| L1 | Repository access audit; secret scanning in the agent path | Secret-shaped strings in diffs |
| L2 | Isolated CI environment; ephemeral credentials | Pipeline runs by agent identity; egress from CI |
| L3 | Dependency policy; migration review path | Dependency additions and transitive delta |
| L4 | Protected paths enforced outside agent reach; rationale requirement | Approval latency versus diff size; protected-path attempts |
| L5 | — | — |
The line to defend is between L4 and L5. Once an agent identity can cause a production change without a human decision, every other control on this page is advisory.
Detections specific to agent-authored change
- 01Pipeline configuration modified by an agent identity. Highest-severity detection in this domain. Should page, not queue.
- 02Secret-shaped string in a diff. Entropy plus known-format matching, run in the agent’s path before commit and again at the push gate.
- 03Dependency addition with a transitive delta above a threshold. One package pulling in forty is a decision someone should make deliberately.
- 04Approval faster than reading time. Approval latency below a floor derived from diff size — a proxy for review becoming a formality, and a useful conversation with the team rather than an accusation.
- 05Protected-path change attempt. Even when correctly blocked, an agent repeatedly attempting to modify authentication code or infrastructure definitions is a signal about its instructions.
- 06Outbound network from the CI environment during an agent-triggered run. Builds that suddenly reach the internet are either a new dependency mirror or an exfiltration attempt, and both are worth knowing about.
- 07Commit volume anomaly. A step change in an agent’s commit rate usually means its scope changed, and scope changes should be deliberate.
Most of these are cheap because the events already exist in your source control and CI logs. The gap is almost never data availability; it is that nobody has written the rule.
Three configurations to remove today
Mistake
One identity that authors and merges
The agent opens a pull request and approves it, usually justified as removing a bottleneck during a pilot that was never revisited.
Instead: Separate identities, with merge requiring a human acceptance of the rationale. This single change removes most realistic damage paths and costs a few minutes per change.
Mistake
Production credentials in the agent’s environment
Given for a deploy step or an integration test, then never removed. The agent can now read them, and any outbound-capable tool becomes an exfiltration path that no code review will catch.
Instead: Ephemeral, scope-limited, non-production credentials for tests. Production deploys execute under the pipeline’s own identity behind an approval gate.
Mistake
Pipeline configuration in the agent’s writable set
Permitted so the agent can fix broken builds. It can now modify the file that defines what the pipeline is allowed to do, which is usually more than the agent is allowed to do.
Instead: Protected path, enforced by branch protection outside the agent’s reach, with human review required on every change regardless of size.
Next step
Put a decision point between proposal and production
BarzelVault evaluates the action before it executes — including deploys, migrations and infrastructure changes — with approval binding and tamper-evident records, so the human decision is enforced rather than assumed.
What this does not address
Three honest boundaries.
- 01It says nothing about whether generated code is correct. Correctness is a testing and design problem, and these controls constrain blast radius rather than quality.
- 02It assumes source control and CI are the delivery path. Agents operating on a developer’s machine with local credentials sit outside all of it, and that is the harder problem.
- 03Protected-path enforcement depends on branch protection that the agent genuinely cannot alter. Verify that, specifically, rather than assuming the configuration is as intended.
Frequently asked questions
What makes coding agent security different from ordinary application security?
The concentration of authority in one identity. A coding agent typically ends up able to write code, trigger pipelines, add dependencies, read secrets and sometimes deploy, which together form a direct path from generated text to production effect with no human decision in it.
Is code review enough to control AI coding agents?
No, because review effectiveness falls as diff volume rises. Ten to twenty thoughtful reviews a day is a control; fifty to two hundred perfunctory approvals is a formality with a git trail. Review capacity should be targeted at protected paths rather than spread across everything.
What is the most important separation for coding agents?
Author and merge must be different identities. An agent that can approve its own pull request has no meaningful constraint on what reaches the deployable branch, and this single separation removes most realistic damage paths.
Should a coding agent hold production credentials?
No. Use ephemeral, scope-limited, non-production credentials for tests, and have production deploys execute under the pipeline’s own identity behind an approval gate. Credentials in an agent’s environment are readable by the agent and exfiltratable through any outbound-capable tool.
Why is pipeline configuration the highest-value target?
Because pipeline configuration is code that executes with the pipeline’s authority, which is normally broader than the agent’s. An agent able to modify a workflow file can grant itself everything the pipeline can do, bypassing every other control.
How should dependency additions by agents be controlled?
Gate them on policy covering provenance, package age, maintainer count, download history, licence and whether an approved internal equivalent exists — and evaluate the transitive delta rather than just the named package, since one addition can pull in dozens.
How do I stop agents committing secrets?
Scan for secret-shaped strings — entropy plus known-format matching — inside the agent’s own path before commit, and again at the push gate. Scanning only after push means the secret is in history and rotation becomes mandatory.
What permission level should a new coding agent start at?
Read and propose: repository read, branch write and pull request creation, with no pipeline access and no secrets. Escalate deliberately through test execution, dependency proposals and gated merge, and never grant direct production change.
What detections are specific to agent-authored change?
Pipeline configuration modified by an agent identity, secret-shaped strings in diffs, dependency additions with a large transitive delta, approvals faster than plausible reading time for the diff size, protected-path change attempts, unexpected outbound network from CI, and commit volume step changes.
How do I measure whether review is still working?
Plot approval latency against diff size. A cluster of sub-thirty-second approvals on diffs over two hundred lines indicates review has become a formality, which is a signal to add automated gates rather than to add reviewers.
Should agent diffs be size limited?
Yes. Large agent-authored diffs are unreviewable in practice, and splitting work into smaller changes is cheap for an agent and expensive for a human, so the constraint costs little and restores review effectiveness.
What about agents running on a developer’s local machine?
That is the harder case and sits outside repository and CI controls entirely, because the agent inherits the developer’s local credentials and network access. Treat local agent use as a separate risk with its own policy rather than assuming pipeline controls cover it.
Glossary
- Authority accumulation
- The gradual concentration of separately-justified permissions in one agent identity, creating a path nobody designed.
- Protected path
- A file or directory whose modification requires human review regardless of change size, enforced outside the agent’s reach.
- Pipeline injection
- Modifying build configuration so that attacker- or agent-controlled code executes with the pipeline’s authority.
- Transitive delta
- The full set of dependencies introduced by adding one package, including indirect ones.
- Ephemeral credential
- A short-lived, scope-limited secret issued for a single run and unusable afterwards.
- Review degradation
- The measurable fall in review effectiveness as diff volume per reviewer rises.
- Change rationale
- An agent-produced statement of intent that a human must accept, supplying the context a diff cannot.
- Self-merge
- An identity approving and merging its own change, the most common damaging misconfiguration.
- Secret-shaped string
- A value matching entropy or known credential formats, detected in diffs before commit.
- Permission ladder
- A graduated sequence of capability grants, each with prerequisites and required detections.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · OpenSSFSLSA — Supply-chain Levels for Software Artifacts ↗Provenance and reproducibility framing for third-party server intake.
- 02 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 03 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 04 · OWASPOWASP Application Security Verification Standard ↗Input-validation, authorization and logging requirements restated here in MCP terms.
- 05 · MITRECWE-78 — OS Command Injection ↗What happens when an unbounded string parameter reaches a shell.
- 06 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 07 · ISOISO/IEC 27001 — Information security management ↗The ISMS baseline that agent-layer controls have to fit inside rather than beside.
- 08 · SemVerSemantic Versioning 2.0.0 ↗The versioning contract tool schemas should honour but frequently do not.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). Coding Agent Security: When an Agent Can Change Production. Real Biz Digital. https://realbizdigital.net/insights/coding-agent-security/
Try the mechanics on a live server
To see what a tool-call envelope actually looks like before you write a policy that has to decide about one — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelVault is the pre-execution decision point, sold as a running product
Nine tools, 12 static resources, 3 resource templates and 9 prompts. Four deterministic outcomes — allow, deny, dry-run, require approval — with approval workflow, hash-chained audit and guardrail data protection. Streamable HTTP, JSON-RPC 2.0.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Dev | Free | 10,000 policy decisions/mo · 9 tools, 4 outcomes, hash-chained audit | A first regulated workflow: one agent, one high-consequence system |
| Team | $199/mo | 75,000 decisions/mo · approval workflow, spend and action limits | Several agents acting on money, records or customer-visible systems |
| Business | $799/mo | 750,000 decisions/mo · exact HTTPS execution, credential isolation, emergency controls | Enterprise-wide pre-execution enforcement under audit |
| Enterprise | $3,999/mo | 5,000,000 decisions/mo · everything in Business, scaled | Group-wide rollout across many teams and systems |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.