Every Third PR Is Agent-Written: Protecting Secrets

According to GitHub, an AI agent is involved in one out of every three pull requests today, compared with fewer than one in ten a year ago.

If the pace continues (this is an extrapolation, not a GitHub forecast), agents will write most of the code on GitHub within two years, and humans will not read all of it.

For secrets, this means protection must trigger before commit without requiring human involvement at every step.

The reason is A GitHub analysis of scaling secret protection and a series of announcements around it.

Previously, a secret leak was a rare event occurring at human speed.

A developer would leave a key in the configuration, a scanner would catch it after the push, and someone would manually revoke and reissue it.

The approach worked while a limited amount of code was being written and someone reviewed every line. An agent breaks both assumptions.

It produces more changes per hour, and no one reads some of them line by line.

The likelihood of finding a password or token in thousands of commits grows with scale, while manually reviewing every finding can no longer keep up. GitHub splits the task in two: prevent more leaks before they occur and reduce the manual work needed to respond to those that remain.

Traditional secret scanning searches for patterns: a cloud provider key has a recognizable prefix and length. A database password in the `db_pass` variable has no such pattern, so these findings went undetected. GitHub announced a specially trained model for detecting leaked secrets.

It reads the surrounding code and uses the context to identify likely credentials, including passwords without a recognizable format.

The model is planned for three areas: secret scanning alerts, push protection (blocking a push containing a secret), and security review within Copilot.

We expect the greatest impact from the third area.

A check within the agent's workflow runs before the secret reaches the repository, so the key does not need to be rotated.

Fixing it at this point costs the least.

The detector triggers after a secret has entered the code, while the sandbox reduces the chance of that happening. Local sandboxing in GitHub Copilot is now generally available for Copilot CLI, the Copilot app, and VS Code sessions with Agent Host.

Commands and tools launched by Copilot receive limited access to the file system, network, and credentials.

The policy is set by the developer or organization.

Under the hood, Microsoft eXecution Container (MXC) translates a unified sandbox policy into isolation mechanisms for the specific operating system.

For the company, this means one rule applies across different workstations.

If an agent cannot access `~/.aws` or connect to the outside network, there is nothing for it to steal or publish.

We consider this principle the mandatory minimum for any agentic environment.

For AI-native development for clients, we use a three-layer model. 1. The secret never reaches the agent.

Tokens with minimal permissions, a short lifetime, and access through a dedicated proxy. A key that is absent from the model context cannot appear in the commit either. 2. The execution environment is restricted.

A sandbox for files, the network, and credentials, as in MXC.

For server-side agents, container isolation and egress filtering provide the same result. 3. Traffic to the models passes through a single point. In LLM & Security Gateway, requests to external and local models pass through a single gateway that masks secrets and personal data and maintains an audit trail.

Agents accessing corporate systems through MCP servers receive separate permissions for each tool.

A repository-level detector serves as the fourth layer and protects against residual errors.

Relying on it alone is risky: every detection model produces false positives and misses. GitHub has so far described plans, so check the documentation for timelines for specific features.