"AI coding assistants are fundamentally changing how software is built, but governance has not kept pace."

Roey Eliyahu, CEO & Co-founder, Salt Security

Redeployed is a weekly newsletter that breaks down one important AI story at a time for leaders in technology. Every issue explains what the shift means for technology companies and how smart leaders can use it to get ahead.

For most of the past two years, the conversation around AI coding agents focused on productivity. Could they write code faster, debug issues, generate tests, review pull requests, or automate repetitive engineering work? As the technology improved, the answer increasingly became yes.

Teams connected agents to source code repositories, observability tools, terminals, cloud environments, and deployment pipelines. The more context agents had access to, the more useful they became, and that tradeoff looked reasonable.

Until researchers demonstrated what happens when that context becomes the attack vector.

This week, security researchers disclosed a technique called "Agentjacking," an attack that can trick AI coding agents into executing malicious instructions hidden inside Sentry error events. According to the report, the attack can expose environment variables, Git credentials, private repository URLs, and other sensitive information. In some scenarios, the agent may execute attacker-controlled actions using the developer's own permissions.

On the surface, it looks like another security vulnerability. In practice, it highlights a broader shift. AI agents are becoming part of the attack surface.

The Security Model Is Changing

Traditional application security was built around a relatively stable set of assumptions. Companies secured users, applications, infrastructure, and data. Security teams focused on controlling access, monitoring activity, and protecting systems from unauthorized actions.

AI agents introduce a new variable.

Unlike traditional software, agents actively consume information from multiple tools, interpret that information, and decide how to act on it. They read logs, review alerts, inspect repositories, analyze tickets, and interact with systems across the development environment.

That means the inputs themselves become increasingly important. A malicious instruction no longer has to target the developer directly. It may only need to target the information the agent consumes. The attack surface expands beyond systems and into context.

What Actually Changed

The significance of Agentjacking is not the specific vulnerability. Security teams patch vulnerabilities every day.

The more important shift is what the attack reveals about how AI systems operate.

For years, developers were trained to think about permissions in terms of users and applications. A user has access. An application has access. Actions happen within those boundaries.

AI agents blur those lines.

An agent may have access to repositories, monitoring systems, cloud environments, internal documentation, and deployment tooling simultaneously. It acts on behalf of a human while consuming information from multiple sources that the human may never review directly.

That creates a new challenge. The agent inherits the permissions of the developer, along with the risks associated with every connected system. As agents become more capable, the consequences of those permissions grow as well.

Why This Matters Beyond Security Teams

It would be easy to view this as a cybersecurity story, but it is really an organizational story.

Most companies are currently focused on increasing the capabilities of their AI tooling. They want agents to access more systems, automate more workflows, and reduce more manual work. That creates a natural incentive to expand permissions.

But every new integration increases the potential blast radius when something goes wrong.

A coding agent connected to a repository is one thing. A coding agent connected to repositories, observability systems, deployment environments, cloud infrastructure, and internal knowledge bases is something else entirely.

As organizations adopt AI agents more aggressively, security can no longer be treated as a review that happens after deployment. It becomes part of the architecture itself.

How Smart Teams Are Responding

The teams moving fastest are not slowing down their AI adoption. They are becoming more deliberate about how agents operate inside production environments.

Instead of granting broad access by default, they are creating permission boundaries around specific workflows. They are auditing tool integrations before deployment, reviewing how agents consume external inputs, and building verification layers around high-risk actions.

Some organizations are beginning to treat agents the same way they treat human employees. Access is granted based on responsibilities rather than convenience. Sensitive actions require additional oversight, and activity is monitored continuously.

The goal is not eliminating risk. It is preventing a productivity tool from becoming an operational liability.

This issue of Redeployed is brought to you by Tecla: As AI agents gain access to more systems, the challenge is no longer simply deploying them. Organizations increasingly need engineers who understand security, infrastructure, and AI workflows as a connected system. The teams moving fastest are building guardrails alongside automation, bringing in talent that can manage permissions, integrations, and operational risk from day one. Tecla helps companies hire senior tech talent in the U.S. and nearshore who already work across AI systems, cloud infrastructure, and secure production environments, so teams can scale AI adoption without expanding their attack surface.

Where the Real Risk Appears

The most dangerous aspect of agent-mediated attacks may not be the attack itself. It may be misplaced trust.

Developers are trained to evaluate code. They are less accustomed to evaluating the information flows that influence autonomous systems. As agents become more capable, teams may gradually stop questioning the context those systems consume.

A suspicious prompt is often obvious. A malicious instruction hidden inside a monitoring event, log entry, or external tool integration is much harder to spot.

Many existing security controls were not designed for that environment. They were designed for humans. As a result, organizations may discover gaps between what their security programs monitor and what their agents actually consume.

What This Means for Teams and Hiring

This shift is changing what companies need from engineering teams.

The demand is no longer limited to people who understand AI models. Organizations increasingly need engineers who understand how AI systems interact with infrastructure, permissions, observability tools, and production environments.

Security, platform engineering, and AI development are becoming more interconnected. Decisions that once belonged to separate teams increasingly overlap as agents move deeper into operational workflows.

The organizations that adapt fastest will treat agent security as an engineering discipline rather than a compliance exercise. Once agents become part of how work gets done, securing them becomes part of how the business operates.

What Smart Companies Will Do Next

The companies that benefit most from AI agents will continue expanding what those systems can do, but they will become equally disciplined about what those systems can access.

They will review permissions before incidents occur. They will audit integrations before workflows scale. They will build security controls around the context agents consume, not just the actions agents perform.

Because AI agents do not just automate developer work.

They inherit developer risk.

And as those agents become more powerful, that risk becomes harder to ignore.

Connect With Other Technology Leaders

If you want to connect with other technology leaders having real conversations about AI and how it is changing business, check out GILD Curated Circuit.

More to come…

Gino Ferrand, Founder @ Tecla

Keep Reading