The developers are happy, the velocity is real, and nobody in the building is against it. Somewhere between the decision to adopt it and the code reaching production, three questions went unanswered — not because anyone avoided them, but because answering them was never on anyone's job description.
Let us be clear about the frame first, because this is easy to misread. This is not an argument against AI coding assistants. The productivity gain is real, developers who use them are not being reckless, and a company that bans them will lose people to one that does not. The argument is narrower and duller: a practice went from experiment to default without anyone writing down the rules, and the three decisions below are cheap to make now and expensive to make after an incident.
The three questions
What can the agent reach? Not what it is used for — what it is technically able to do.
What data leaves the building? Which code, which files, and under what contract with the provider.
Who checks what it produced? Before it merges, and before it deploys.
Ask three people in the same company and you will typically get three different answers to each, which is itself the finding.
Question one: what can the agent actually reach?
This is where the shift from autocomplete to agent matters, and it is easy to miss because the change was gradual. A completion tool suggests text and a human types. An agent reads across the whole repository, decides what to change and edits files — and, depending on how it has been configured, runs commands, installs packages and opens a pull request on its own.
Where nobody has decided otherwise, the permission model is implicit: the agent can do whatever the developer's machine can do. Which is worth spelling out, because a developer's machine typically has cloud credentials in environment variables, an SSH key, a package-registry token, a .env file with real values, and — in smaller companies — access to production.
None of that is an argument for panic. It is an argument for four decisions somebody should actually make:
- Execute, or propose? Can the agent run shell commands unattended, or does each one need approval? Unattended execution is the single largest expansion of what a mistake can cost.
- Install packages, or ask? An agent that installs its own dependencies can install a package that did not exist until an attacker registered the name it invented. Install scripts run before anyone reads anything.
- Push, or open a pull request? Proposing is almost always enough, and it preserves the one checkpoint that still involves a human.
- Whose credentials? If the agent runs with a developer's full personal access, every mistake has that person's blast radius. A separate, narrower identity costs an afternoon.
The same question applies in CI, where it is sharper: an agent with a pipeline token is operating with the credentials that reach production, and without a human in the room at all.
Question two: what data actually leaves
The honest starting point is that most people using these tools do not know precisely what is transmitted, and the answer differs per tool and per setting.
It is usually more than the file on screen. To be useful, an assistant needs context: neighbouring files, imports, type definitions, sometimes an index of the whole repository. Agents go further, because they read whatever they judge relevant.
Four categories are worth checking against your own repository, because they are the ones that cause a problem:
- Personal data in test fixtures. Extremely common, rarely deliberate. A production export was once used to build a realistic test, and it stayed. If that leaves for processing, it is a processing activity with your customers' data in it.
- Credentials in configuration. A committed key is already a problem on its own terms; being transmitted to a third party is an additional one.
- Code you do not own. Work done under a customer contract or an NDA may have terms about where it may be processed, and those terms were written before anyone considered this.
- The thing that is actually your business. Pricing logic, matching algorithms, models. Usually fine — but it should be a decision rather than an accident.
The contractual questions are short and worth getting in writing from the provider: is our input used to train models, what is the retention period, where is it processed, and is there a data processing agreement? The answers can be very different on the consumer and the business plan of the same product — training on your input, retention period and whether a data processing agreement is offered at all are commonly what separates the tiers — and that is the easiest detail to miss: a team can be on the wrong plan without anyone having chosen it.
If personal data is involved at all, this stops being a tooling question and becomes a data protection one, with the usual consequences for who is accountable. That is a conversation for whoever handles your GDPR compliance, not something to settle in a developer channel.
Worth saying plainly: no scanner solves this question. It is a procurement and legal decision. What tooling can do is tell you whether the checkable ones — committed credentials above all — are in the repository at all, which is a genuinely useful input to the decision, and not the same as making it.
Question three: who checks what comes out?
This is the one that quietly breaks, and the mechanism is arithmetic rather than negligence — the same arithmetic that makes asking developers to check their dependencies more carefully fail, applied one stage further down.
AI assistants increase how much code is produced. They do not increase how much code a human can carefully read. When the volume of pull requests goes up and the review capacity does not, review does not stop — it gets thinner. The same person approves more changes, reads less of each, and the approval keeps meaning what it used to mean on paper.
There is a second effect worth naming, because it is uncomfortable: reviewing generated code is psychologically different from reviewing a colleague's. It is fluent, well-formatted and confident, and there is no author to ask. Fluency reads as competence. A reviewer who would have questioned a colleague's odd import can let the same line pass when a machine wrote it.
What actually gets through, specifically:
- Dependencies nobody evaluated. The assistant picks a library that fits the problem, with no view on whether it is maintained, who can publish to it, or whether the name is one character from the real one.
- Credentials in generated examples. Assistants fill in placeholder values, and placeholders have a way of becoming real ones during debugging.
- A finding "fixed" by removing the check. Ask an assistant to make a failing security test pass and it may well oblige — by deleting the assertion. It did what you asked, and the only thing that notices is a check that looks at the code itself rather than at whether the suite went green.
- Deleted, not rotated. Ask it to remove a committed key and it will report success once the line is gone. The key is still in the history and still valid.
- Workflow and infrastructure files. These read as configuration and get reviewed like configuration, while running with more privilege than the application.
Notice what these have in common: none of them needs a human to spot it first. Each is a property of the code or the configuration that a machine can check on every change. That is the argument for automating this question rather than the other two — not because a machine reviews better than a person, but because this is the part where a machine reviews consistently, and consistency is exactly what thinning review loses first.
A one-page policy is enough
Nobody needs a governance programme for this. What is missing is a page that says who decided what, so the answer exists before somebody has to improvise it:
- Which tools are approved, and on which plan. Naming the plan matters more than naming the tool.
- What the agent may do unattended — execute, install, push — and what needs a human.
- What must never sit in a repository an agent can read. Real customer data, live credentials. The credentials half of that is mechanically checkable, which makes it the part worth enforcing rather than merely stating.
- What the gate before merge is, and that it does not depend on anyone remembering.
- Who owns the answer when a new tool appears — because one will, next quarter.
Written down, this takes an hour. The reason it does not happen is that it belongs to nobody: it is partly security, partly legal, partly engineering, and entirely the kind of thing that waits for a trigger. The trigger is usually an incident, a customer questionnaire, or an acquirer's due diligence — all of which arrive with someone else's deadline attached.
The point
The developers are not the problem here, and neither is the technology. What happened is ordinary: a practice became normal faster than the decisions about it got made, which is how most governance gaps form.
Two of the three questions are decisions somebody has to sit down and make. The third is a check that can run by itself, every time, without depending on how busy the reviewer was that week — and that is the one worth automating first, because it is the one that degrades silently.
What access should an AI coding agent have?
An AI coding agent should have less access than the developer running it, and four decisions are worth making explicitly: whether it can execute shell commands unattended, whether it can install packages by itself, whether it can push or only open a pull request, and whose credentials it runs with. Where none of those has been decided, the ceiling is implicit — the agent inherits whatever the developer's machine can reach, which typically includes cloud credentials, an SSH key, a registry token and sometimes production access.
What data is sent to an AI coding assistant?
An AI coding assistant usually sends more than the file on screen: to make a suggestion useful it needs context, so neighbouring files, imports, type definitions and sometimes an index of the whole repository can go with it, and how much varies by tool and by setting. Agents go further, because they read whatever they judge relevant. The categories worth checking your own repository for are personal data in test fixtures, credentials in configuration, code covered by a customer contract or NDA, and the logic that actually constitutes your business.
Is it a problem under GDPR to use an AI coding assistant?
It depends on whether personal data is involved, and in a lot of repositories it is — test fixtures built from a production export are common and rarely deliberate. If personal data is transmitted to a provider, that is a processing activity, and the questions to settle in writing are whether your input trains their models, how long it is retained, where it is processed and whether there is a data processing agreement. Those answers differ sharply between consumer and business plans of the same product. This is a matter for whoever handles your compliance rather than something to settle in a developer channel.
Does AI-generated code get reviewed properly?
AI-generated code tends to get less scrutiny per line than the code it replaced, and the mechanism is arithmetic rather than negligence. Assistants increase how much code is produced without increasing how much a human can carefully read, so review gets thinner rather than stopping. Generated code is also fluent and confident with no author to question, and fluency reads as competence — a reviewer who would have queried a colleague's odd import can let the same line pass when a machine wrote it.
What actually slips through when AI writes the code?
Five things recur when AI writes the code: dependencies nobody evaluated for whether they are maintained or even real, credentials left in generated example configuration, security findings "fixed" by deleting the check rather than the flaw, committed keys reported as removed when only the line was deleted and the key is still live in the history, and workflow files that read as configuration but run with more privilege than the application. All five are properties a machine can check on every change, which is why this is the part worth automating.
Where CodeControl fits — and where it does not
CodeControl answers the third question. It connects to your GitHub and checks what actually arrives: every dependency against known vulnerabilities, malicious and typosquatted packages, packages too new to have a history, committed credentials in the code and in the git history, licence obligations, and the workflow files that run with production access. It runs within a minute of every push, and every pull request gets a secret check on just the new lines before anyone merges — so the check does not depend on how much time the reviewer had.
It does not answer the first two, and it is worth being straight about that. CodeControl has no view on what permissions your agent runs with, and none at all on what your assistant transmits to its provider. Those are decisions for a person, not a scanner. What it can tell you is whether live credentials are sitting in the repository the agent reads — in the code and in the history — which is a useful thing to know before you make those decisions.