Coding agents write, run, and sometimes commit or deploy code with minimal human review in between, which puts them in an unusual position among agent types: their output isn't just information or a single action, it's a set of instructions that will itself run with whatever permissions the resulting system has. A coding agent that writes a script with a subtle logic flaw, or one manipulated into embedding something malicious, doesn't cause damage directly. It causes damage the next time that code executes, which might be immediately in a sandbox, or might be after it's merged and deployed to production weeks later. That delay between the agent's action and the actual impact is what makes coding agent security distinct from most other agent use cases.

Execution environment isolation is non-negotiable

Any code a coding agent writes and then runs to test or verify itself needs to execute in an isolated environment with no path to production systems, credentials, or sensitive data. This sounds obvious, but it's a common shortcut under time pressure to let a coding agent run in an environment that's "basically" isolated but shares a network, a credential store, or a filesystem mount with something that matters. A coding agent's execution sandbox deserves the same rigor as any other untrusted code execution environment, because from a security standpoint, that's exactly what it is.

Dependency and package risk gets a new source

A coding agent that can add dependencies or pull in packages introduces a new path for supply chain risk: it might select a package based on a plausible-sounding name that turns out to be malicious or typosquatted, especially if it's working from training data that's out of date relative to the current package ecosystem. Automated dependency scanning and an allowlist of vetted packages matter more here than in a workflow where a human developer is choosing each dependency deliberately.

Generated code deserves the same review as human-written code

It's tempting to treat AI-generated code as lower risk because it often looks clean and well-structured, but clean-looking code can still contain a logic error, an injected credential, or a subtly unsafe pattern, sql string concatenation instead of parameterized queries, for instance. Code review, static analysis, and security scanning need to apply to agent-generated code with the same rigor as human-written code, not a lighter pass because it "looks fine."

Commit and deployment actions need their own gate

Writing code in a sandbox is low risk. Committing it to a shared repository, merging it, or deploying it to any environment beyond the sandbox is a different category of action and deserves its own authorization check, separate from whatever let the agent write and test code in the first place. An agent that can freely iterate in its own sandbox but needs explicit approval to merge or deploy captures most of the productivity benefit while keeping the highest-impact step gated.

Prompt injection through the codebase itself

A coding agent working across an existing codebase can encounter injected instructions in comments, commit messages, issue descriptions, or even variable names, anywhere text exists that the agent will read as part of its context. Treating a codebase as a fully trusted source just because it's internal misses this vector, especially in codebases with external contributors or dependencies pulled from public sources.

Secrets in the codebase are a specific, recurring failure mode

A coding agent working across a real codebase will frequently encounter existing secrets, API keys, connection strings, tokens checked in by mistake long before the agent arrived, and a coding agent that isn't specifically constrained can end up echoing those secrets into logs, commit messages, or even generated documentation without any malicious intent at all. This is less an exotic attack and more a predictable consequence of an agent treating everything in its context as fair material to reference or reproduce. Secret-scanning applied to what the agent reads as well as what it writes, and explicit instructions to treat detected credentials as sensitive rather than as ordinary code content, closes a gap that pure output scanning alone tends to miss.

Where TELEON fits

For coding agents that call out through defined tools, running tests, requesting a deployment, opening a pull request, TELEON's enforcement at the tool-call boundary can apply separate policy to sandbox actions versus commit and deployment actions, requiring approval specifically at the higher-impact step regardless of how the agent's internal reasoning got there, with an audit trail of what was run, committed, or deployed and by which authorization.

Building the actual execution sandbox and dependency scanning is specialized infrastructure work that sits outside gateway-level policy enforcement.

A short checklist

  1. Run all agent code execution in an isolated sandbox with no path to production.
  2. Scan and allowlist dependencies the agent introduces, treating them as supply chain risk.
  3. Apply the same code review and static analysis to agent-generated code as human code.
  4. Gate commit, merge, and deployment actions separately from sandboxed iteration.
  5. Treat comments, commit messages, and issues as potential injection vectors.
  6. Require explicit approval before any agent action reaches a shared or production environment.
  7. Log what the agent ran, committed, or deployed for every consequential action.

Coding agents compress the usual gap between writing software and running it, which is most of their appeal and most of their risk. Treating the sandbox as genuinely isolated and the commit or deploy step as a real gate, rather than a formality once the agent has proven itself a few times, keeps that compression from becoming the fastest way to ship a mistake to production.