Agentic security in the enterpriseAdvancedLesson 1536 min read

Coding agents: secrets, packages and pull requests

Coding agents read your code, run commands and open pull requests. They meet untrusted text in issues and dependencies, and they can reach your secrets. Here is how to use them safely.

✦ Ask the tutor🧪 Lab · 35 min📝 Lesson test
Lesson in motion

In 60 seconds

Coding agents: secrets, packages and pull requests

Coding agents read your code, run commands and open pull requests. They meet untrusted text in issues and dependencies, and they can reach your secrets. Here is how to use them…

1/5
In simple words
A coding agent is like a very fast new trainee in your workshop. They can use every tool on the bench. So you do not leave the safe open, you check the parts they bring in, and a senior person checks their work before it goes to customers.
Coding agents can read a repository, edit files, run terminal commands, install packages and open pull requests. Many developers now use them daily. They combine all three parts of the lethal trifecta by default: private data (code and secrets), untrusted content (issues, READMEs, dependencies, web docs) and ways out (network, git push, package installs).

Four risk areas

AreaWhat can go wrongMain control
SecretsThe agent reads a .env file or cloud credentials and prints them in output, logs or a commitNo real secrets in the agent's environment; secret scanning on commits
PackagesThe agent installs a package name it invented, or a look-alike of a real one; attackers register such namesApproved registries or a proxy; lockfiles; human check on new dependencies
Injected instructionsAn issue, README, code comment or dependency's docs tells the agent to do something harmfulTreat repo text as untrusted; restrict commands and network
PipelineAgent changes CI files or workflows to gain more access or skip checksProtected paths; code owners; least-privilege CI tokens
The invented-package problem is sometimes called slopsquatting: a model suggests a package that does not exist, and an attacker publishes a malicious package with that name. Always check that a new dependency is real, maintained and the one you meant.

Run it in a box

  1. 1

    Container or VM

    The agent works in a dev container or virtual machine, not directly on a laptop full of credentials.
  2. 2

    No production secrets

    Use test credentials or none. Real secrets stay in the CI system and secrets manager.
  3. 3

    Network limits

    Allow the package registry (or your internal mirror) and the code host. Block the rest where you can.
  4. 4

    Command limits

    Many coding agents can ask before running commands or allow only listed commands. Keep dangerous ones (deleting, pushing, deploying) behind approval.

Pull requests are the checkpoint

Agent with a free hand
  • Pushes straight to the main branch
  • Can edit CI workflows and security config
  • CI token can write to the repo and publish packages
  • Merged because "the tests passed"
Agent inside guardrails
  • Works on its own branch; branch protection blocks direct pushes
  • Changes to CI, auth and dependency files need a code owner's review
  • CI runs with read-only tokens by default; publish rights only in protected release jobs
  • A human reviews every agent pull request like a new colleague's
Least-privilege CI token (GitHub Actions example)yaml
# At the top of a workflow file: default to read-only
permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci        # installs exactly what the lockfile says
      - run: npm test
Note
Other CI systems have similar settings. The idea is the same: the automatic token given to pipeline jobs should be read-only unless a specific job needs more.

What reviewers should look for in agent pull requests

  • New dependencies: do they exist, are they well known, are they needed?
  • Changes to CI, build scripts, permissions, auth or security checks, even small ones.
  • Removed or weakened tests, or checks turned off "to make the build pass".
  • Hard-coded keys, URLs to unknown servers, or new outbound network calls.
  • Code that does more than the task asked for.
Watch out
Passing tests do not prove code is safe. An agent can write code and tests that agree with each other and still be wrong or insecure. Review and security scanning still apply.
Try this. Check a repository you work on: can anyone (or any bot) push directly to the main branch? Which files would you want a code owner to approve?

Watch and read more

Lab

A hardened CI workflow, a branch protection plan and an agent pull request review checklist.

~35 min

The problem

Work on a practice repository you own, or on paper.

  1. Fix the starter CI workflow so it follows least privilege: read-only by default, no secrets in the test job, installs from the lockfile.
  2. Write a branch protection plan: who can push to main, how many reviews, which paths need a code owner (CI files, auth code, dependency files).
  3. Write a 6–8 item review checklist for pull requests opened by coding agents.
  4. Write the sandbox settings for the agent: where it runs, what network it can reach, which commands need approval.
Starter codeyaml
# Practice workflow with problems to fix
permissions: write-all

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      PROD_DB_PASSWORD: "hunter2-example-not-real"
    steps:
      - uses: actions/checkout@v4
      - run: npm install        # installs latest versions, ignores lockfile
      - run: npm test
      - run: npm publish        # publishing from a test job

You are done when

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1The agent must run tests that need a database. How do you avoid giving it production credentials?Reveal

Give it a disposable test database, started inside its container or CI job with throwaway credentials and made-up data. Production credentials should exist only in deployment jobs that the agent cannot trigger or edit, protected by branch rules and code-owner review.

Q2Why is a public repository's issue tracker a special risk for coding agents?Reveal

Anyone on the internet can write there, so it is fully untrusted content. An agent that reads issues and also holds secrets or write access is the lethal trifecta. Use a separate, low-privilege agent for public issues, with no secrets and no push or publish rights, and have humans review everything it proposes.

Please sign in to continue.

Questions people ask

Can we let the agent merge its own pull requests if all checks pass?

For very low-risk changes in low-risk repos, some teams do. For anything touching production, security, dependencies or CI, keep a human reviewer. The checks were written with human authors in mind, and an agent can be steered by text you have not read.

How do secrets leak through coding agents?

The agent reads a file with a secret, then includes it in a command, a log, a test fixture, a commit or a message to a model provider. Keep real secrets out of the agent's environment, use secret scanning on commits, and rotate anything that may have been exposed.

What about injection through issues?

If an agent is asked to "fix issue 42", the issue text goes into its context. Anyone who can write issues (on a public repo, anyone at all) can place instructions there. Limit what the agent can do on public-facing repos, and never give such an agent secrets or publish rights.

Should agents be allowed to add dependencies?

They can propose them. A human, or a policy check against an approved list, should confirm before a new dependency is merged. Lockfiles and an internal package mirror make this easier to control.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.

Sign in to take the test and save your progress