Coding agent security: what can it reach?
Stefan-Iulian Tesoi · · 8 min read
As safe as the narrowest thing it can reach, and no safer. Judge a connection by what it is structurally unable to do rather than by what a vendor promises it will not do, because the first is testable in an afternoon and the second is a sentence in a sales call.
Most coding agent security conversations go wrong in the first five minutes, because they are held as a debate about trust. Trust is the wrong frame. Nobody asks whether they trust a deploy key; they ask what it opens.
What does coding agent security actually cover?
Three surfaces, which get conflated and have different answers.
The first is what the agent can read. A backlog contains more than task descriptions: customer names in bug reports, revenue figures in prioritisation notes, an unannounced acquisition in a roadmap item. Teams reason carefully about repository access and hand over the backlog without a second look, though the backlog is often where the commercially sensitive material actually lives.
The second is what the agent can change. Reading is a disclosure question. Writing is an integrity question, and it is the one that determines whether your board still describes reality next month.
The third is where the data goes afterwards. An agent is a client talking to a service, and that service has its own infrastructure, its own model providers and its own retention. This surface is entirely a vendor question and cannot be mitigated by configuration.
The useful question is not "do we trust this agent". It is "if this credential were being used by someone hostile, what is the worst outcome, and would we find out". Both halves are answerable without trusting anyone.
Why capability beats intention
Because a limit that is enforced holds when the model misbehaves, and a limit that is requested does not.
This distinction has a name in the security literature. OWASP's Top 10 for Large Language Model Applications lists Excessive Agency as a category in its own right: harm that follows from granting a model more functionality, permission or autonomy than the task requires. The mitigation is not a better prompt. It is a smaller grant.
The practical consequence for agent access control is that instructions are not controls. "The agent is told not to close its own tickets" is a sentence in a system prompt, and system prompts are influenced by everything the model reads afterwards — including the text of a backlog item written by someone outside your company who filed a bug. A control is something the server refuses to do regardless of what the client asked.
The test is simple and worth running before any vendor conversation: ask what happens if the agent is instructed to do the thing it is not supposed to do. If the answer involves the model declining, that is a preference. If the answer is that the call returns an error, that is a control.
What should a connection be unable to do?
Four things, and they are the ones worth checking first because each removes a whole class of AI agent security risks rather than mitigating one.
| The limit | Why it matters | How to test it |
|---|---|---|
| Cannot close its own work | Keeps a human decision between "built" and "done" | Ask the agent to mark something done |
| Cannot widen its own access | A compromised agent cannot grow its blast radius | Ask it to grant itself another project |
| Cannot reach an ungranted project | Contains a mistake to one backlog | Ask it to list an unrelated project's items |
| Cannot erase the record | Anything undoable is survivable; unlogged is not | Ask it to remove an item permanently |
Laimonade is worth naming here because these are checkable claims rather than reassurances. A connected agent cannot mark work done, cannot add anything to the unattended-implementation queue including its own items, cannot reach a project the connection was not granted, and cannot read your Claude memory, chat history or uploaded files. Tools are declared Read, Write or Destructive, and the destructive ones — the ones that undo a human decision rather than the ones that lose data — prompt the client to confirm before running. Every tool and its permission is published in the MCP tool reference, which a build check compares against the server's own registry, so the page cannot quietly drift from what the server does.
One detail is a good illustration of capability thinking. A project API key cannot create a new project, even though a signed-in person can. The reason is that a key is scoped to the project it belongs to, and letting it create another would widen that scope without anyone agreeing to it. That is a limit chosen because of what the credential is, not because creating projects seemed risky.
Which questions are worth asking a vendor?
Seven, and the answers should exist in writing before the call rather than being produced during it.
- What can the connection reach that we did not explicitly grant? The answer should be "nothing", and there should be a way for us to list the grant ourselves.
- Which actions are irreversible? Not which are dangerous — which cannot be undone. Those are the only ones that need confirmation dialogs.
- Who is the work recorded as? A per-person credential preserves attribution. A shared key collapses every action onto one identity, which is fine until you need to know who did something.
- What happens when a credential is rotated? If rotation breaks every configured client at once, that is not a flaw, but it is a fact your runbook needs before the incident rather than during it.
- Where can we see the credential being used? A last-used timestamp is a small feature that answers "is something still connected that should not be" in one glance.
- Who are the subprocessors, and is the list maintained or generated? A hand-maintained list drifts. Laimonade's is checked on every build against the backend's actual outbound calls, which is the difference between a list that is true and a list that was true. It is published in the privacy policy.
- What is the retention, and what happens on cancellation? This is the surface configuration cannot touch, so it is the one that most needs to be written down.
Questions three, four and five are one question wearing three hats: whether the audit trail lets you reconstruct what happened. It is the thing teams ask about last and need most. The connection mechanics behind all of them are in connect your coding agent, and the granted set is managed from the MCP page.
When is the honest answer "not yet"?
When you cannot answer the reconstruction question, or when the backlog holds material that has no business leaving your network.
Three situations where waiting is the right call, and none of them is timidity:
- You use one shared credential for everything. Fix attribution first. An agent is not the problem; you already cannot tell who did what, and adding a fast actor to that is how a small mistake becomes an unattributable one.
- The backlog carries regulated data. Patient identifiers, card data or anything with a residency requirement in ticket descriptions is a data-flow decision, not a tooling decision, and it needs the compliance conversation before the pilot.
- Nobody owns the grant. If there is no named person who reviews what is connected and revokes what is stale, the connection will outlive the project that justified it. That is true of every integration and more consequential for one that writes.
The counter-argument deserves stating honestly: none of this is unique to agents. A CI runner with repository credentials and deploy rights has a larger blast radius than a backlog connection, and most teams approved that years ago without this scrutiny. The reason agents attract more attention is that they are new and they are fast, and speed turns a misconfiguration into a lot of actions before anyone looks. That is a real difference, but it is an argument for narrow grants and good logs rather than for abstaining.
The question people actually type — is it safe to use AI coding agents — has no general answer, because it is not about agents. Whether this connection, with this grant, leaves a record you could reconstruct is answerable this afternoon.
Frequently asked questions
Can an agent leak our source code?
Only what it is given, which is why the grant matters more than the agent. A backlog connection reads backlog items and writes status and evidence; it does not have repository credentials unless you gave it some separately. The realistic disclosure risk is the content of items — customer names, revenue notes, unannounced plans — rather than code, and that is worth auditing before connecting anything.
What happens if a credential is stolen?
It can do whatever the credential was granted, immediately, which is the argument for narrow grants and a visible last-used timestamp. Rotating a project API key stops the old one everywhere at once and by design, so every configured client needs updating in the same window. Per-person sign-in limits the blast radius to one person's access and preserves attribution while you work out what happened.
Does an agent need write access at all?
Yes, if you want it to hand work back rather than describe it in a chat window. Read-only is genuinely useful for a first fortnight, and it is a reasonable way to start a pilot that a security reviewer can approve. The limit worth keeping permanently is not write access — it is the authority to close work, which should stay with a person.
Is an agent riskier than a human contractor?
Differently risky, and the honest comparison is unflattering in both directions. A contractor has judgement and can be held to an agreement; an agent has neither, and acts faster. A contractor's activity is usually far less logged than an agent's. Narrow grants and complete records make the agent the easier of the two to reason about, which is not the same as the safer one.