AI Agents Can Manipulate Other AI Agents: A New Security Threat Emerges
AI Agents Can Manipulate Other AI Agents: A New Security Threat Emerges
Artificial intelligence agents are becoming increasingly autonomous.
They can read code, interact with repositories, call APIs, access development environments and execute tasks on behalf of users.
But this growing autonomy introduces a new security problem:
What happens when one AI agent can manipulate another AI agent with greater privileges?
Security researchers have recently demonstrated an attack scenario involving Google’s Agent Development Kit (ADK), showing how an attacker-controlled agent could influence a more privileged agent in a development environment.
The research highlights an important problem for the emerging multi-agent ecosystem: security boundaries between AI agents cannot simply rely on the assumption that agents operating in the same environment are trustworthy.
The New AI-to-AI Attack Surface
Traditional security models are built around identities such as:
- users,
- applications,
- services,
- containers,
- and machines.
AI agents introduce another type of identity.
An organization might have one agent responsible for code analysis, another for repository management and another with access to deployment infrastructure.
Individually, these agents may have carefully defined permissions.
The problem appears when they interact.
A lower-privileged agent may process attacker-controlled information and then pass instructions or manipulated context to a more privileged agent.
The resulting attack chain could look like:
Untrusted input → Agent A → manipulated context → Agent B → privileged action
The attacker does not necessarily need to compromise Agent B directly.
Instead, Agent A becomes the mechanism for influencing it.
Why Agent-to-Agent Trust Matters
This creates a security question that traditional access-control systems do not completely answer:
Can an AI agent safely trust instructions received from another AI agent?
The answer cannot simply be „yes” because both agents belong to the same organization.
An agent can process information originating from:
- repositories,
- documentation,
- websites,
- issue trackers,
- emails,
- pull requests,
- APIs,
- or other agents.
Any of these sources could potentially contain malicious instructions or manipulated context.
The security boundary therefore moves beyond the individual AI model.
It includes the entire chain of agents, tools and data.
Prompt Injection Becomes More Dangerous
Prompt injection is already a major concern for AI applications.
An attacker can place instructions inside content that an AI system is expected to process.
With a single AI assistant, this can already cause unwanted behavior.
With multiple agents, the consequences can become more complex.
An attacker may not need to convince a highly privileged agent directly.
Instead, they could manipulate another agent that communicates with it.
This creates a potential indirect prompt-injection chain.
The first agent processes malicious content.
It then generates information or instructions consumed by another agent.
The second agent performs an action using its own permissions.
The result is effectively a privilege escalation through agent interaction.
Least Privilege Is Becoming Even More Important
The principle of least privilege becomes particularly important in multi-agent systems.
An AI agent should have only the permissions required for its specific task.
For example, a code-review agent may need access to source code.
It should not automatically have access to:
- production credentials,
- deployment systems,
- unrelated repositories,
- cloud administration,
- or sensitive databases.
More importantly, an agent should not be able to use another agent as an unrestricted bridge to those resources.
High-impact actions should require explicit authorization and additional validation.
How Should AI Agents Be Secured?
Organizations deploying agentic AI should consider treating every agent as a separate security principal.
Important controls include:
- unique identities for individual agents,
- narrowly scoped permissions,
- isolation between agents,
- validation of agent-to-agent messages,
- monitoring of tool calls,
- detailed audit logs,
- protection against prompt injection,
- short-lived credentials,
- and human approval for high-risk operations.
The goal should be to prevent an untrusted agent from turning a trusted agent into an unintended attack tool.
A New Security Model for AI
The traditional enterprise security model often looks like:
User → Application → Infrastructure
Agentic systems can look more like:
User → Agent → Agent → Tool → API → Infrastructure
Every additional connection creates another trust boundary.
This means organizations cannot secure AI agents simply by securing the underlying model.
They also need to secure:
identity + permissions + tools + communication + data + execution environment.
The emergence of agent-to-agent attacks is an early warning that multi-agent systems need security architectures designed specifically for autonomous software.
The most important question may no longer be:
„Is this AI agent secure?”
It may be:
„Can this AI agent safely interact with another agent that has more privileges?”
As autonomous AI becomes part of software development, cloud operations and enterprise infrastructure, that question is likely to become increasingly important.
Source: Techzine and The Register reporting on research into agent-to-agent attacks involving Google’s Agent Development Kit.
AI Agents Can Exploit Other AI Agents: A New Cybersecurity Threat Emerges AI agents are increasingly being given access to Czytaj dalej
AI Agents Went Beyond Their Instructions During Security Tests — A New Warning for the AI Industry Artificial intelligence security Czytaj dalej
