AI coding agents change the security problem from “a developer wrote a risky line” to “an automated workflow changed code, dependencies, configuration, and sometimes infrastructure faster than humans can review.”
That does not mean teams should avoid AI coding tools. It means the guardrails need to move into the same workflow as the agent.
Main risks from AI coding agents
The most common risks are not exotic:
- Hallucinated package names that become dependency confusion risk.
- New dependencies added without security review.
- Secrets committed through generated config or examples.
- Missing auth and ownership checks.
- Prompt injection paths in agent-enabled features.
- Overbroad GitHub Actions or cloud permissions.
- Generated tests that prove the happy path but miss abuse cases.
- Code merged before a human understands the security model.
AI coding agents increase change velocity. Security review has to match that velocity without becoming a wall of generic alerts.
Guardrail 1: block unsafe dependencies
Agents are good at finding packages that appear to solve the problem. They are less reliable at judging whether a package is trustworthy.
At minimum, teams should check:
- Package age and publisher reputation.
- Typosquatting and hallucinated names.
- Install scripts and obfuscated code.
- New transitive dependency risk.
- Whether the dependency is necessary at all.
Supply-chain checks should happen before merge, not after the dependency has spread through the codebase.
Guardrail 2: catch secrets before they leave the machine
Agents can generate example config, test credentials, API calls, and deployment snippets. That makes secrets scanning essential.
Use local pre-commit checks, CI checks, and PR review. Do not rely on one layer. Once a secret lands in Git history or CI logs, cleanup gets messy.
Guardrail 3: review auth and business logic in the PR
Most dangerous agent-generated bugs are not obvious syntax mistakes. They are missing assumptions:
- The route works, but does not enforce object ownership.
- The admin path is protected, but the mutation helper is reused somewhere public.
- The workflow succeeds, but a user can skip a payment state.
- The agent action works, but untrusted content can steer it.
Hacktron Review is built for this layer. It reviews pull requests for exploitable security issues and explains the fix inline.
Guardrail 4: encode project rules
AI coding agents need product context. So do AI security reviewers.
Capture rules such as:
- Which auth helper must protect tenant data.
- Which repositories may publish packages.
- Which branches may deploy.
- Which domains are trusted webhook sources.
- Which agent tools may act on untrusted input.
- Which resources should never become public.
Hacktron supports project-specific rules in .hacktron/rules.md, so teams can make the reviewer reflect their real threat model.
Guardrail 5: review infrastructure and CI changes together
AI agents can edit code and workflow files in the same PR. That combination matters.
A GitHub Actions permission change may be harmless alone but dangerous with a new package publish step. A cloud permission may become critical when paired with a new SSRF path. A new webhook may be safe only if the validation logic is correct.
Review the whole PR as a system.
Practical rollout
Start with repositories where agents already write code. Add PR security review for changes touching auth, payments, integrations, dependencies, AI features, CI/CD, and IaC. Track which findings developers accept, then encode repeat patterns in project rules.
The goal is not to ban AI-generated code. It is to make sure the code gets the same security judgment a careful human reviewer would apply.