2027: The Multi-Agent Organization and the Security of Agent-to-Agent Communication

This article is a forward-looking scenario in the DotlyGuard AI and cybersecurity series. It describes a possible direction for enterprise technology rather than a prediction that every organization will adopt multi-agent systems in 2027.

This article is Part 5 of From Generative AI to AI Agents: Why the Next Five Years Will Change Cybersecurity.

The first four stages of the AI transition were relatively easy to describe.

In 2023, AI generated.

In 2024, AI integrated into business workflows.

In 2025, AI increasingly began to act.

In 2026, organizations began thinking about what happens when AI agents become part of the operating structure of the enterprise.

The next logical question is more difficult:

What happens when one AI agent is no longer enough?

Instead of one agent performing an entire workflow, an organization may use multiple specialized agents.

One agent may research.

Another may analyze.

Another may communicate with customers.

Another may manage a business application.

Another may write or test software.

Another may monitor activity.

Another may coordinate the other agents.

This creates what we can call the multi-agent organization.

It is an emerging architectural possibility, not a universal description of businesses in 2027.

But if organizations move in this direction, cybersecurity will face a fundamental new problem.

The security question will no longer be only:

Can we trust this agent?

It will also become:

Can we trust the relationship between these agents?

A single-agent workflow can be represented as:

Human → Agent → Tool → Business System

A multi-agent workflow could look like:

Human → Agent A → Agent B → Agent C → Tool → Business System

Or:

Human → Coordinator Agent → Specialist Agents → Tools → Data → Actions

The architecture can become even more complex.

For example:

Customer Request → Customer-Service Agent → Research Agent → Pricing Agent → Billing Agent → CRM Agent → Customer Notification

The user may see only one interface.

Behind that interface, several software systems may be working together.

This can provide specialization and flexibility.

But every additional participant creates another trust relationship.

Traditional cybersecurity has spent decades protecting communication between:

• Users and applications

• Applications and APIs

• Servers and databases

• Devices and services

• Services and cloud infrastructure

Multi-agent systems introduce another relationship:

Agent → Agent

That relationship cannot simply be treated as ordinary application traffic.

The receiving agent needs to understand:

• Who sent the request?

• Which agent is it?

• Who authorized that agent?

• What task is it performing?

• What authority was delegated?

• What information can it access?

• What action is it requesting?

• Is that action within the original user's authorization?

This is why agent identity is becoming a significant area of security research.

NIST's work on agent identity and authorization explicitly considers how organizations can identify, authenticate, authorize, audit, and establish accountability for software and AI agents. By September 2026, NIST reported that its project had received feedback from more than 600 commenters and was moving toward an implementation use case involving AI agents in software development (NIST comments on software and agentic AI identity).

The direction is clear:

An agent needs an identity before an organization can meaningfully control its authority.

Consider a simple example.

Agent A is responsible for customer support.

Agent B is responsible for refunds.

A customer asks for a refund.

Agent A sends a request to Agent B:

"Issue a refund for this customer."

Should Agent B automatically comply?

Not necessarily.

Agent B may need to verify:

1. Who is Agent A?

2. Is Agent A authorized to request refunds?

3. Is this customer eligible?

4. Is the refund amount within the permitted limit?

5. Is the request associated with an authenticated user?

6. Does the request contain the required context?

7. Is the action allowed under current policy?

This is similar to traditional authorization.

But there is an important difference.

The requester is no longer necessarily a human.

It is another software agent.

That means authorization has to work across machine-to-machine relationships involving autonomous systems.

Suppose a human gives Agent A permission to handle customer support.

Agent A then delegates part of its work to Agent B.

Agent B delegates another task to Agent C.

Now consider the authority chain:

Human → Agent A → Agent B → Agent C

Where did Agent C get its authority?

Did the human authorize Agent C?

Did Agent A have permission to delegate?

Did Agent B have permission to delegate further?

Did the original authorization allow this chain?

These questions become critical.

An agent should not be able to gain additional authority simply by passing a request through another agent.

This is sometimes described as preventing privilege escalation through delegation.

The fundamental principle remains:

Delegation should not silently expand authority.

Multi-agent systems create chains of trust.

Consider:

Human → Agent A → Agent B → Agent C → Database

The database may trust Agent C.

But Agent C may have received its instruction from Agent B.

Agent B may have received its instruction from Agent A.

Agent A may have been initiated by a human.

If something goes wrong, the organization needs to understand the complete chain.

This creates a new security requirement:

Traceability across delegated actions.

Security teams may eventually need to reconstruct not only what happened, but how authority moved through the system.

Communication between agents can introduce several classes of risk.

For example:

Identity spoofing

An attacker attempts to make an agent appear to be another trusted agent.

Message manipulation

A request is modified before reaching the receiving agent.

Unauthorized delegation

One agent attempts to delegate authority it does not possess.

Instruction injection

Malicious content is inserted into a message between agents.

Context manipulation

An agent receives incomplete or misleading information.

Replay

A previously valid instruction is submitted again.

Trust exploitation

An attacker compromises one trusted agent and uses its relationships to reach other systems.

Cascading failure

One compromised or malfunctioning agent causes other agents to take inappropriate actions.

OWASP's 2026 agentic security materials explicitly identify insecure inter-agent communication, identity and privilege abuse, cascading failures, and rogue agents among the risks that organizations need to consider (OWASP Top 10 for Agentic Applications crosswalk).

This is one of the major differences between a single-agent system and a multi-agent environment.

With one agent, the security boundary is relatively centralized.

With many agents, trust relationships multiply.

Imagine an organization with five agents.

Agent A receives a request.

It asks Agent B to analyze information.

Agent B asks Agent C to update a record.

Agent C asks Agent D to send a message.

Agent D triggers Agent E to perform another operation.

Now imagine that the original instruction was malicious.

The system may have transformed one malicious input into a chain of legitimate-looking operations.

The resulting sequence could look like:

Malicious Input → Agent A → Agent B → Agent C → Agent D → Agent E → Business Impact

This is a cascading action problem.

The individual agents may each appear to be functioning correctly.

The problem exists in the overall chain.

This is why security testing cannot focus exclusively on individual components.

The interactions between components matter too.

When a human directly performs an action, attribution is relatively straightforward.

A user logs in.

The user performs an operation.

The system records it.

In a multi-agent environment, the chain may look like:

User → Agent A → Agent B → Agent C → API

If the API logs only Agent C, the organization may lose important context.

The security record needs to answer more questions.

Who initiated the task?

Which agent received the original instruction?

Which agents participated?

Which permissions were delegated?

Which tools were invoked?

What data was accessed?

Which action created the final change?

This is where provenance becomes important.

Organizations need to understand the origin and progression of an action.

Giving every agent an identity is an important step.

But identity by itself does not solve the problem.

Consider two agents:

Agent A

Purpose: customer support

Permissions: read customer tickets

Agent B

Purpose: billing

Permissions: issue refunds

Both have valid identities.

Now Agent A asks Agent B to issue a refund.

The question is not simply:

Is Agent A real?

The question is:

Is Agent A authorized to request this operation from Agent B?

This introduces multiple layers of authorization.

Identity

Who is the agent?

Authentication

Can the system verify that identity?

Authorization

What can the agent do?

Delegation

Can the agent ask another agent to perform an action?

Scope

What limits apply to the delegated authority?

Duration

How long is that authority valid?

Auditability

Can the organization reconstruct what happened?

NIST's agent identity work specifically highlights these areas, including identification, authentication, authorization, auditing, and non-repudiation (NIST concept paper on software and AI agent identity).

Least privilege is relatively easy to describe when there is one user and one application.

Multi-agent systems introduce delegation.

Suppose:

Agent A can read customer information.

It calls Agent B, which can access billing.

Agent B then calls Agent C, which can modify financial records.

The original workflow may unintentionally create a path from customer-support permissions to financial-system permissions.

This is why organizations need to think about effective authority, not just direct permissions.

An agent may have limited permissions itself but still have access to a powerful downstream capability through another agent.

The security question becomes:

What can this agent ultimately cause?

That is more important than simply asking:

What can this agent directly access?

Traditional security teams often think about blast radius.

If an account is compromised, how much damage can the attacker cause?

The same concept applies to agents.

If an agent has:

• One read-only permission

its potential impact may be limited.

If it can:

• Read customer data

• Modify records

• Send emails

• Execute code

• Create users

• Invoke administrative APIs

its potential impact is much broader.

Now multiply that by multiple agents.

A compromised coordinator agent could potentially influence several downstream agents.

This means the architecture needs boundaries.

One agent should not automatically inherit the authority of every other agent.

Traditional networks use segmentation to limit movement.

Applications may also use service boundaries.

Multi-agent systems can benefit from similar architectural thinking.

Instead of:

Agent A → Everything

the system can use:

Agent A → Approved Agent B

Agent A → Approved Tool C

Agent B → Approved Data D

Agent C → Approved API E

This creates a controlled graph of relationships.

The goal is not to prevent agents from working together.

The goal is to prevent unnecessary trust.

A useful principle is:

Connect agents because the workflow requires it, not because connectivity is technically possible.

As organizations deploy more agents, their architecture may become easier to understand as a graph.

For example:

Human → Coordinator Agent → Research Agent / Analysis Agent / Operations Agent → Web Tool / Database / Business API

The graph shows more than system architecture.

It also shows trust.

Each connection represents a relationship that may need:

• Authentication

• Authorization

• Policy

• Monitoring

• Logging

• Rate limiting

• Validation

• Isolation

This creates a new security concept:

The agent graph is part of the attack surface.

Traditional security monitoring often focuses on endpoints, users, applications, networks, and infrastructure.

A multi-agent environment adds another layer.

Security teams may need to understand:

• Which agents are communicating?

• How often?

• Which agents invoke which tools?

• Which agents access sensitive data?

• Which agents create downstream actions?

• Are there unexpected communication paths?

• Did an agent suddenly begin calling a new service?

• Did an agent's behavior change?

• Did an agent begin requesting broader authority?

The goal is not necessarily to monitor every AI thought.

The goal is to observe security-relevant behavior.

That distinction is important.

Security teams need actionable evidence, not an enormous stream of model-generated text.

Explore Security Monitoring →

Even in a future dominated by software agents, endpoints do not disappear.

People still use computers.

Developers still write software.

Administrators still manage infrastructure.

Employees still access business systems.

AI agents may run:

• In browsers

• On developer workstations

• In cloud services

• In internal applications

• On servers

• In automation environments

This means endpoint security remains part of the larger architecture.

A compromised endpoint could become the starting point for an AI-driven attack chain.

For example:

Compromised Endpoint → Stolen Identity → AI Application → Agent → Tool → Business API → Sensitive Data

The fact that an AI agent is involved does not eliminate traditional cybersecurity risks.

It can amplify the consequences of existing weaknesses.

That is why endpoint visibility, endpoint monitoring, vulnerability management, threat detection, and security monitoring remain important foundations.

Consider a business with an outdated workstation.

That workstation has access to an AI development environment.

The developer's credentials are available to the environment.

An agent can use those credentials to access an internal system.

A vulnerability on the endpoint therefore becomes connected to an AI workflow.

The vulnerability itself may be conventional.

The consequences may not be.

This is an important lesson:

New AI risks do not replace traditional vulnerabilities. They can connect traditional weaknesses to new execution paths.

That makes vulnerability management increasingly important.

Security teams need to understand not only whether a weakness exists, but also whether the affected system sits on an important operational path.

Imagine receiving an alert:

"API request denied."

That may be useful.

But imagine receiving:

"Agent B attempted to invoke the billing API using delegated authority from Agent A, outside its approved workflow."

That is much more useful.

Context changes the value of an alert.

A security platform therefore needs to move toward understanding relationships between events.

For example:

Endpoint Event + Identity Event + Agent Activity + API Activity + Data Access = Security Context

The goal is not simply to generate more alerts.

The goal is to provide enough context for humans to determine whether an event requires investigation.

Explore Endpoint Security Alerts →

Multi-agent systems do not necessarily require a human to approve every operation.

That would eliminate much of the value of automation.

Instead, organizations may establish boundaries.

For example:

Low-risk action

Agent performs automatically.

Medium-risk action

Agent performs automatically but records the operation.

Higher-risk action

Agent requests approval.

Critical action

Human approval is mandatory.

This creates a practical approach to autonomous systems:

Autonomy within boundaries.

The boundaries become the security controls.

The question is too broad.

A better set of questions is:

What can this agent do?

What can it access?

Who authorized it?

Who can it delegate to?

What can those agents do?

How far can the chain travel?

What happens if one agent is compromised?

Can we stop the chain?

Can we reconstruct the chain afterward?

These questions are measurable.

They can become architecture requirements.

A practical security architecture could be built around several principles.

1. Give every agent a verifiable identity

An organization needs to know which agent is making a request.

2. Define explicit authorization

Identity should not automatically grant access.

3. Control delegation

An agent should not automatically be able to delegate all of its authority.

4. Limit tool access

Agents should only have access to the tools required for their purpose.

5. Limit data access

Sensitive information should require appropriate authorization.

6. Record security-relevant activity

Organizations should maintain useful audit trails.

7. Monitor agent relationships

Unexpected communication patterns can be security signals.

8. Control high-impact actions

Important operations may require additional authorization or human approval.

9. Maintain endpoint security

Devices remain part of the execution environment.

10. Prepare for failure

Organizations should assume that individual components can fail or become compromised.

NIST's 2026 AI security work reflects this broader direction. Its research agenda now explicitly includes single-agent and multi-agent systems, while its agent identity initiative focuses on authentication, authorization, and secure human-agent and multi-agent interactions (NIST AI Research — Security and Resilience).

The cybersecurity platform of the future will need to connect more than endpoints.

It will need to help organizations understand the environment in which humans and software agents operate.

The layers could look like:

People → Endpoints → Identity → Applications → AI Agents → Agent Relationships → Tools → APIs → Data → Actions → Security Monitoring

This does not mean one cybersecurity product has to own every layer.

It means organizations need enough visibility and control across these layers to understand risk.

The security platform becomes increasingly important because fragmentation creates blind spots.

If one system knows about the endpoint, another knows about identity, another knows about the application, and another knows about the agent, security teams need ways to connect those signals.

Modern software already depends on supply chains.

Applications use:

• Libraries

• Packages

• APIs

• Cloud services

• External vendors

• SaaS platforms

AI agents may create another type of dependency.

An organization may deploy an agent built by one vendor.

That agent may use another model provider.

It may invoke external tools.

It may call another agent.

That agent may use additional services.

The resulting architecture becomes a chain of dependencies.

Security teams therefore need to ask:

Which components does this agent trust?

Which external services does it depend on?

Which other agents can it invoke?

What happens if one dependency changes?

Can the organization identify the source of an unexpected behavior?

The more interconnected the ecosystem becomes, the more important supply-chain visibility becomes.

Automation follows predefined instructions.

For example:

If invoice received → validate → store → notify

Agentic coordination can be more dynamic:

Understand request → determine what needs to happen → select another agent → retrieve information → evaluate result → perform action

That flexibility is useful.

But flexibility also introduces uncertainty.

The more freedom an agent has to decide which agent or tool to invoke, the more important authorization and monitoring become.

The objective should not be to remove flexibility.

It should be to bound flexibility with policy.

It is important not to assume that every organization will become a multi-agent organization by 2027.

Some companies may continue using traditional software.

Some may use a few AI assistants.

Some may deploy specialized agents.

Others may experiment with multi-agent workflows.

Adoption will depend on cost, reliability, regulation, business value, technical maturity, and security requirements.

But the architectural possibility is important enough to prepare for.

NIST is already treating multi-agent security as a distinct area of research, and its 2026 AI security work explicitly includes multi-agent systems (NIST AI Research — Security and Resilience).

The question for security teams is therefore not:

"Will every company become multi-agent?"

It is:

"If our organization adopts multiple interacting agents, will our security architecture be ready?"

The security lesson of this stage is different from the previous years.

2023

What information are we giving AI?

2024

What systems can AI access?

2025

What can AI do?

2026

How do we secure an organization where AI can act?

2027

How do we secure AI agents interacting with one another?

The security boundary continues to expand.

First, we secured the user.

Then the application.

Then the AI system.

Now we have to consider the relationships between autonomous systems.

Looking back at the series:

2023 — AI generates information. (Part 1)

2024 — AI becomes embedded into workflows. (Part 2)

2025 — AI begins taking actions. (Part 3)

2026 — AI becomes part of enterprise operations. (Part 4)

2027 — Multiple agents may coordinate work. (this article)

2028 — The organization itself may increasingly be designed around AI-native workflows. (Part 6)

This does not mean humans disappear.

It means software may become increasingly capable of coordinating parts of the business.

And when the architecture changes, cybersecurity has to change with it.

There is a common mistake when discussing the future of AI.

People focus on the intelligence.

But intelligence is only one part of the system.

The other parts are:

Identity

Permissions

Endpoints

Applications

Data

Tools

APIs

Monitoring

Security

Human oversight

A powerful AI system operating inside a poorly secured environment does not automatically create a secure business.

In fact, greater autonomy can make weaknesses more consequential.

That is why the cybersecurity platform remains foundational.

Organizations need to know:

What exists?

Who is using it?

What is connected?

What can act?

What can it access?

What vulnerabilities exist?

What activity is occurring?

What looks suspicious?

What happened when something went wrong?

These questions existed before AI.

AI makes them more interconnected.

The multi-agent organization is a possible next stage in the evolution of AI.

Its defining characteristic is not simply that there are more AI models.

It is that multiple autonomous systems may coordinate work.

That creates a new security boundary:

Agent → Agent

Every relationship creates a question of identity.

Every delegation creates a question of authority.

Every tool creates a potential attack surface.

Every shared piece of context creates a potential trust problem.

Every autonomous action creates a need for accountability.

And every chain of actions creates a need for visibility.

The most important security principle may therefore become:

An agent should never receive more authority simply because another trusted agent asked it to act.

Trust must remain bounded.

Authority must remain traceable.

Actions must remain observable.

And the organization must be able to understand what happened when the system behaves unexpectedly.

This is why the cybersecurity architecture built today matters.

Endpoint security remains relevant.

Endpoint visibility remains relevant.

Vulnerability management remains relevant.

Threat detection remains relevant.

Security monitoring remains relevant.

Identity remains relevant.

The AI era does not remove these foundations.

It connects them to a much larger execution environment.

The next stage of the journey takes this even further.

What happens when businesses stop treating AI as something added to existing software and begin designing the business itself around AI?

That is the possibility we explore next:

**2028: The AI-Native Business and the New Definition of Cybersecurity.**

Continue with Part 4: The Agentic Enterprise or return to the series introduction.

Introduction: From Generative AI to AI Agents

Part 1: 2023: The Generative AI Revolution

Part 2: 2024: When AI Entered the Business Workflow

Part 3: 2025: The Rise of Agentic AI

Part 4: 2026: The Agentic Enterprise

Part 5: 2027: The Multi-Agent Organization and the Security of Agent-to-Agent Communication (this article)

Part 6: 2028: The AI-Native Business