AI coding agents are often introduced as development assistants, which can make them seem relatively harmless. They answer questions, generate code, explain errors, and handle repetitive work that would otherwise consume time. That description is accurate right up until the agent can read a repository, modify files, execute commands, install packages, access external services, or connect to other systems on behalf of the person directing it.

At that point, the security model changes. The agent is no longer just producing text that someone may or may not use. It has become an active participant inside the development environment, with access to resources that may include source code, credentials, configuration files, test data, terminal sessions, cloud accounts, package managers, deployment scripts, browser sessions, and connected services.

This does not mean coding agents are inherently unsafe. The same could be said about PowerShell, SSH, an administrative account, or any other capability that becomes dangerous when its permissions exceed the work being performed. The issue is authority, not personality, and an AI agent that can act should be treated much more like a delegated operator than an unusually intelligent autocomplete feature.

That distinction changes the security question considerably. Asking whether a model can write secure code is useful, but it is no longer enough. The more important question becomes: what happens when the model is wrong while it has the authority to act on its answer?

A normal chat session has a fairly obvious boundary. Text is entered, text comes back, and somebody decides what happens next. A coding agent operating within an editor, terminal, repository, or cloud workspace can have a much larger blast radius because its output may immediately influence the environment in which the work is being performed.

Suppose an agent has permission to inspect an entire repository while fixing a small input-validation problem. The repository also contains deployment scripts, sample configuration, cached logs, an old database export, several environment files, and a few credentials somebody forgot were there. From the agent's perspective, all of that may simply appear to be potentially useful context.

Now add command execution. The agent can inspect package information, run tests, search directories, launch scripts, modify files, and perhaps install something it believes will solve the problem faster. None of those activities are inherently malicious, and most are exactly the capabilities that make coding agents useful. Still, they also mean that a mistake is no longer limited to a questionable block of generated code that someone has to copy and paste.

Consider a simple example. An agent is asked to fix a failing Python parser and decides that the easiest solution is to upgrade a dependency to a newer version, so it updates requirements.txt, installs the package, and adjusts several functions to match the new API. The parser now works, but another internal utility sharing that environment breaks because the dependency change was outside the original scope.

Nothing hostile happened. The agent solved the problem it was given and produced a functioning result. The security and operational problem stemmed from allowing the agent's blast radius to extend beyond what the task required.

Think of it like bringing a contractor into a data center to replace one failed power supply. Giving the contractor access to the affected rack makes sense, but handing over the master keys, administrator credentials, network diagrams, backup vault access, and permission to rearrange equipment would be difficult to justify. The fact that the contractor is competent does not remove the need to limit the job.

One of the easiest things to underestimate with AI-assisted development is context. More context often improves the agent's ability to understand a project, so the natural response is to provide everything available and let the model sort it out. That may improve coding performance while quietly increasing exposure.

A repository is not just code. It may contain internal hostnames, architecture notes, comments describing production behavior, API examples, troubleshooting output, customer-like test records, vulnerability findings, cloud configuration, credentials, and documentation that was never written with an AI agent in mind. Even relatively harmless files can become sensitive when combined with everything else the agent already knows about the system.

Imagine asking an agent to troubleshoot authentication failures and pasting a complete debug log into the conversation. Buried inside that log is an Authorization header containing a bearer token that nobody noticed because the interesting error appeared fifty lines later. The agent now has access to the same credential even though authentication design, not credential handling, was the actual subject of the task.

Another example appears with screenshots. A screenshot of a cloud console may help explain a deployment problem. Still, it can also expose account IDs, internal URLs, usernames, resource names, IP addresses, and other information around the part of the screen that actually matters. Context engineering therefore needs the same minimization mindset already applied to logs, support bundles, crash dumps, and incident artifacts.

This creates two different security concerns. The first is exposure, where unnecessary sensitive information enters the agent's working context and may later appear in generated output, logs, documentation, or other actions. The second is influence because some of the information given to the agent can change how it interprets the task.

That second problem becomes especially important once repository content begins to behave like instructions.

Coding agents frequently learn how to work with a project by reading files inside the project itself. Instruction files, contribution guides, development notes, README files, scripts, examples, and configuration can all shape what the agent believes it should do. This is extremely useful when those instructions are trusted and up to date, but it becomes dangerous when they are stale, misleading, imported from elsewhere, or deliberately hostile.

Consider an agent tasked with inspecting an unfamiliar repository and fixing a build problem. Buried in the documentation is a troubleshooting note stating that the build requires downloading a shell script from an external server and executing it before tests run. A human administrator might pause to question why a local build suddenly requires arbitrary remote code. In contrast, an agent with broad command permissions may interpret the note as legitimate project guidance and proceed.

The situation becomes more complicated when repositories include externally supplied material. A README may have been copied from another project, issue content may have been imported automatically, examples may come from a third-party package, and documentation may contain generated text. The project directory can therefore contain both trusted instructions and untrusted data without any visual distinction between the two.

A practical example would be a support ticket copied into a repository for troubleshooting. The ticket includes a block of text stating that anyone analyzing the issue should disable certificate validation, as the development service uses a temporary certificate. A human might recognize that as user-supplied troubleshooting advice, while an agent could interpret the same text as an operational instruction unless the task clearly defines which sources are authoritative.

This is similar to leaving a handwritten note next to the controls of an industrial machine. If the note says, “Before starting, disable the safety interlock,” the danger does not depend on whether the machine itself is defective. The problem is that somebody with authority may mistake untrusted instructions for approved operating procedure.

Repository trust therefore needs to be explicit. Documentation can explain the system without being allowed to redefine security policy, while imported content should never silently outrank approved project instructions. The agent should know which files provide authoritative guidance and which files are merely data to be inspected.

The ability to execute commands is one of the most useful capabilities an AI coding agent can have. It allows the agent to run tests, examine failures, inspect dependencies, format code, check syntax, search files, and verify that a change actually works. It also moves the agent from advisory software into something much closer to an automated operator.

A shell does not care whether a command came from a human or a language model. If the process has permission to delete a directory, the directory can be deleted; if it has permission to read a credential file, that file can be read. If outbound network connections are permitted, information can leave the environment, and if package installation is allowed, the dependency state can change whether anyone explicitly approved that change or not.

Consider an agent that encounters a missing Python module and decides to install it with pip install. The package name looks reasonable, installation succeeds, and the code begins working immediately. What remains invisible in that quick success is whether the correct package was selected, whether the package source was expected, whether it executed installation scripts, and what transitive dependencies arrived with it.

A second example involves troubleshooting. An agent examining a permission error may decide to rerun a command with sudo or an elevated PowerShell session because that clears the immediate obstacle. The application now works, but the agent has solved a permissions problem by increasing privilege instead of identifying why the original process lacked the access it needed.

That is an important difference. A successful command is not necessarily a correct security outcome, just as a service running as Administrator is not proof that a permissions problem has been fixed. Coding agents should therefore be allowed to execute commands within limits appropriate to the task, rather than be granted unlimited authority, because command execution makes development convenient.

Secrets have always been difficult to manage properly, and AI-assisted development gives them several new places to wander. API keys, access tokens, private keys, passwords, cloud credentials, signing material, database connection strings, and service credentials may appear in configuration files or environment variables that the agent can inspect while solving an unrelated problem. Once those values enter the working context, they can influence the generated output in ways nobody expected.

An agent need not intentionally steal a secret for the situation to become dangerous. It may paste a configuration example into the generated documentation, include a value in the debugging output, reproduce an environment variable while explaining why authentication failed, or insert a real credential into the generated test code because that credential happened to be present during the session. The behavior can be entirely logical yet still result in a security incident.

Imagine asking an agent to generate a curl command that demonstrates an API call. The project environment already contains API_TOKEN, so the agent produces a complete example with the actual token instead of a placeholder, since that version is immediately executable. Somebody copies the example into a ticket, or a documentation repository, and a credential that was never supposed to leave the workstation is now stored elsewhere.

The safest solution is not simply a prompt that says, “Do not reveal secrets.” That instruction is useful, but it should sit behind a stronger control: unnecessary secrets should not be available to the agent in the first place. An agent repairing a parser does not need cloud deployment credentials, and an agent generating unit tests should not require a production database password.

This is basic least privilege applied to a new type of operator. The concept has not changed just because the interface now accepts natural language. If access is not required for the work, removing that access is stronger than asking the agent to ignore it.

The attack surface expands when coding agents connect to external capabilities via systems such as the Model Context Protocol, plugins, extensions, APIs, browser automation, or other integrations. These connections can give an agent access to information and actions far beyond the repository on the local disk. They can also connect multiple trust zones that previously had very little direct interaction.

An MCP-connected agent might query documentation, inspect tickets, interact with databases, access cloud resources, retrieve files, communicate with development services, or call specialized utilities. This makes the agent dramatically more capable because the model is no longer limited to reasoning about information already supplied in the session. It also means that permissions, identity, and trust must be evaluated across multiple systems rather than just one.

Consider an agent with read access to an issue tracker and permission to execute database queries through another connected service. A support ticket contains instructions asking the developer to verify an account by querying a particular table and then update a field if the account appears inactive. If the agent treats the ticket contents as authoritative instructions, an untrusted, user-controlled field can indirectly trigger actions via a much more privileged database connection.

That is a variation of the confused-deputy problem. The ticket itself never had database authority, but it influenced an agent that did. Security, therefore, needs to consider not only what each connector can do, but also which information sources are allowed to trigger those actions.

Another example involves cloud operations. A coding agent may legitimately need read access to inspect deployment logs while troubleshooting an application, but a cloud connector capable of modifying resources introduces a very different risk. If the task needs observation rather than administration, the connection should reflect that difference.

The model is trustworthy for the work, and the connected service is legitimate. The weakness can still emerge from their relationship. Secure design, therefore, has to examine the entire action path rather than approve each component independently.

A useful way to approach coding-agent security is to assign a permission budget to every task. The budget represents the minimum authority needed for the agent to complete the work and demonstrate that it was completed correctly. This does not require a giant administrative process; it requires thinking about access before defaulting to everything.

For example, fixing validation in a parser might require read and write access to one application directory, access to its unit tests, and permission to execute the test suite. It probably does not require cloud credentials, unrestricted Internet access, production databases, or permission to modify unrelated infrastructure. The task itself tells us quite a bit about what the agent should and should not need.

A larger task naturally receives a larger budget. Updating authentication might require access to routes, middleware, configuration, tests, and database models, but that still does not automatically justify deployment privileges. The amount of authority should grow because the work requires it, not because broad permissions are easier to configure.

A short permission checklist can keep this manageable:

• Give the agent access only to files relevant to the current task.
• Remove production credentials and unrelated secrets from its environment.
• Require approval before installing dependencies or making major configuration changes.
• Restrict outbound network access when the task does not require it.
• Separate read-only inspection from actions that modify external systems.
• Review repository instructions before allowing the agent to treat them as authoritative.
• Inspect diffs and command history before accepting a completed task.

These are ordinary security practices applied to an environment in which software can now interpret and act on instructions. The controls are not complicated, and most can be implemented without significantly slowing development. Their value comes from limiting how far an ordinary mistake can travel.

Small Tasks Produce Smaller Security Problems

AI coding agents tend to be easier to control when they receive narrow tasks. A request to “modernize the authentication system” can touch routes, database schemas, session handling, middleware, configuration, dependencies, tests, interfaces, and deployment settings. The resulting change may be technically impressive while being extremely difficult to inspect.

A smaller task creates a smaller diff. “Add server-side role validation to these two administrative routes without changing the authentication mechanism or database schema” creates a much tighter engineering boundary. The agent can still identify additional improvements, but those suggestions do not automatically become permission to implement them.

Suppose the agent notices that the application uses an outdated authentication library while completing that work. A large, vague task might encourage it to replace the library, rewrite session handling, alter configuration, and update several routes in a single operation. A constrained task allows the agent to report the dependency issue while finishing the requested authorization change separately.

This separation makes review considerably easier. The authorization fix can be tested and accepted on its own, while the dependency replacement becomes another deliberate task with its own requirements and rollback plan. AI can generate large amounts of code quickly, but review capacity has not increased at the same rate.

That is why a thirty-file diff still deserves thirty files worth of attention. The fact that the model produced those changes in seconds does not make the security impact free. Small tasks keep generation speed aligned with the amount of change that can realistically be understood.

Trust the Result After Verification, Not Before

It is tempting to anthropomorphize coding agents because conversation can make them seem cooperative. They explain what they are doing, respond to corrections, acknowledge mistakes, and often provide convincing reasons for their decisions. None of that should determine the security model, because permissions should be based on capabilities rather than conversational style.

If the agent claims it modified only approved files, inspect the diff. If it says no dependency changed, verify the dependency and lock files. If it reports that tests passed, check the test execution rather than treating the summary as proof.

A practical example is an agent reporting, “I added authorization checks and all tests pass.” That sounds reassuring until inspection shows that the tests exercise the browser interface but never call the protected API directly. The agent may have implemented exactly what its tests measured while leaving the actual object-level authorization problem untouched.

Another example appears when the agent says a secret was removed from the codebase. Searching the current source may confirm that claim, while Git history still contains the credential in an earlier commit. Verification has to test the security property that matters, not merely the most obvious interpretation of the agent's statement.

This is not emotional distrust. The same approach applies to scanners, compilers, firewalls, deployment systems, and administrative scripts because systems can behave unexpectedly without possessing any intentions. AI simply makes the principle more visible because the system that created the change can also write a persuasive explanation of why the change is correct.

Explanation helps understand the work. Verification establishes whether it can be trusted.

Put the Agent on the Threat Model

Once an AI coding system can interact with files, commands, credentials, repositories, external services, or deployment environments, it belongs on the threat model. The questions are familiar: what information can it access, what actions can it perform, which sources can influence it, where are the trust boundaries, and what happens when it behaves incorrectly. Security professionals already know how to ask these questions; the new part is recognizing that the coding agent belongs in the diagram.

That does not require treating every AI development session as hostile activity. It requires acknowledging that an agent with authority has consequences beyond whether the generated code contains a vulnerability. The security boundary now includes the model, its context, repository instructions, permissions, connected services, execution environment, and the mechanisms that approve or restrict its actions.

The safest coding agent is not necessarily the least capable one. A highly capable agent operating within a well-defined boundary can be safer than a simpler agent with unrestricted access because capability and authority are distinct. The goal is to provide enough authority for the work without quietly providing enough authority to turn a routine mistake into a much larger operational problem.

AI coding agents are valuable precisely because they can increasingly perform work rather than merely describe it. That same capability is why they need to be treated as part of the attack surface rather than as something sitting outside it. The moment an agent can act, security has to account for where those actions can reach, what can influence them, and how far an incorrect decision can travel.