AI Agent-to-Agent Attacks: Why Least Privilege Is No Longer Enough

AI coding agents and autonomous assistants are becoming part of modern development environments.

They can inspect repositories, analyze code, create pull requests, call APIs and interact with cloud infrastructure.

That creates a new security problem that traditional application security models were not designed to handle:

What happens when an untrusted AI agent can influence a more privileged AI agent?

Recent research involving Google's Agent Development Kit demonstrated an attack scenario in which one agent could manipulate another agent through its interaction and context.

The original security story was covered by Netbe Technology News:

AI Agents Can Manipulate Other AI Agents: A New Security Threat Emerges

But the interesting part for developers is what this means for application architecture.

The Traditional Permission Model

Consider a normal application architecture:

User
  |
  v
Web Application
  |
  v
API
  |
  v
Database

Every component has a defined role.

Authentication determines who the user is.

Authorization determines what the user can do.

The application decides which API calls are allowed.

Now introduce autonomous agents:

User
  |
  v
AI Agent A
  |
  +----> Tool
  |
  +----> AI Agent B
              |
              +----> API
              |
              +----> Cloud

The architecture becomes significantly more complicated.

An agent is no longer simply executing a predefined workflow.

It is interpreting information and deciding what to do next.

The Agent-to-Agent Attack Chain

Imagine the following environment.

Agent A is responsible for code analysis.

Agent B has permission to interact with a private repository.

Agent C can deploy applications.

Their permissions might look reasonable:

Agent A
  READ source code

Agent B
  READ/WRITE repository

Agent C
  DEPLOY application

The problem appears when Agent A processes attacker-controlled content.

For example, a malicious instruction could be embedded in:

README.md

or:

GitHub issue

or:

source code comment

The agent processes the content and generates an instruction for Agent B.

Agent B trusts the request because it came from another internal agent.

The attack becomes:

Malicious Content
       |
       v
    Agent A
       |
       v
 Manipulated Request
       |
       v
    Agent B
       |
       v
Privileged Operation

The attacker does not necessarily need to compromise Agent B directly.

The attacker exploits the trust relationship between agents.

Why Prompt Injection Is Different With Agents

Prompt injection is not a new concept.

The problem becomes more serious when an AI system can use tools.

A simple chatbot may generate a malicious response.

An autonomous agent may generate a malicious response and then execute an action.

For example:

Untrusted Input
      |
      v
Prompt Injection
      |
      v
AI Decision
      |
      v
Tool Invocation
      |
      v
Sensitive Resource

Once multiple agents are involved:

Untrusted Input
      |
      v
Agent A
      |
      v
Agent B
      |
      v
Tool
      |
      v
Production

The attack surface grows rapidly.

Least Privilege Still Matters

The first defense should still be least privilege.

An agent that only needs to analyze code should not have access to production credentials.

An agent that creates pull requests should not automatically be able to deploy them.

An agent that manages development infrastructure should not have access to unrelated customer databases.

A basic permission model might look like:

Code Review Agent
    |
    +-- Repository: READ
    +-- Issues: READ
    +-- Production: DENY
    +-- Secrets: DENY

This is much safer than:

AI Agent
    |
    +-- GitHub: FULL ACCESS
    +-- Cloud: ADMIN
    +-- Secrets: READ

But least privilege alone does not solve the entire problem.

The Missing Layer: Agent Trust

Consider two agents:

Agent A
    |
    | request
    v
Agent B

Even if Agent B has correctly configured permissions, it still needs to determine whether the request from Agent A should be trusted.

That means authorization needs to consider more than:

WHO is requesting?

It should also consider:

WHAT is being requested?
WHY is it being requested?
WHAT information influenced the request?
IS THIS ACTION EXPECTED?

This introduces something similar to intent validation.

Treat Agents as Security Principals

Each autonomous agent should have its own identity.

For example:

agent-code-review
agent-repository-manager
agent-deployment
agent-security-scanner

Each identity should have:

• unique credentials,
• narrowly scoped permissions,
• independent audit logs,
• defined responsibilities,
• and controlled communication paths.

Avoid architectures where every agent shares the same API key.

That makes attribution and containment much harder.

Short-Lived Credentials

Long-lived credentials are dangerous even with traditional applications.

They become even more problematic with autonomous agents.

Instead of giving an agent a permanent secret:

GITHUB_TOKEN=permanent-secret

use short-lived credentials whenever possible.

Conceptually:

Agent
  |
  v
Identity Provider
  |
  v
Short-Lived Token
  |
  v
API

If an agent is compromised, the window for abuse is reduced.

Tool Access Should Be Explicit

One of the most important design decisions is controlling which tools an agent can call.

Do not expose every available tool to every agent.

For example:

Code Review Agent

Allowed:
  read_repository
  search_code
  create_report

Denied:
  deploy_production
  read_secrets
  modify_firewall
  create_admin_user

This creates a much smaller attack surface.

Validate High-Risk Actions

Not every AI decision should have the same security requirements.

A useful model is:

LOW RISK
|
+-- Read documentation
+-- Analyze source code
+-- Generate text
|
MEDIUM RISK
|
+-- Create pull request
+-- Modify development configuration
|
HIGH RISK
|
+-- Deploy production
+-- Access secrets
+-- Modify IAM
+-- Change firewall rules

High-risk operations should require stronger authorization.

For example:

AI Agent
   |
   v
Policy Engine
   |
   +---- ALLOW
   |
   +---- DENY
   |
   +---- HUMAN APPROVAL

This prevents an AI agent from making a high-impact decision based solely on manipulated context.

Log the Entire Agent Chain

Traditional application logs often record:

user -> API -> action

Agentic systems need more context.

A useful audit trail should answer:

Which agent acted?
Which user initiated the task?
Which agent triggered the action?
What tools were called?
What data influenced the decision?
What permissions were used?
What was the final result?

For example:

User: developer-123

Agent: code-review-01

Input:
  repository PR #482

Tool:
  read_repository

Output:
  suspicious README instructions detected

Next Agent:
  repository-manager-02

Requested Action:
  modify repository

Policy:
  DENIED

Reason:
  request originated from untrusted repository content

This type of logging could become essential for incident response.

Network Segmentation Still Matters

Agent security should not replace traditional security controls.

It should complement them.

An AI agent should not have unrestricted network access simply because it is running inside a trusted environment.

Use:

• network segmentation,
• egress filtering,
• API allowlists,
• service identities,
• workload isolation,
• and strict firewall policies.

If an agent is compromised, containment should still be possible.

A Practical Architecture

A more secure multi-agent architecture could look like this:

                    USER
                      |
                      v
               +--------------+
               | Policy Layer |
               +--------------+
                      |
          +-----------+-----------+
          |                       |
          v                       v
   Code Agent               Security Agent
          |                       |
          v                       v
    Tool Gateway             Tool Gateway
          |                       |
          +-----------+-----------+
                      |
                Policy Engine
                      |
          +-----------+-----------+
          |                       |
          v                       v
       GitHub                  Cloud

The important part is that agents do not receive unrestricted access to infrastructure.

Every tool call passes through an authorization layer.

The Developer's New Responsibility

Developers deploying AI agents now have to think beyond model security.

A secure model does not automatically produce a secure application.

Security depends on the entire system:

Model
+
Prompt
+
Agent
+
Tools
+
Identity
+
Permissions
+
Data
+
Network
+
Policy

A vulnerability in any of these layers can affect the whole system.

Conclusion

AI agents are becoming software components with decision-making capabilities.

That makes them fundamentally different from traditional automation scripts.

The biggest risk may not be a single compromised AI agent.

It may be a chain of agents that trust each other too much.

The security model therefore needs to evolve from:

"Can this agent access the resource?"

to:

"Should this agent be allowed to make this request, based on where the request came from and what influenced it?"

Agent-to-agent trust is likely to become an important security boundary as autonomous software becomes more common.

For developers, the practical rules are straightforward:

Give agents their own identities.

Use least privilege.

Limit tool access.

Use short-lived credentials.

Validate high-risk actions.

Monitor agent-to-agent communication.

And most importantly:

Never assume that another AI agent is trustworthy simply because it is part of the same system.

---

Original source: Netbe Technology News — AI Agents Can Manipulate Other AI Agents: A New Security Threat Emerges