Enterprise takeaway: GitHub’s October 28, 2026 public preview adds pull-request scanning for vulnerabilities in applications that use models and tools. That is a useful earlier warning about risky code paths, but it does not certify that an agent’s permissions, runtime data access or production approvals are safe. Engineering leaders need a test plan that separates what source analysis can see from what only execution can prove.
The announcement describes detection of indirect prompt injection and discusses sensitive information disclosure and excessive agency as the feature’s coverage expands. The more specific product documentation says the initial preview concentrates on indirect prompt injection. Treat broader risk categories as areas to verify against the current supported detector, not as guaranteed complete coverage.
What the preview actually scans
GitHub says the feature runs on eligible pull requests alongside existing CodeQL analysis and flags paths where untrusted content can reach a model connected to tools, data or business systems. Findings appear in the pull request with mitigation guidance. The October 28 announcement says the feature is in public preview on github.com, requires GitHub Advanced Security and is not available on GitHub Enterprise Server.
It is important to distinguish this detector from AI Scan for repositories, another October 28 preview that runs on demand against the default branch and creates backlog alerts. A pull-request detector cannot by itself provide a complete inventory of historical agent code or prove that deployed runtime configurations match what was reviewed. GitHub documents separate enablement for the different scanning features.
Four boundaries a source-code alert cannot establish
1. Untrusted input versus trusted instructions
A detector may identify code paths in which a document, webpage, issue comment or retrieved result enters a model context that can influence tool use. The risk is not merely an unusual string. It is the possibility that content supplied by a lower-trust source is treated as an instruction. Test representative document and retrieval workflows in a controlled environment. Record whether the agent rejects unauthorized actions, not just whether a scanner reports a finding.
2. Model output versus business authorization
An agent can produce a plausible tool request even when the requested action is forbidden. Every sensitive tool needs an authorization decision tied to the authenticated user, resource and operation. Code scanning can point to risky architecture; it cannot guarantee that every production policy, tenant permission or delegated credential is configured correctly. The distinction also matters in our GitHub application identity migration guide, where installation identity and effective privilege are separate checks.
3. Review findings versus release enforcement
A warning in a pull request is not automatically a blocked merge. Security teams should document whether the preview’s alerts can be incorporated into existing approval processes, what their organization will do when a finding is disputed, and who has authority to accept residual risk. GitHub’s product documentation notes preview limitations around enforceable rulesets. Keep mandatory security gates in established controls until the feature’s enforcement behavior is verified.
4. A clean pull request versus a safe production agent
Runtime prompts, retrieval indexes, tool catalogs, access tokens and third-party services may change after a code review. A scanner cannot observe every subsequent configuration change or malicious document the system will encounter. Use a staged exercise that includes unauthorized tool requests, cross-tenant data attempts, revoked access and audit-log inspection. Our enterprise CI release-gate framework explains why testing and authorization must remain independent of the automation that proposes changes.
A simple coverage map for the release meeting
Find potential untrusted-input paths
Prove unsafe requests are refused
Check identity, resource and action
Monitor changes, audit and revoke
Proposed assurance model. Passing a source scan does not replace the other three checks.
Six acceptance tests for a pilot
Test one — enablement: Confirm enterprise policy, organization setting, eligible repository and supported hosting. Record which repositories are actually covered, rather than assuming an enterprise-level toggle automatically activates everything.
Test two — known-risk fixture: Introduce a harmless, deliberately vulnerable sample in a private test repository with approved access. Verify that the detector recognizes the supported indirect-instruction pathway. Do not use production credentials or real customer data.
Test three — negative control: Include a similar but properly authorized flow. Track whether it is incorrectly flagged and how much analyst time it consumes. False positives affect adoption just as much as missed findings.
Test four — triage: Assign an owner, document the proposed fix, have a separate reviewer approve it, and confirm that the alert is not dismissed merely because a code change was suggested. Compare the effort with the existing durable-fix and regression measurement approach.
Test five — runtime challenge: Execute benign simulated prompt-injection and excessive-permission cases in a sandbox. Verify that tool authorization and human approval stop actions even if the model follows an unsafe instruction.
Test six — cost and coverage: Track scanned eligible pull requests, findings reviewed, confirmed actionable findings, time to remediation and incremental security credits. A rising finding count is not automatically a quality improvement; normalize it by reviewed code and confirmed risk reduction.
How to interpret a clean result
A clean scan means no finding was reported for the code and detector scope exercised at that moment. It is not proof that the agent resists all prompt injection, cannot disclose sensitive data or operates with least privilege. The same caution applies to automated code review: our separation-of-duties review policy keeps responsibility with accountable maintainers.
Use the preview to strengthen the early feedback loop, then retain scenario tests, authorization enforcement and production monitoring. Security assurance comes from the combined evidence, not from a single green status.
Sources and limitations
- GitHub, October 28, 2026 — launch scope, prerequisites and public-preview status.
- GitHub documentation, AI applications scanning for pull requests — initial detection coverage, separate enablement and preview limitations; details can change.
- GitHub, October 28, 2026 — separate repository-wide scanning preview.