AI & Workplace Security
AI-generated code works. But who checked whether it’s secure?
Inxtinct Editorial Team · Sep 21, 2026 · 5 min read
A developer asks an assistant to produce a password-reset endpoint. The code runs, the tests pass and the ticket is almost done. A reviewer looks at the happy path, sees the expected response and approves the change.
What nobody checked is whether one user can reset another user's password by changing a value in the request. It is an illustrative scenario, but the failure mode is familiar: working software and secure software are not the same thing.
AI coding assistants can remove repetitive work and help developers navigate unfamiliar libraries. They can also produce plausible code that fits the immediate task while missing something the task description never asked about. That is a reason to improve review, not to declare AI coding off-limits.
Why normal review can fail
Code review often asks whether the code meets the ticket. Security review also asks who can reach the functionality, which data it exposes, what assumptions it makes about callers and whether it introduces a new dependency or permission.
The generated code may look especially persuasive because it is formatted cleanly, includes comments and resembles patterns developers have seen before. None of those are evidence of secure authorisation or correct handling of secrets.
The NCSC's secure AI development guidance treats secure design, development, deployment and operation as connected responsibilities. That is a useful mindset for reviewing AI-assisted work: a prompt that produces code is not the end of your security process.
A review checklist for AI-assisted changes
1. Verify authentication and authorisation separately
Authentication establishes who is making a request; authorisation determines whether that identity may perform the action. For every endpoint that reads or changes data, ask whether the permission check operates on the specific resource, not just whether the caller is signed in.
In the password-reset example, a signed-in user should not be able to change an arbitrary account identifier and gain a capability meant only for their own account. Add negative tests: what happens when another user's identifier is supplied?
2. Look for secrets and unsafe logging
A model may put an API key into a configuration example or suggest logging a full request body for debugging. Search for hardcoded secrets, tokens in URLs, personal information in logs and credentials exposed to client-side code.
If a real secret entered an unapproved prompt or was committed into a repository, use your incident process and rotate it as needed. Removing a line from the latest commit does not guarantee it disappeared from history or external systems.
3. Challenge dependency suggestions
Check that suggested packages exist, are maintained and have an appropriate licence and provenance. Do not blindly install a dependency because a model confidently named it. Review transitive dependencies and lockfiles as part of ordinary supply-chain controls.
A dependency scanner helps, but it does not decide whether the package is appropriate or whether the code uses it safely.
4. Examine input, output and data boundaries
Which inputs come from users, third parties or another AI system? Are they validated? Is the application applying parameterised queries or safe APIs rather than building commands and database queries from concatenated input? Is sensitive information returned to a caller who should not receive it?
Think about abuse cases alongside normal examples. A feature may behave well under expected values but fail when it receives a missing identifier, unexpectedly large content or a crafted document.
5. Check permissions and infrastructure changes
Some generated changes request broad service-account privileges or relax a cloud policy to make a deployment work. Treat permission expansion as a visible design choice that needs justification, approval and testing.
6. Run targeted security tests
Unit tests and conventional QA are still necessary. Add tests for denied access, malformed inputs, revoked credentials, unintended data exposure and failure behaviour. Automated analysis and dependency checks support this work; they don't replace a reviewer who understands the system.
Change what appears in the pull request
Require an AI-assisted pull request to explain the behaviour change, security assumptions, new dependencies, configuration changes and tests performed. You do not need a theatrical disclosure that “AI wrote this”. You need enough context for another engineer to assess the change.
A useful review comment is: “What stops a user with account A from requesting this action against account B?” A less useful one is: “Looks good, generated code is usually fine.”
Assign clear ownership. The developer remains responsible for the submitted code; the reviewer remains responsible for examining it. Treat the assistant as a tool, not a teammate who can be accountable for security decisions.
A simple team policy for AI coding
Rather than writing ten pages of prohibitions, agree on a few enforceable rules:
- Use approved assistants and accounts for company repositories.
- Don't share real credentials or restricted information with an unapproved tool.
- Review generated code to the same security standard as any other contribution.
- Require human approval for access-control, payment, authentication and infrastructure changes.
- Keep ordinary tests, dependency checks and security scanning in the delivery pipeline.
- Reassess permissions when assistant features gain repository or cloud access.
The review effort should be proportional to the change. A documentation typo and a new authentication middleware should not receive identical scrutiny.
An example review conversation
A reviewer sees an AI-generated function that fetches an invoice using a numeric ID. They ask the developer whether the lookup is restricted to invoices the current tenant may access. The developer adds a tenant constraint and a test showing that another tenant's invoice is denied.
The useful outcome is not “we caught the AI”. It is that the team used a reliable review habit which would also catch a human-written mistake.
Inxtinct's security consultancy can help teams review AI-assisted development practices and the controls around releases. The goal is to preserve the productivity benefit without treating a successful build as a security assessment.
