Since June, GitHub has run the same automatic security validation on code produced by Claude and OpenAI Codex that it already ran for Copilot cloud agent. That sounds like a product integration. It is more useful as an architectural signal: the safe boundary is moving away from which agent wrote this and toward what every generated change must pass before a person can merge it.

The built-in preflight has three parts. GitHub says it uses CodeQL to find code-security issues, checks newly introduced dependencies against the GitHub Advisory Database, and scans for secrets such as keys and tokens. If it finds something, the agent attempts to repair the problem before finalizing its pull request. The validation is on by default and does not require a GitHub Advanced Security license.

The important phrase is "third-party." Claude, Codex, and Copilot have different models, tools, and failure profiles. GitHub is not claiming those differences disappeared. It is applying the same checks after each agent produces code. The control becomes identity-agnostic.

That is the right direction, but the built-in validation is not the whole merge gate. It follows the repository's Copilot cloud-agent settings, an administrator can disable one or more validation tools, and it runs as part of the agent session. GitHub also keeps Actions approval separate by default: workflows do not automatically run merely because an agent pushed a change. That separation matters because a modified workflow can execute with repository secrets. Reviewing the handoff before granting execution is itself a security boundary.

The preflight is also deliberately narrow. CodeQL can find supported vulnerability patterns, but it cannot decide whether the feature should exist. An advisory lookup may reject a newly introduced vulnerable dependency without telling you whether adding another dependency was a good architectural choice. Secret scanning can recognize credentials; it will not catch every valid but non-secret production identifier that should have stayed private.

None of the three validates intent, business logic, threat-model completeness, operational cost, or a compromised workflow. A clean scan does not prove that an authorization check sits on the correct side of a cache, that a rate limit survives horizontal scaling, or that a migration has a rollback path. Those remain review and test questions.

So I would not build policy around a list of approved agent brands. I would build one lane:

  1. The agent works on an isolated branch and opens a pull request.
  2. Agent-side validation catches cheap, recognizable failures before handoff.
  3. Repository-owned required checks run regardless of author: tests, linting, dependency review, secret scanning, workflow-trust checks, and any domain-specific invariants.
  4. A human reviews the diff, the evidence, and the architectural decision before merge.

That third step is the durable one. It covers locally run agents, GitHub-hosted agents, human contributors, and whatever agent appears next quarter. It also keeps the policy enforceable when a repository administrator turns off an optional agent setting or a change arrives through a path the integration does not recognize.

GitHub's own risk documentation makes the same boundary visible from another direction. Agent pull requests remain subject to branch protection and required checks; the agent cannot mark its own pull request ready for review, approve it, or merge it; and Actions workflows require approval by default. GitHub's third-party agents page applies the same protections, mitigations, and limitations to Claude and Codex. The agent can prepare a change, but it does not get to redefine the conditions under which that change becomes trusted.

The best part of GitHub's announcement is not that Claude and Codex became safer. It is that their names matter less at the handoff. Treat agent validation as a useful preflight. Keep the repository's deterministic checks and human approval as the admission control.

See also

Sources

  1. GitHub: Security validation for third-party coding agents
  2. GitHub Docs: Risks and mitigations for Copilot cloud agent
  3. GitHub Docs: Configuring cloud-agent settings
  4. GitHub Docs: About third-party coding agents