GitHub now scans pull requests for AI-agent security failures

GitHub has added AI-specific security checks to the pull-request workflow. The new public preview is designed to find code paths where an AI application reads untrusted content and can then reach tools, data or business systems with unsafe authority.

The GitHub release announcement names three initial risk classes: indirect prompt injection, sensitive information disclosure and excessive agency. The checks run automatically on pull requests alongside existing CodeQL analysis when an organisation has GitHub Advanced Security and has enabled both code scanning and scanning for AI applications.

This matters because many serious agent failures do not look like familiar injection bugs. The dangerous condition may be a chain: an agent reads a webpage, issue comment or uploaded document; hidden instructions in that content influence the model; the same agent holds a credential or tool that can change a system. Each component can appear reasonable in isolation. The security problem emerges from how data, instructions and authority connect.

What the preview is looking for

Indirect prompt injection occurs when malicious instructions arrive inside content that the model has been asked to process. An attacker does not need to type into the application’s chat box. A poisoned webpage, email, file or ticket can become an instruction channel when an agent reads it.

Sensitive information disclosure occurs when an agent can retrieve or transmit data without the controls that should govern that information. A model that can search internal documents and send messages may unintentionally bridge two systems with different access expectations.

Excessive agency means the agent has more permissions, tools or autonomy than its task requires. A summarisation agent with write access to a CRM, shell commands and outbound messaging has a much larger failure radius than its stated purpose justifies.

GitHub says the detector follows agent code paths, identifies cases where untrusted content can reach a capable model and provides mitigation guidance in the pull request. That places the warning where a developer can still change the architecture before the code reaches production.

What changed, and what did not

The AI-application detector is a public preview on github.com. It requires a GitHub Advanced Security licence and is not available on GitHub Enterprise Server at this time. Preview status should shape expectations: coverage will expand, detection quality will change and teams should validate findings rather than treating the absence of an alert as evidence that an agent is safe.

GitHub also announced a separate AI Scan for repositories preview on the same day. AI Scan uses an agentic scanner to explore a repository for vulnerabilities that CodeQL may not cover. Its findings enter the normal code-scanning backlog and consume Code Security AI credits. It does not replace the AI-application detector: one broadens repository vulnerability discovery, while the other targets risky AI and agent architectures in pull requests.

That distinction is useful for buyers. “AI security scanning” now describes at least two different activities:

• using AI to find conventional software vulnerabilities;
• finding vulnerabilities created by applications that use AI.

An organisation may need both, but they answer different questions and should be evaluated separately.

Why a scanner cannot see the whole risk

Static and agentic analysis can find important code relationships, but an AI agent’s effective authority also depends on deployment configuration, identity, runtime policy and the external systems it can reach. Repository code may not reveal that a production service account has broad tenant access, that an MCP server exposes an administrative method, or that a human routinely approves requests without reading them.

The detector also cannot decide the organisation’s risk tolerance. Reading public product pages may be acceptable for one workflow and prohibited for another that handles confidential acquisition data. The same tool call can be low risk in a sandbox and consequential in a production finance system.

Treat the alert as a prompt for design review rather than a complete verdict. A useful finding should lead to questions such as:

• Which inputs are untrusted, and are they clearly separated from system instructions?
• Which tools can the agent call after reading those inputs?
• Does the agent use the end user’s identity, a shared service identity or a privileged automation account?
• Can it send data outside the organisation or make an irreversible change?
• What evidence will a reviewer see before approving an action?
• Can the action be reversed, and is there an audit trail?

A practical rollout for development teams

Start with a small set of repositories that already contain agents or model integrations. Do not enable a new preview everywhere and leave developers to interpret unfamiliar alerts on their own.

1. Define the architecture boundary. Document model calls, retrieval sources, tools, credentials, approval points and outbound destinations for one application.
2. Enable the detector on an active repository. Select a project with enough pull-request traffic to generate evidence, but avoid making a preview tool an immediate blocking control.
3. Triage alerts with security and engineering together. Confirm the data flow, reachable permissions and production configuration before accepting or dismissing a finding.
4. Fix the authority chain. Prefer narrow tools, scoped identities, allowlisted destinations, structured outputs and explicit approval for consequential actions. Prompt wording alone is not a reliable security boundary.
5. Test adversarial content. Put hostile instructions in the files, webpages and messages the agent is expected to read. Verify that the system contains the attempt and records what happened.
6. Measure the preview. Track true findings, false positives, review time, repeated patterns and whether developers can apply the guidance. Decide later whether any alert class is reliable enough to block a merge.

For repository-wide AI Scan, add cost controls before scheduling broad use. GitHub states that scans consume Code Security AI credits and run within a fixed time budget. A security tool still needs an owner, a budget and a process for the alerts it creates.

What leaders should ask for

The most useful management evidence is not a dashboard showing that scanning is enabled. Ask for the inventory of AI-enabled applications, the risky data-and-tool paths discovered, the design changes made and the residual risks accepted. That connects the scanner to accountable engineering decisions.

GitHub’s release is a welcome sign that AI-agent risks are moving into ordinary software-delivery controls. Pull-request feedback can make secure design easier and earlier. It will work best as one layer in a programme that also covers identities, runtime isolation, connector governance, logging, red teaming and recovery.

If you are building agents or reviewing their control boundaries, our AI security consulting work can help turn those architecture questions into testable requirements and evidence.