Engineering teams have given AI tools access to the crown jewels faster than almost any other department: source code, API credentials, cloud infrastructure, and deployment pipelines. A coding assistant that autocompletes a function is fairly low risk. An agent with permission to run commands, install dependencies, commit code, or trigger a deployment is operating with the same kind of authority a new engineer would get on their first day, except it moves faster and doesn't necessarily understand the informal rules a human engineer would pick up through months on the team. The risk isn't hypothetical either: AI-generated code can introduce vulnerabilities just as easily as it can fix them, and an agent with infrastructure access can misconfigure something in seconds that would take a careless human much longer to break.
Where AI shows up in the engineering workflow
Code completion and generation, automated code review and testing, documentation generation, and increasingly, agents that can run terminal commands, manage dependencies, open pull requests, or interact directly with cloud infrastructure are the common deployments. The command-running and infrastructure-touching agents carry the most risk, since they're not just producing text for a human to review, they're taking actions with real system-level consequences.
Source code and secrets exposure
Coding assistants routinely have access to an entire codebase, including hardcoded credentials, API keys, and internal architecture details that shouldn't leave the organization's control. Many coding assistants send code context to a third-party model provider by default, and engineering teams need to know exactly what leaves the network, whether that data is retained or used for model training, and whether sensitive repositories are excluded from that flow entirely.
Supply chain risk from AI-suggested dependencies
AI coding assistants can suggest packages or dependencies that don't exist, are outdated, or in some documented cases have been deliberately published by an attacker anticipating exactly this kind of AI-driven suggestion, sometimes called package hallucination or slopsquatting. Automated dependency installation triggered by an agent without a human verifying the package name and source is a meaningfully different risk than a human developer copying a well-known library, and it deserves its own verification step before anything gets installed.
Action risk from agents with infrastructure access
An agent that can run shell commands, modify infrastructure configuration, or deploy code is operating close to production systems, and a prompt injection buried in a code comment, a malicious pull request description, or a compromised dependency's documentation can potentially steer that agent toward an unintended action. These agents need scoped, least-privilege credentials rather than broad admin access, and any irreversible action, deleting resources, pushing to production, rotating credentials, should require explicit human approval rather than autonomous execution.
Code review still has to catch AI's mistakes
AI-generated code needs the same security review any human-written code would get, and arguably more scrutiny early on, since a model can produce code that looks idiomatic and correct while containing a subtle vulnerability, an injection flaw, a missing authorization check, that a quick glance won't catch. Treating AI-generated code as pre-vetted because it came from a capable model is a mistake teams make more often than they'd like to admit.
Regulatory and compliance considerations, in general terms
Software engineering doesn't carry the same sector-specific regulatory weight as healthcare or finance directly, but code that processes regulated data inherits whatever obligations apply to that data, and AI coding tools touching that code need to respect the same data handling boundaries. Organizations with security certifications or compliance obligations should confirm AI coding tool vendors don't introduce a new, unreviewed data flow that undermines an existing compliance boundary.
Where TELEON fits
TELEON's policy enforcement and audit trail are directly relevant where a coding agent has tool access to run commands, manage infrastructure, or interact with external services, providing scoped permissions at the tool-call boundary and a record of what commands were executed and approved. It doesn't review code quality or catch vulnerabilities in generated code, that remains the job of static analysis, testing, and human code review working alongside it.
A short checklist
- Confirm what code and data leaves the network to third-party coding assistant providers.
- Exclude sensitive repositories and credentials from AI coding tool context where possible.
- Verify AI-suggested package names and sources before automated installation.
- Scope agent infrastructure credentials to least privilege, never broad admin access.
- Require human approval for irreversible infrastructure actions triggered by an agent.
- Apply standard security code review to AI-generated code, without exception.
- Monitor agent command execution for patterns consistent with prompt injection.
- Test coding agents against malicious content embedded in comments, PRs, or dependency docs.
Engineering teams are usually the ones building the AI security controls other departments rely on, which makes it a little ironic how quickly some teams hand broad infrastructure access to their own coding agents without applying the same scrutiny they'd insist on for a customer-facing feature. The standard shouldn't be different just because the agent is helping the people who built the system.