Listen to this Post
Introduction:
The traditional application security model is built on a fundamental assumption: that developers are the final arbiters of code implementation. We spend countless hours crafting detailed remediation advice, filing Jira tickets, and conducting training sessions to tell developers exactly how to fix vulnerabilities. However, as Ashton Richards highlights in a provocative new thesis, this assumption is rapidly breaking down. In an AI-first engineering workflow, developers are transitioning from being “authors” of code to “orchestrators” of intelligent agents. When the primary implementer shifts from a human to a machine, our security outputs—currently aimed at humans—become legacy noise.
Learning Objectives:
- Understand the paradigm shift from developer-centric to agent-centric security workflows.
- Learn how to inject security context directly into AI development pipelines, bypassing human bottlenecks.
- Identify the technical architecture required to move security findings from human-readable tickets to machine-executable patches.
You Should Know:
- The Shift from Author to Orchestrator: Rethinking the Control Plane
As Richards notes, telling a developer how to fix a vulnerability in a world where they didn’t write the code is a logical fallacy. If a developer uses an AI agent to generate 90% of a function, and a scanner finds a vulnerability in that generated code, the remediation advice should not go to the developer—it should go back to the agent. The developer’s role is now to manage the “how” and the “why,” not the syntax. This means our security tools must stop producing outputs for humans and start producing structured data for machines.
Step‑by‑step guide: Redirecting Security Findings to Agents
To simulate this, we can use a combination of a Static Application Security Testing (SAST) tool and a script to convert findings into a context file for an LLM.
Linux/macOS Command (Parsing SARIF output):
Assuming you have a SAST tool that outputs SARIF format (e.g., Semgrep) This command extracts the vulnerability location and message, then formats it for an agent. semgrep --config auto --sarif ./src > results.sarif Use jq to parse the SARIF and create a prompt for the AI jq -r '.runs[].results[] | "[bash] " + .message.text + " in " + .locations[].physicalLocation.artifactLocation.uri + " at line " + (.locations[].physicalLocation.region.startLine|tostring)' results.sarif > agent_context.txt The agent_context.txt file can now be fed into the context window of an IDE plugin or CI agent.
Windows PowerShell Equivalent:
Using a tool like 'ConvertFrom-Json' to parse SARIF
$sarif = Get-Content .\results.sarif | ConvertFrom-Json
$sarif.runs[bash].results | ForEach-Object {
$message = $<em>.message.text
$location = $</em>.locations[bash].physicalLocation
$file = $location.artifactLocation.uri
$line = $location.region.startLine
"[bash] $message in $file at line $line" | Out-File -FilePath .\agent_context.txt -Append
}
- Injecting Security Context: The “Never Do It Again” Prompt
One of the key insights from the discussion is that a developer might tell an agent to “never do it again.” This requires the security team to provide the agent with the organizational policy. Instead of fixing a single SQL injection instance, the security team should ensure the agent’s system prompt or Retrieval-Augmented Generation (RAG) database contains the rule: “Always use parameterized queries for database interactions.”
Step‑by‑step guide: Configuring an Agent’s System Prompt for Security
This example demonstrates how to structure a security policy for an AI coding assistant like GitHub Copilot or Cursor.
1. Create a Security Policy Document:
Create a file named `SECURITY_GUIDELINES.md` in your repository.
Secure Coding Policy for AI Agents
SQL Injection Prevention
- Rule: Never concatenate user input directly into SQL strings.
- Implementation: Always use parameterized queries (e.g., `cursor.execute("SELECT FROM users WHERE id = ?", (user_id,))` in Python) or an ORM.
- Rationale: Prevents unauthorized data access and manipulation.
Hardcoded Secrets
- Rule: Do not generate code containing hardcoded API keys, passwords, or tokens.
- Implementation: Use environment variables or a secrets manager (e.g., HashiCorp Vault).
2. Inject into Agent Context:
For tools like Cursor, you can add this file to the “Context” manually, or use the `@` symbol to include it. For automated CI agents, you would load this markdown file and append it to the user prompt before sending it to the LLM API.
Python snippet for API injection:
import openai
with open("SECURITY_GUIDELINES.md", "r") as f:
security_rules = f.read()
user_prompt = "Write a function to get user details from a SQLite database based on an ID."
response = openai.ChatCompletion.create(
model="gpt-4",
messages=[
{"role": "system", "content": "You are a secure coding assistant. Follow these rules strictly: " + security_rules},
{"role": "user", "content": user_prompt}
]
)
print(response.choices[bash].message.content)
3. Securing the Agent Supply Chain
Robert A. noted in the comments that the “biggest security jump” is securing the agents writing the code. If a development team relies on an AI agent, and that agent is compromised or trained on vulnerable data, every piece of code it produces is poisoned. This requires a shift from auditing code to auditing the training data and system prompts of the agents.
Step‑by‑step guide: Auditing AI-Generated Code Dependencies
When an agent generates code, it often imports libraries. We must scan not just the human-written code, but the agent-recommended dependencies.
1. Simulate an Agent Generating a Requirements File:
“Generate a Python script to parse a CSV. Include necessary imports.”
- Run a Software Bill of Materials (SBOM) scan on the output:
Assuming the agent generated a `requirements.txt` orpyproject.toml, use a vulnerability scanner like `Safety` orSnyk.
Simulate agent output echo "pandas==1.5.0\nrequests==2.28.1" > generated_requirements.txt Scan for vulnerabilities safety check -r generated_requirements.txt --full-report
If the scanner finds a vulnerability in requests==2.28.1, the security team must feed this back to the agent with a rule: “Never use requests version 2.28.1; use 2.31.0 or higher.”
4. Self-Healing Pipelines: From Detection to Remediation
The ultimate goal of this new paradigm is to close the loop entirely. When a vulnerability is detected in a pull request, an agent should automatically create a fix commit. The developer simply reviews the “orchestration” of the fix.
Step‑by‑step guide: Automating a Security Fix with an Agent
This uses a CI/CD pipeline (GitHub Actions) to trigger an automated fix.
1. Create a GitHub Action Workflow (`.github/workflows/auto-fix.yml`):
name: AI Security Fixer
on:
pull_request:
types: [opened, synchronize]
jobs:
semantic-security-fix:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
ref: ${{ github.head_ref }}
<ul>
<li>name: Run Security Linter
id: lint
run: |
Run a linter that outputs in a parseable format
semgrep --config p/ci --json . > semgrep_results.json</p></li>
<li><p>name: Generate Fix via AI
id: ai_fix
run: |
Use a Python script to read the results and call an LLM
python .github/scripts/generate_fix.py semgrep_results.json > fix.patch
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}</p></li>
<li><p>name: Apply Patch
run: |
git apply fix.patch
git config --global user.name 'security-agent[bash]'
git config --global user.email 'security-agent[bash]@users.noreply.github.com'
git add .
git commit -m "Automated security fix by AI agent" || echo "No changes to commit"
git push
2. The `generate_fix.py` Script (Conceptual):
This script takes the JSON output from Semgrep, identifies the vulnerable line, and asks an LLM to provide a corrected version of the specific function.
5. The Human Element: Orchestration over Implementation
Despite the automation, Chris Widdick raises a valid point: if developers don’t understand the “why,” they are spectating, not orchestrating. The security team’s role evolves into creating the “Guardrails” and “Playbooks” for the agents. This involves writing clear, machine-readable security policies.
Step‑by‑step guide: Creating a Machine-Readable Security Policy
Instead of a PDF document, create a YAML file that an agent can parse.
security_policies.yaml
version: 1.0
policies:
- rule_id: "CRYPTO-001"
description: "Use of weak hashing algorithm"
pattern: "hashlib.md5("
suggestion: "Use hashlib.sha256() or bcrypt instead."
severity: "high"
languages: ["python"]
<ul>
<li>rule_id: "AUTH-002"
description: "JWT secret hardcoded"
pattern: "jwt.encode({.}, 'hardcoded_secret'"
suggestion: "Load secret from environment variable: os.getenv('JWT_SECRET')"
severity: "critical"
languages: ["python", "javascript"]
What Undercode Say:
- Shift Left, But Into the Machine: The industry has been “shifting left” for years, but we were shifting toward humans. The real shift now is moving security controls into the AI agent’s training and context. If we fail to do this, we will be inundated with vulnerabilities generated at machine speed but fixed at human speed.
- Security Becomes a Data Engineering Problem: The core takeaway is that writing secure code is no longer just a software engineering problem; it is a data engineering problem. The quality of the code output is directly tied to the quality of the data (policies, examples, and feedback) we feed the model. Security teams must become experts in prompt engineering and RAG optimization, ensuring the agents are trained on secure defaults and organizational best practices.
The discussion underscores a critical inflection point. We cannot simply bolt security advice onto a system where the developer is no longer the primary coder. We must build security into the agent’s reasoning process. This means moving away from ticketing systems and toward continuous, automated feedback loops where the security tool speaks directly to the AI, ensuring that the “never do it again” command is actually heard—and executed—by the system writing the code.
Prediction:
Within the next three to five years, we will see the emergence of the “AI Application Security Engineer” role. These professionals will not review code line-by-line; instead, they will audit AI training datasets, fine-tune models on secure coding standards, and manage the guardrails for development agents. Traditional SAST tools will either become obsolete or will pivot entirely to become “Agent Security Testing” (AST) tools, focusing on the integrity and security of the AI agents themselves rather than the code they produce. The concept of a “vulnerability backlog” will diminish as security fixes are applied in milliseconds during the code generation phase, rendering the traditional Jira-driven remediation workflow a relic of the human-author era.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ashton Richards – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
