DEF CON 34 — Part 5 of 13

Why coding agents fundamentally change endpoint and DevSecOps risk

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For years, security teams have treated the developer workstation as a privileged endpoint.

That was already justified.

A developer laptop may contain source code, Git credentials, SSH keys, cloud CLI sessions, Kubernetes contexts, package-registry tokens, CI/CD access, signing material, internal documentation and credentials cached by development tools.

But something important has changed.

The workstation is no longer merely where a developer uses those privileges.

Increasingly, it contains software capable of exercising them on the developer’s behalf.

Coding agents can read repositories, interpret instructions, execute shell commands, modify files, install dependencies, invoke APIs, interact with Git, connect to MCP servers and sometimes initiate deployment workflows.

This creates a fundamentally different endpoint.

The developer workstation is becoming an agent control plane.

And that changes its threat model.

From privileged endpoint to delegated execution environment

Traditional endpoint security assumes a relatively understandable chain of authority:

Human → Application → Operating System → Resource

The human initiates an action.

The application executes it.

Endpoint controls attempt to determine whether that execution is legitimate.

Coding agents introduce another decision-making layer:

Human → Agent → Context → Reasoning → Tool → Identity → Resource

The developer may initiate only the first step.

Everything after that can increasingly be determined by the agent.

That difference matters because the agent does not operate in isolation.

It operates inside an environment already saturated with authority.

A developer workstation may simultaneously possess:

• GitHub or GitLab authentication
• SSH private keys
• cloud CLI credentials
• Kubernetes contexts
• package-registry tokens
• CI/CD permissions
• local source-code access
• internal documentation
• API credentials
• infrastructure-as-code repositories
• access to development databases
• privileged browser sessions

Now add:

• coding agents
• MCP servers
• agent Skills
• hooks
• repository instructions
• local tools
• project-specific agent configuration

The result is not simply a laptop with an AI assistant.

It is an orchestration environment capable of translating natural-language context into actions across multiple enterprise control planes.

That is why the security question is no longer merely:

Can an attacker compromise the developer workstation?

It is also:

Can an attacker influence something the agent trusts sufficiently to make the workstation compromise itself?

The Repository Has Changed

Consider one of the most ordinary developer activities imaginable:

git clone repository
        ↓
open project
        ↓
ask coding agent to understand or modify it
        ↓
agent consumes repository context
        ↓
agent invokes tools
        ↓
tools execute under developer authority

Nothing in this sequence looks inherently suspicious.

That is precisely the problem.

The repository has traditionally been treated primarily as a collection of software artifacts.

Source code.

Configuration.

Documentation.

Build files.

Tests.

Dependencies.

But coding agents consume repositories differently from traditional development tools.

They may interpret parts of the repository as instructions.

Files such as AGENTS.md, CLAUDE.md, Skills, setup instructions and tool configurations can influence what an agent believes it should do.

Research published in 2026 has already documented how ordinary project-setup material—including README files, requirements files and Makefiles—can steer coding agents toward malicious package sources, vulnerable versions or plausible but incorrect dependencies. The important finding is that security behavior varies not simply by model, but by the combination of model and agent harness. (⁠arXiv)

The repository therefore occupies several roles simultaneously.

It is:

Code.

Data.

Configuration.

Documentation.

And increasingly:

Agent policy.

That last category changes everything.

When Context Crosses the Execution Boundary

This is where the compositional-security argument of this series becomes particularly visible.

A malicious repository instruction does not necessarily require a traditional vulnerability.

It does not need memory corruption.

It does not need an exploit against the coding agent itself.

It may simply need to become trusted context.

The chain can look like this:

Attacker-controlled repository
        ↓
Agent instruction / Skill / configuration
        ↓
Coding agent interprets context
        ↓
Agent chooses an apparently legitimate tool
        ↓
Tool executes locally
        ↓
Developer credentials become reachable
        ↓
Cloud / Git / CI/CD action

Each individual component can appear to be working correctly.

Git cloned the repository correctly.

The agent read the repository correctly.

The shell executed the requested command correctly.

The cloud CLI authenticated correctly.

IAM correctly recognized the developer.

The CI/CD platform correctly accepted an authorized request.

And the organization was still compromised.

This is compositional security failure in almost pure form.

The weakness exists in the relationship between trusted systems.

The Dangerous New Property: Identity Inheritance

Coding agents usually do not require attackers to steal a completely new identity.

They can inherit one.

If an agent runs on a developer workstation, the effective authority available to it may include whatever the developer environment already exposes.

Consider:

Developer
    │
    ├── Git credentials
    ├── SSH keys
    ├── AWS / Azure / GCP sessions
    ├── Kubernetes contexts
    ├── package registry credentials
    ├── CI/CD tokens
    └── internal APIs
             ↓
        Coding Agent
             ↓
           Tools

The agent does not necessarily possess these identities as formally assigned IAM principals.

That distinction can create dangerous blind spots.

An IAM inventory might show:

Developer Alice has access to Repository X and Development Subscription Y.

But the operational reality may be:

Anything capable of causing Alice’s coding environment to execute the right sequence of commands can potentially exercise part of Alice’s authority.

This is inherited authority.

And it means that traditional IAM analysis can underestimate agent privilege.

The relevant question becomes:

What authority can the agent cause to be exercised from the environment in which it runs?

That is a much larger attack surface.

The Skill Problem

Agent Skills make this problem even more interesting.

Skills package instructions and capabilities that allow coding agents to perform specialized workflows.

Conceptually, that is extremely useful.

Instead of repeatedly explaining how an organization builds, tests, deploys or reviews software, those procedures can become reusable agent capabilities.

But reusable capability is also reusable authority.

Datadog Security Labs demonstrated a particularly important property of this model: project-level Skills can arrive with a cloned repository, and dynamic-context commands can execute before the rendered Skill content is even presented to the model. In such a case, model-level defenses may never have an opportunity to recognize the malicious instruction. (⁠Datadog Security Labs)

This creates an uncomfortable architectural lesson.

We tend to imagine the model as the security decision point:

Untrusted content
      ↓
     Model
      ↓
Safety reasoning
      ↓
    Action

But some agent architectures can contain execution paths closer to:

Untrusted artifact
      ↓
Agent framework
      ↓
Dynamic context / hook
      ↓
Local execution
      ↓
     Model

The security boundary moved.

And the organization may not have noticed.

This is why securing the model alone cannot secure the development agent.

The Scale Problem Is Already Visible

This is not merely a hypothetical future in which developers eventually accumulate large agent ecosystems.

That ecosystem is already emerging.

Snyk’s 2026 telemetry across nearly 10,000 developer environments found that just over half of scanned developers had live MCP server connections. Among developers using MCP servers, roughly one in twelve had a high- or critical-severity finding. Its dataset also found developers averaging 18 installed Skills, with some environments reaching 135. (⁠Snyk)

Those numbers matter less as universal benchmarks than as an architectural signal.

The developer endpoint is accumulating a new software supply chain:

IDE
 +
Coding Agent
 +
MCP Servers
 +
Skills
 +
Plugins
 +
Repository Instructions
 +
Hooks
 +
External Context

Most enterprises already have mature processes for approving endpoint software.

Far fewer can currently answer:

• Which MCP servers are running across our developer fleet?
• Which Skills are installed?
• Which repositories can introduce agent configuration?
• Which tools may agents invoke?
• Which commands can those tools execute?
• Which identities are available when they execute them?

That is an inventory problem before it is even a vulnerability problem.

Repository Trust Is Becoming Endpoint Trust

This produces one of the most important implications for DevSecOps.

Historically, cloning an untrusted repository was usually considered substantially safer than executing its code.

That assumption is weakening.

If opening a repository causes an agent to discover instructions, load configuration, activate Skills, start MCP components or execute setup workflows, then the act of bringing the repository into the development environment becomes security-relevant.

The trust relationship begins earlier.

The security boundary therefore shifts from:

Don’t execute untrusted code

toward:

Don’t allow untrusted context to control trusted execution.

That is a much harder policy to enforce.

Because developers are supposed to consume external context.

They investigate open-source projects.

Review pull requests.

Reproduce bugs.

Analyze malware.

Test dependencies.

Inspect customer code.

Evaluate proof-of-concepts.

Security researchers do this even more aggressively.

Agentic development turns these perfectly legitimate activities into potential authority-crossing events.

A Pull Request Can Become an Input to Privilege

Consider another normal workflow.

A developer receives a pull request.

The developer asks the coding agent:

Review this change and run whatever tests are necessary.

The developer believes they have delegated code review.

Operationally, they may have delegated something much larger:

Untrusted contributor
        ↓
Pull request
        ↓
Repository context
        ↓
Coding agent
        ↓
Shell / Git / MCP / package manager
        ↓
Developer workstation
        ↓
Enterprise identity

The attacker’s input and the organization’s authority have become connected by an interpreter capable of taking action.

This resembles the semantic-execution problem discussed in Part 1 of this series.

But here the consequences are amplified because the execution environment belongs to a developer.

The input does not merely influence an AI response.

It can potentially influence a machine containing some of the organization’s most valuable credentials.

Why EDR Is Necessary — And Insufficient

It might be tempting to classify this entirely as an endpoint-security problem.

EDR certainly matters.

If an agent launches suspicious processes, accesses credential stores, creates persistence or connects to malicious infrastructure, endpoint telemetry may detect parts of the attack.

But EDR sees execution.

It does not necessarily understand why the execution occurred.

Imagine:

claude
  ↓
bash
  ↓
git
  ↓
az
  ↓
API call

Every binary may be legitimate.

Every process may be signed.

Every authentication may succeed.

Every API call may be syntactically valid.

The anomaly exists in the causal chain.

Why did the agent run the command?

Which repository instruction influenced it?

Which Skill was active?

Which MCP server supplied context?

Which user request initiated the workflow?

Which identity was subsequently exercised?

Traditional endpoint telemetry was not designed to reconstruct this semantic provenance.

Agentic endpoints therefore require another observability layer:

Agent execution provenance.

We Need to Know Why the Tool Ran

For sensitive agent actions, logging only the resulting process is insufficient.

Security teams increasingly need a chain resembling:

Human request
    ↓
Agent session
    ↓
Context sources
    ↓
Instruction source
    ↓
Agent decision
    ↓
Tool invocation
    ↓
Process execution
    ↓
Identity used
    ↓
Resource affected

This does not mean logging private model reasoning.

It means recording security-relevant causality.

For example:

• which repository was active
• which configuration files were loaded
• which Skills were available
• which MCP servers were connected
• which tool was invoked
• which command or API operation resulted
• which identity authorized it
• which destination was affected

Without this correlation, security teams may see an authorized developer making an authorized change while completely missing that the developer never intended the action.

That distinction will become increasingly important.

PAM Has to Expand Beyond Humans

This leads directly into privileged-access management.

PAM traditionally revolves around questions such as:

Who receives privileged access?

For how long?

To which resource?

Was the session approved?

Was the activity recorded?

But consider an engineer with production Kubernetes privileges who uses a coding agent.

The human may be strongly authenticated.

The access may be just-in-time.

The session may last only 30 minutes.

Yet during those 30 minutes, the coding agent can potentially operate inside the same authority envelope.

PAM therefore needs another question:

What software may exercise the privilege once the human has obtained it?

That question becomes particularly important for:

• production cloud administration
• Kubernetes administration
• secrets management
• infrastructure-as-code
• CI/CD administration
• signing environments
• release engineering

A privileged human session increasingly implies a potentially privileged agent session.

Those should not automatically be equivalent.

Separate Human Authority from Agent Authority

The cleaner architecture is to stop allowing agents to inherit arbitrary developer authority.

Instead:

Developer Identity
        │
        ├──────── Human actions
        │
        ▼
   Developer tools


Agent Identity
        │
        ├──────── Explicitly permitted actions
        │
        ▼
   Controlled tools

The agent should ideally possess an identifiable security principal of its own.

Its permissions should be narrower than the developer’s.

Its actions should be attributable.

Its credentials should be ephemeral.

And sensitive operations should pass through independent policy enforcement.

That allows the organization to say:

Alice may administer the production cluster.

without automatically implying:

Every coding agent running inside Alice’s environment may administer the production cluster.

This is the agentic equivalent of eliminating shared administrator accounts.

The Developer Workstation Needs Internal Trust Zones

There is another architectural consequence.

We have spent years segmenting networks.

Agentic development suggests we may need to segment developer execution environments more aggressively as well.

Consider three trust levels.

Zone 1 — Untrusted Context

Repositories, pull requests, documentation, tickets and external content that have not been trusted.

Agents operating here should have extremely limited execution authority.

No production credentials.

No unrestricted cloud sessions.

No sensitive MCP connections.

Potentially isolated containers or disposable environments.

Zone 2 — Development Authority

Trusted internal development repositories and normal engineering workflows.

Agents may compile, test, modify files and interact with development infrastructure.

But their cloud and CI/CD permissions remain constrained.

Zone 3 — Privileged Operations

Production deployment, secrets access, signing, infrastructure administration and other high-impact operations.

Agent access should require separate authorization and independent policy enforcement.

The important principle is:

Context trust and authority should increase together only deliberately.

Today they often do not.

A developer can move from an unknown GitHub repository to a production terminal within seconds while retaining the same credentials, agent process and local environment.

That is an enormous trust-boundary collapse.

Treat Agent Configuration Like Executable Code

Organizations should also reconsider what deserves security review inside repositories.

Historically, CODEOWNERS rules might protect:

.github/workflows/
terraform/
deployment/
security/

Agentic development adds new sensitive surfaces.

Changes to:

AGENTS.md
CLAUDE.md
.claude/
Skills
MCP configuration
agent hooks
tool definitions
IDE agent rules
setup instructions

may deserve heightened review.

Not because every instruction is malicious.

But because these files can influence systems capable of execution.

This is conceptually similar to the evolution of CI/CD security.

A YAML file once looked like configuration.

Then organizations realized:

This configuration causes privileged infrastructure to execute commands.

So pipeline configuration became security-sensitive code.

Agent configuration is moving through the same transition.

A New DevSecOps Control Point

This suggests a new security gate.

Before an agent consumes repository-specific instructions, the organization should be able to establish their provenance and trust.

Something like:

Repository enters environment
        ↓
Agent configuration discovered
        ↓
Trust classification
        ↓
Policy evaluation
        ↓
Allowed capabilities assigned
        ↓
Agent execution

The capabilities available to the agent should depend on the trust classification of the context.

An unknown external repository might receive:

READ: repository
ACT: isolated filesystem
NETWORK: restricted
CREDENTIALS: none
MCP: none

A trusted internal repository might receive broader development permissions.

Production actions would remain separately gated.

This is much closer to zero trust than simply asking developers to approve commands one by one.

“Allow This Command?” Is Not a Security Architecture

Many coding agents attempt to mitigate dangerous actions by asking the developer for confirmation.

That helps.

But it should not become the primary control.

Developers using coding agents repeatedly see requests to:

run tests,

install packages,

modify files,

execute shell commands,

access directories,

connect to tools.

The more frequently approval is required, the more routine approval becomes.

Eventually the user is no longer evaluating the semantic consequence of the command.

They are clearing friction.

That creates the same structural problem we have already seen with MFA fatigue.

And it foreshadows a topic we will examine later in this series:

Human approval itself can become an attack surface.

The CISO Ownership Problem

Perhaps the most uncomfortable organizational question is who owns this risk.

Endpoint Security?

Yes.

Because execution occurs on endpoints.

PAM?

Yes.

Because developer identities and privileged credentials are involved.

Application Security?

Yes.

Because repositories and development workflows provide the input.

Cloud Security?

Yes.

Because agents can invoke cloud tools.

Software Supply Chain Security?

Yes.

Because repository configuration, packages and Skills can propagate attacker influence.

AI Security?

Obviously.

But assigning the problem to all of them can easily mean that none of them owns the complete attack path.

That is precisely why compositional security matters.

The risk exists between existing security domains.

A useful governance model therefore needs one accountable view of:

Repository
    ↓
Agent
    ↓
Tool
    ↓
Developer Identity
    ↓
CI/CD
    ↓
Cloud
    ↓
Production

Every arrow is a trust relationship.

Every relationship needs an owner.

What CISOs Should Ask Now

The immediate questions are surprisingly practical.

Inventory

Do we know which coding agents are installed across developer endpoints?

Do we know which MCP servers, Skills, plugins and agent extensions they use?

Identity

Do agents inherit developer credentials?

Can we distinguish human-initiated actions from agent-initiated actions?

Repository Trust

Can external repositories introduce agent instructions, Skills, hooks or configuration?

Are changes to those files security-reviewed?

Execution

Can agents execute arbitrary shell commands?

Can they install packages?

Can they start local services?

Can they modify Git configuration?

Cloud

Can an agent reach active AWS, Azure or GCP sessions?

Can it use Kubernetes contexts?

Can it invoke infrastructure-as-code deployment tools?

CI/CD

Can agent actions trigger builds, releases or deployments?

Can they modify pipeline configuration?

Isolation

Can untrusted repositories be opened inside disposable development environments?

Can agent execution be sandboxed separately from the developer’s privileged environment?

Detection

Can the SOC correlate agent activity with endpoint processes, Git activity, cloud identities and CI/CD events?

If the answer to most of these questions is unknown, the organization does not yet know the effective privilege of its coding-agent estate.

A Minimum Enterprise Control Model

A practical control model can begin with five requirements.

1. Discover the Agent Estate

Inventory coding agents, MCP servers, Skills, plugins and agent configuration across managed developer environments.

Agent infrastructure should not remain shadow IT simply because it runs inside an IDE or terminal.

2. Isolate Untrusted Context

External repositories and unknown code should enter disposable or constrained environments before agents receive access to them.

The less trusted the context, the less authority the agent should possess.

3. Separate Agent and Developer Identity

Where technically possible, agents should receive dedicated, narrowly scoped credentials rather than silently inheriting everything available to the human.

4. Protect Agent Configuration

Repository instructions, Skills, MCP configuration, hooks and similar files should be treated as security-sensitive artifacts and protected through review and provenance controls.

5. Correlate the Entire Execution Chain

Detection should connect:

repository + agent + tool + process + identity + CI/CD + cloud

because observing those components independently hides the attack path.

The Larger Lesson

The developer workstation has always been dangerous because developers possess extraordinary access.

Coding agents amplify that danger in a subtle way.

They add an interpreter between attacker-controlled context and enterprise authority.

That interpreter can read.

Reason.

Choose.

Execute.

And it operates inside an environment already trusted by much of the enterprise.

The security model therefore cannot remain:

Protect the developer’s credentials.

It has to become:

Protect every path capable of causing those credentials to be exercised.

That distinction is central to compositional security.

A developer may never intentionally execute malicious code.

A coding agent may never itself be compromised.

The cloud identity may never be stolen.

The CI/CD system may never contain a vulnerability.

And yet an attacker may still traverse the entire chain.

Malicious Context
      ↓
Coding Agent
      ↓
Trusted Tool
      ↓
Developer Identity
      ↓
Enterprise Control Plane

No single component has to fail catastrophically.

The composition is enough.

The CISO Takeaway

The developer workstation is becoming one of the first places where the consequences of agentic computing become operationally unavoidable.

It is simultaneously an endpoint, an identity environment, a software factory, a cloud administration console and now an autonomous execution environment.

Security architecture has to reflect that convergence.

Coding-agent security cannot live exclusively inside AI governance.

It belongs inside Endpoint Security.

It belongs inside PAM.

It belongs inside DevSecOps.

It belongs inside Software Supply Chain Security.

And above all, it belongs inside attack-path governance.

Because the real privilege of a coding agent is not defined by what the model itself can do.

It is defined by what the environment around it can be persuaded to do.

Core thesis:

The coding agent inherits the blast radius of the developer workstation.

And as developer workstations become agent control planes, securing the endpoint will increasingly mean securing the chain from context to authority to execution.

Next in the series: Part 6 — Cloud Automation Is the New Persistence Layer — why short-lived credentials were supposed to make cloud compromise less durable.

But what happens when the attacker does not steal the credential?

What happens when they compromise the mechanism that creates it?

Part 6 examines why CI/CD systems, workload identities, serverless functions, ephemeral build agents and automated credential issuance are creating a new persistence model:

The attacker does not need to keep the credential if they can keep the authority path that produces the next one.

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.