Securing AI Coding Agents Against Malicious Repository Changes

Consider:

Pull Request
     |
     v
CI Pipeline
     |
     v
Build Script
     |
     v
Command Execution

If the pull request can modify the build script, the attacker may influence what CI executes.

This is why pull-request workflows should not automatically receive powerful secrets.

For example, avoid making repository-controlled code capable of freely accessing:

production credentials
cloud administrator credentials
deployment tokens
database administrator credentials

Use short-lived identities and scoped permissions instead.

Use a Trust Boundary Around CI Secrets

A useful architecture is:

Untrusted Pull Request
        |
        v
Restricted CI
        |
        v
Tests and Static Analysis
        |
        v
Trusted Build
        |
        v
Approval
        |
        v
Privileged Deployment

The first stage should operate with minimal privileges.

Only after the change passes required checks should it move into a more trusted workflow.

This reduces the impact of malicious repository changes.

Detect Secret Exposure

AI coding agents can accidentally expose secrets while inspecting files, logs, or environment variables.

Implement secret scanning across:

• Source code
• Commit history
• Pull requests
• Generated files
• Build logs
• Agent output

Also prevent the agent from accessing secrets it does not need.

For example, an agent fixing a unit test should not receive:

DATABASE_PRODUCTION_PASSWORD
CLOUD_ADMIN_TOKEN
PRODUCTION_API_KEY

even if those values exist in the environment.

Credential isolation is more reliable than expecting the model to remember not to disclose secrets.

Use Command Allowlisting

Many coding agents can execute shell commands.

Instead of allowing arbitrary commands, define task-specific command policies.

For example, a test agent might be allowed to execute:

dotnet build
dotnet test
dotnet format

but not:

Remove-Item
Invoke-WebRequest
curl
ssh
kubectl delete
terraform destroy

The exact policy depends on the environment.

The important point is that command execution should be treated as a privileged capability.

Add Human Approval for High-Risk Actions

Some actions should require explicit approval even if the agent has permission to request them.

Examples include:

Merge to protected branch
Deploy to production
Modify access policies
Rotate credentials
Delete infrastructure
Change CI security settings
Modify authentication configuration

A simple approval flow is:

Agent
  |
  v
Action Requested
  |
  v
Policy Evaluation
  |
  v
High Risk?
  |
 Yes
  |
  v
Human Approval
  |
  v
Execute

This keeps the agent useful while preventing high-impact operations from becoming fully autonomous.

Validate Dependencies Added by the Agent

An AI coding agent may add or update dependencies to solve a task.

This creates another supply chain boundary.

Before merging dependency changes, check:

• Package name
• Version
• Source
• Known vulnerabilities
• License
• Maintenance status
• Dependency tree
• Install scripts

Do not approve a dependency simply because the agent says it is required.

The dependency should pass the same review process as manually introduced packages.

Detect Suspicious Repository Instructions

Security tooling can identify suspicious patterns in repository content.

Examples include instructions asking an agent to:

Ignore previous security rules.
Print environment variables.
Upload local files.
Disable tests.
Disable security scanning.
Use production credentials.
Download an unknown executable.
Modify authentication controls.

These patterns should not automatically be considered malicious, because legitimate repositories can contain similar words in documentation or security tests.

Instead, treat them as signals that require context-aware analysis.

Maintain an Audit Trail

Every important agent action should be traceable.

Record information such as:

User
Agent
Repository
Branch
Commit
Task
Files Changed
Commands Executed
Tools Used
Policy Decisions
Approvals
Test Results
Timestamp

This helps answer questions after an incident.

For example:

Which agent modified the CI workflow?
Which user requested the task?
Which commands did the agent execute?
Which files did it read?
Was a privileged action approved?
Which commit introduced the change?

Without this information, investigating AI-assisted development incidents becomes much harder.

Example: Blocking High-Risk Agent Actions in .NET

A simple policy model can classify operations before execution.

public enum AgentActionRisk
{
    Low,
    Medium,
    High,
    Critical
}

public sealed class AgentAction
{
    public string Name { get; init; } = string.Empty;
    public AgentActionRisk Risk { get; init; }
}

A policy service can require approval for high-risk actions:

public bool RequiresApproval(AgentAction action)
{
    return action.Risk >= AgentActionRisk.High;
}

The actual production implementation should also evaluate the user, agent identity, repository, environment, and current permissions.

The important design principle is that risk should be evaluated before execution rather than after the action has already occurred.

Common Mistakes

Trusting all repository instructions

Repository content should not automatically become an instruction source.

Treat repository content as untrusted input unless it comes from a defined trusted channel.

Giving agents broad credentials

A coding agent rarely needs production-level credentials.

Use short-lived, scoped identities.

Allowing direct writes to protected branches

Use isolated branches and pull requests.

Running untrusted code with privileged CI secrets

Separate untrusted validation from privileged deployment workflows.

Allowing unrestricted shell commands

Command execution can become a path from source-code modification to system compromise.

Use allowlists, sandboxing, or restricted execution environments.

Treating generated code as trusted

AI-generated code still needs normal testing, security analysis, dependency review, and human review for sensitive changes.

Best Practices

• Treat repository content as untrusted input.
• Separate system and user policies from repository instructions.
• Use least-privilege agent permissions.
• Separate repository read and write capabilities.
• Use isolated branches and workspaces.
• Prevent direct agent access to production credentials.
• Restrict shell and system commands.
• Run security and dependency checks before merge.
• Protect CI/CD secrets from untrusted pull requests.
• Apply stronger review to deployment and security configuration changes.
• Require approval for high-risk operations.
• Scan generated changes for secrets and suspicious dependencies.
• Maintain detailed audit logs.
• Keep agent permissions separate from repository ownership permissions.
• Test the agent against prompt-injection and malicious repository scenarios.

Advantages and Disadvantages

Summary

AI coding agents should be treated as software actors with real permissions, not simply as chat interfaces inside an editor.

The repository itself should also be treated carefully. Source files, documentation, pull requests, issue descriptions, scripts, and dependency metadata can contain content that influences the agent. That content should not be allowed to override security policies or grant the agent additional authority.

A secure architecture separates repository content from trusted instructions, limits agent permissions, isolates changes in branches or workspaces, restricts command execution, protects CI/CD credentials, and validates every important change before it reaches a protected environment.

The most important principle is simple: an AI agent should have enough access to complete its task, but not enough access to turn a malicious repository change into a production incident.

As AI-assisted development becomes more autonomous, these boundaries become part of normal application security and software supply chain security rather than optional controls.