Security scanning is an essential part of the pull request lifecycle, but modern applications create a difficult problem for traditional static analysis.
Developers increasingly work with:
AI-generated code
Large language model integrations
Agentic workflows
Prompt handling
Tool calling
External model APIs
Retrieval-augmented generation
Dynamic instructions
Third-party AI services
These systems can introduce security risks that are different from traditional application vulnerabilities.
An AI security scanner can inspect pull requests for issues specific to AI-enabled applications and provide security findings before code reaches production.
GitHub's AI-powered security scanning capabilities extend GitHub's application-security workflow into this emerging area. The goal is not to replace established security tools, but to add AI-specific analysis to the pull request lifecycle.
A practical architecture looks like this:
Developer
|
v
Pull Request
|
v
AI Security Scan
|
+--> Prompt Risks
+--> Tool-Use Risks
+--> Model Integration Risks
+--> Data Exposure
+--> Configuration Problems
|
v
Security Findings
|
v
Developer / Security Review
The key advantage is timing: security issues can be identified while the change is still being reviewed rather than after deployment.
Why AI Applications Need Specialized Security Checks
Traditional application security scanning remains essential.
For example, an ASP.NET Core application may require checks for:
SQL injection
Cross-site scripting
Authentication weaknesses
Authorization issues
Dependency vulnerabilities
Hard-coded secrets
Unsafe deserialization
AI applications introduce additional concerns.
Consider this simplified flow:
User Input
|
v
Prompt
|
v
AI Model
|
v
Tool / Function
|
v
Application Data
A vulnerability can occur at multiple boundaries.
For example:
Untrusted User Input
|
v
Prompt Construction
|
v
Model Output
|
v
Tool Invocation
|
v
Sensitive Operation
Traditional static analysis may not fully understand the security implications of these AI-specific flows.
What Are AI Security Scan APIs?
An API-driven security scanning workflow allows organizations to integrate AI-focused security analysis into their existing development processes.
Instead of manually reviewing every AI-related pull request, a system can trigger a scan automatically:
Pull Request Opened
|
v
Workflow Trigger
|
v
AI Security Scan
|
v
Results
|
v
Pull Request Feedback
The exact implementation depends on the GitHub security products and APIs enabled for the organization.
The architectural principle is straightforward: security analysis becomes part of the normal pull request workflow.
API-Driven Security Automation
A security automation pipeline can be represented as:
GitHub Event
|
v
Security Workflow
|
v
Scan API
|
v
Finding Results
|
+--> Pull Request Comment
|
+--> Security Dashboard
|
+--> Alert / Ticket
This makes the scan reusable.
The same security workflow can potentially run for:
Pull requests
Branch updates
Scheduled scans
Release validation
Security investigations
Pull Request Integration
The most useful point to introduce AI security scanning is before merge.
A typical lifecycle becomes:
Code Change
|
v
Pull Request
|
+--> Build
+--> Unit Tests
+--> Static Analysis
+--> Dependency Scan
+--> AI Security Scan
|
v
Review
|
v
Merge
This gives developers feedback while they still have the context needed to fix the problem.
What AI Security Scanning Can Look For
AI security analysis can focus on several categories.
Prompt Injection
Prompt injection occurs when untrusted input influences an AI system's instructions in an unsafe way.
For example:
System Instruction
+
User Input
|
v
LLM
If the application does not clearly separate trusted instructions from untrusted content, an attacker may influence the model's behavior.
A scanner can help identify suspicious prompt-construction patterns.
Sensitive Data Exposure
AI applications frequently send data to external model providers.
For example:
var prompt = $"Summarize this customer record: {customer}";
If customer contains sensitive information, the application may unintentionally send data that should not leave the organization's security boundary.
A security review should therefore examine:
Data Source
|
v
Prompt Construction
|
v
Model Provider
Unsafe Tool Calls
Agentic applications can allow models to invoke tools.
For example:
await toolExecutor.ExecuteAsync(
modelResponse.ToolName,
modelResponse.Arguments);
This creates a security boundary.
The application should not assume that a model-generated tool name or argument is trustworthy.
A safer architecture validates:
Model Output
|
v
Tool Allowlist
|
v
Argument Validation
|
v
Authorization
|
v
Tool Execution
Excessive Permissions
An AI agent should not have access to every operation in an application.
For example:
AI Agent
|
+--> Read Customer
+--> Search Orders
+--> Delete Customer
+--> Modify Billing
+--> Deploy Infrastructure
The last three capabilities may require significantly stronger controls.
Security scanning can help identify risky patterns, but permission architecture remains an application-design responsibility.
AI Security Scanning Does Not Replace CodeQL
One of the most important points for security teams is that AI-specific scanning should complement existing security analysis.
A mature GitHub security pipeline can include:
CodeQL
+
Secret Scanning
+
Dependency Scanning
+
AI Security Analysis
+
Manual Security Review
Each layer catches different classes of problems.
For example:
Security Layer | Primary Focus |
|---|---|
CodeQL | Code-level vulnerabilities |
Dependency scanning | Vulnerable packages |
Secret scanning | Exposed credentials |
AI security scanning | AI-specific application risks |
Manual review | Architecture and context |
There is no reason to replace one layer simply because another becomes available.
Automating Scans With GitHub Actions
A GitHub Actions workflow can serve as the orchestration layer.
A simplified workflow structure looks like:
name: AI Security Review
on:
pull_request:
types:
- opened
- synchronize
- reopened
jobs:
security:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Run AI security analysis
run: |
./scripts/run-ai-security-scan.sh
The example demonstrates the architecture rather than prescribing a specific scanning command.
The actual scan invocation depends on the AI security service or API being integrated.
Why Permissions Matter
The workflow above contains:
permissions:
contents: read
pull-requests: write
Permissions should be explicitly minimized.
Do not give an AI security workflow:
permissions:
contents: write
actions: write
administration: write
unless those permissions are genuinely required.
A security scanner should have the minimum permissions necessary to:
Read the code it needs.
Execute the analysis.
Publish the resulting security information.
This follows the principle of least privilege.
Returning Findings to a Pull Request
Security findings are more useful when developers can see them where they work.
A conceptual result might look like:
AI Security Finding
Severity: High
File:
src/Agents/ToolExecutor.cs
Issue:
Model-generated tool arguments are passed to
the execution layer without validation.
Recommendation:
Validate tool names and arguments against an
explicit allowlist before execution.
This is more actionable than sending the same information to a separate security dashboard with no connection to the code change.
Severity and Triage
A security scan should classify findings.
A common model is:
Critical
High
Medium
Low
Informational
But severity alone is not enough.
Consider:
Severity
+
Exploitability
+
Data Sensitivity
+
Production Exposure
+
Business Impact
A medium-severity finding in a public-facing payment workflow may deserve more attention than a high-severity issue in an unreachable internal test component.
Security teams should therefore define triage rules rather than blindly using severity as the only decision criterion.
Blocking Pull Requests
Organizations can choose whether a finding should block merging.
For example:
Critical -> Block
High -> Block
Medium -> Review
Low -> Informational
This should be implemented carefully.
If every AI-generated finding blocks a pull request, false positives can quickly create developer frustration.
A better model is:
High Confidence + High Severity
|
v
Block Merge
while uncertain findings can remain advisory.
Confidence Matters
AI security findings are not guaranteed to be correct.
A useful workflow distinguishes:
High Confidence
|
v
Strong Candidate for Enforcement
Low Confidence
|
v
Human Investigation
This is particularly important when AI is used to identify architectural or contextual security problems.
Automated blocking should be reserved for findings where the organization has sufficient confidence.
Handling False Positives
False positives are one of the biggest risks in automated security systems.
Suppose the scanner reports:
Potential prompt injection vulnerability.
The developer investigates and determines that:
The input has already been validated and
is not user-controlled.
The workflow should allow the finding to be dismissed or marked as reviewed according to organizational policy.
Teams should track false-positive rates.
For example:
False Positive Rate =
Incorrect Findings
------------------
All Findings
If the rate becomes too high, developers may start ignoring security findings altogether.
Security Scanning and AI-Generated Code
AI-generated code creates another important use case.
Consider a developer asking an AI coding assistant to implement:
"Create an endpoint that lets administrators
execute maintenance commands."
The resulting code may compile and pass tests while still creating a dangerous capability.
Security scanning can provide another review layer:
AI-Generated Code
|
v
Application Build
|
v
Security Analysis
|
v
Human Review
This is particularly important for agent-generated code because agents can modify multiple files in a single workflow.
Scanning AI Configuration
Security review should not focus only on source code.
AI applications commonly contain configuration such as:
{
"Model": "production-model",
"Temperature": 0.2,
"ToolsEnabled": true
}
Other configuration may define:
Model providers
API endpoints
Tool permissions
System prompts
Retrieval sources
Logging behavior
Data retention
Safety controls
A secure pipeline should include configuration files in its analysis where appropriate.
Scanning Prompts as Code
System prompts increasingly function like application logic.
For example:
const string systemPrompt = """
You are an internal support assistant.
Never disclose confidential customer information.
Use approved tools only.
""";
A change to the prompt can alter application behavior even when no C# logic changes.
Therefore, organizations should treat important prompt changes as security-relevant changes.
For example:
Prompt Change
|
v
Security Review
|
v
Pull Request
Protecting the Scanner Itself
The security scanner becomes part of the software supply chain.
Protect:
Workflow definitions
API credentials
Scan configuration
Action dependencies
Service accounts
Result endpoints
A compromised security workflow could become a powerful attack vector.
Use pinned action versions and carefully controlled permissions where appropriate.
Protecting AI Scan Results
Security findings can themselves contain sensitive information.
A finding might reveal:
Internal endpoint
Database structure
Authentication behavior
Vulnerability details
Sensitive file paths
Therefore, access to security scan results should be controlled.
Do not automatically expose detailed security findings to every user who can see a pull request if the organization's security model requires restricted disclosure.
Building an Enterprise AI Security Pipeline
A mature enterprise workflow can look like:
Pull Request
|
+---------------+---------------+
| | |
v v v
CodeQL Dependency Scan AI Security
| | |
+---------------+---------------+
|
v
Result Aggregation
|
+----------+----------+
| |
v v
Developer Review Security Team
|
v
CI
|
v
Merge
This gives each security mechanism a defined role.
Measuring AI Security Scan Effectiveness
Organizations should measure more than the number of scans executed.
Useful metrics include:
Metric | Purpose |
|---|---|
Pull requests scanned | Coverage |
Findings per PR | Detection volume |
True positives | Finding quality |
False positives | Noise |
Mean time to remediation | Response speed |
Reopened findings | Fix effectiveness |
Blocked PRs | Enforcement impact |
Escaped vulnerabilities | Outcome quality |
A mature security program should focus increasingly on outcomes.
Measuring Coverage
A basic coverage metric is:
Scan Coverage =
PRs Scanned
-----------
Eligible PRs
For example:
Eligible PRs = 1,000
Scanned PRs = 950
Coverage = 95%
A high coverage percentage is useful only if the scan is appropriately configured and the results are actually reviewed.
Measuring Mean Time to Remediation
Another useful metric is:
MTTR =
Finding Resolved Time
-
Finding Created Time
Tracking this by severity can reveal operational weaknesses.
For example:
Critical -> 2 hours
High -> 1 day
Medium -> 5 days
The goal should be to establish realistic service-level expectations rather than simply maximizing closure speed.
Common Mistakes
Replacing Existing Security Tools
AI security analysis should complement, not automatically replace, CodeQL, dependency scanning, secret scanning, or other controls.
Giving the Scanner Excessive Permissions
Use least privilege.
Blocking Every Finding
False positives can create unnecessary development friction.
Trusting AI Findings Blindly
AI security analysis can produce incorrect or incomplete results.
Ignoring Prompt Changes
Important prompts can influence application security just like code.
Exposing Production Credentials
Security workflows should use scoped credentials and isolated environments.
Running Untrusted Repository Code With Sensitive Permissions
Pull request workflows can execute attacker-controlled code depending on workflow configuration.
Review workflow trust boundaries carefully.
Measuring Only Finding Counts
A scanner producing thousands of low-quality findings is not necessarily effective.
Measure precision, remediation, and escaped vulnerabilities.
Best Practices
Run AI security checks early in the pull request lifecycle.
Keep traditional security scanning enabled.
Use least-privilege GitHub Actions permissions.
Isolate security scanning environments.
Minimize access to secrets.
Treat AI prompts and configuration as security-relevant artifacts.
Validate model-generated tool names and arguments.
Apply authorization independently of model output.
Track false positives.
Use confidence and severity together for merge enforcement.
Keep security findings auditable.
Measure remediation time.
Test the scanner against known security issues.
Periodically review whether the scanner is detecting meaningful vulnerabilities.
Never treat AI scanning as a replacement for human security review of critical systems.
Advantages
Earlier Security Feedback
Developers can address AI-specific risks while the pull request is still open.
Automated Coverage
Every eligible pull request can be analyzed consistently.
AI-Specific Analysis
Security workflows can focus on prompt injection, tool use, model integrations, and data-flow risks that traditional tools may not fully cover.
Better Developer Workflow
Security findings can be connected directly to the pull request.
Scalable Security Operations
API-driven scanning can be integrated into organization-wide automation.
Disadvantages and Risks
False Positives
Incorrect findings can create alert fatigue.
False Negatives
No AI scanner can guarantee complete vulnerability detection.
Additional Cost
Large repositories and frequent pull requests can increase analysis consumption.
Security Workflow Risk
The scanner itself becomes part of the organization's security infrastructure.
Context Limitations
Some security decisions require architectural or business context unavailable to automated analysis.
Conclusion
GitHub AI security scanning APIs provide a way to integrate AI-focused security analysis into the normal pull request lifecycle.
Instead of treating AI security as a separate post-development activity, organizations can build a pipeline where every relevant change is analyzed before it reaches production:
Pull Request
|
+--> CodeQL
+--> Dependency Scanning
+--> Secret Scanning
+--> AI Security Analysis
|
v
Security Findings
|
v
Developer + Security Review
|
v
CI Validation
|
v
Merge
The most important architectural principle is that AI security scanning should be another security layer, not the only security layer.
Traditional static analysis remains valuable for conventional vulnerabilities. Dependency and secret scanning address their own threat categories. Human security reviews provide architectural context.
AI-specific scanning adds another perspective for applications built around prompts, models, agents, retrieval systems, and tool execution.
For enterprise teams, the strongest implementation combines automated scanning with least-privilege permissions, isolated execution, measurable false-positive rates, risk-based enforcement, and human oversight.
The objective is not simply to scan more pull requests.
The objective is to identify meaningful AI-related security risks early enough that developers can fix them before those risks become production vulnerabilities.
Join the conversation! Your thoughts help the community grow.