- AI code needs the same review as code from an unknown colleague.
- Five checks: secrets, dependencies, authorization, input validation and automated scanning.
- Automate what you can: code scanning and dependency alerts catch many flaws but do not replace thinking about permissions.
Coding agents and builders write code faster than it can be read carefully. That makes the temptation to deploy “because it works” stronger than with hand-written code. Code that works need not be secure: an application can perform its task correctly and at the same time expose a key, another user’s data or a dependency with a known vulnerability. Below are five checks worth doing before every deployment. The background of risks around models is described in the article on the OWASP LLM Top 10.
Check 1: secrets
Check that the code, configuration files or repository history contain no API keys, passwords or tokens. Code run in the browser is especially risky, because every visitor sees everything in it. Keep secrets in environment variables on the server side. GitHub has a secret scanning feature that runs automatically in public repositories and in private ones depends on the plan and enabled options. If a key leaked, revoke it at once, because deleting a file does not remove it from the change history.
Check 2: dependencies
An agent readily adds packages, and each is somebody else’s code with its own vulnerabilities. Review the list of dependencies: is each needed, does it come from a trusted source, is the name not a typo of a known package. Enable Dependabot, which warns about dependencies with known vulnerabilities and can propose updates. Introduce updates consciously, with tests, because an automatic version change can also be a source of errors.
Check 3: authorization
A serious flaw that can appear in application code is a missing check of who may see or change data. Authentication (who this is) is not the same as authorization (what is allowed). For every operation on data ask: does the code check that exactly this user has the right to this record? Test it by hand: log in as user A and try to read user B’s data by changing the identifier in the address. Automated scanners will not judge your application’s permission logic, so this is a check for a human.
| What you check | What helps | |
|---|---|---|
| 1. Secrets | Keys in code, files and history | Secret scanning, environment variables |
| 2. Dependencies | Packages needed, trusted, up to date | Dependabot, review of the package list |
| 3. Authorization | Who may do what on data | A test with two accounts, human review |
| 4. Input | Validation and parameterized queries | Schemas, tests with malicious data |
| 5. Scanning | Known vulnerability patterns | Code scanning on every push |
Check 4: input validation
Data from a user is untrusted, and in AI applications text returned by the model joins it. Check that data is validated (types, lengths, allowed values), that database queries are parameterized rather than glued from text, and that output displayed in the browser is properly protected against code injection. OWASP lists improper handling of model output as one of the threats to LLM applications: a model can return text that, once inserted into a page, executes as code. I write about validating tool arguments in the article Tools and validation in JavaScript.
Check 5: automated scanning
Finally, turn on what checks for you. Code scanning in GitHub analyzes code for vulnerabilities and errors, shows alerts in the repository and can run on a schedule or on events such as a push. That way new code from an agent is checked every time, not only when somebody remembers. The automation catches known patterns but does not replace thinking, so checks 3 and 4 stay with a human.
- 01SecretsNo keys in code and history.
- 02DependenciesNeeded, trusted, no known vulnerabilities.
- 03AuthorizationA test of access to others' data.
- 04InputValidation, parameterization, escaping.
- 05ScanningAutomation on every change.
- 06DeploymentOnly after green checks.
After deployment the checks do not end: set up alerts, review them weekly and have a plan for an incident, that is know who revokes keys, how to roll back a version and where the backups are. Also write a short note on which checks were done before deployment and when, because at the next change you will know what to repeat.
For a coding agent working with permissions on your computer extra rules apply, described in the text An approvals checklist. You will find all materials on this area in the AI code security hub.
Last checked: 20 October 2026. The availability of GitHub features depends on the repository type and plan; check the current documentation.