FortiOS 8.0 MCP/A2A Agent Protocol Support Technical Insight

I. Introduction: New Cybersecurity Challenges in the Agentic AI Era

1.1 Background and Motivation

From 2024 to 2025, artificial intelligence technology is undergoing a profound paradigm shift from "large language model dialogue" to "autonomous agent collaboration." AI agents are no longer merely tools responding to user queries but intelligent entities capable of autonomous planning, tool invocation, and collaborative work. According to industry forecasts, by 2026, over 80% of enterprises will deploy AI agent applications in production environments, presenting unprecedented cybersecurity challenges.

Core characteristics of AI agents include: autonomous decision-making capabilities, multi-tool invocation, multi-system coordination, and complex data flow. These features pose severe challenges to traditional cybersecurity defense systems—agents can autonomously access sensitive data, invoke external APIs, and exchange information with other agents, behaviors that are often difficult to identify and audit within traditional network monitoring systems.

In this context, Fortinet pioneered the introduction of native support for two agent communication protocols—MCP (Model Context Protocol) and A2A (Agent-to-Agent Protocol)—in FortiOS 8.0. This marks mainstream network security vendors formally incorporating AI agent protocols into enterprise security defense systems, providing critical technical support for addressing emerging AI workloads.

1.2 FortiOS 8.0 Agentic AI Protocol Support Overview

FortiOS 8.0's Agentic AI protocol support functionality is built upon the mature Application Control module, implementing deep detection and monitoring of MCP and A2A protocols through a newly added GenAI (Generative AI) application signature database. The core value of this functionality is reflected in the following dimensions:

Protocol-level visibility: Capable of identifying and recording all key operations of agent protocols, including method invocations, parameter passing, and message content, providing unprecedented AI traffic visualization capabilities for security teams.

Risk assessment capabilities: Based on protocol characteristics and contextual information, FortiGate can assess the risk level of agent communications, helping security teams identify anomalous behaviors and potential security threats.

Audit and compliance support: Through enhanced log fields and FortiView visualization features, enterprises can meet AI application audit and compliance requirements, establishing complete AI traffic audit trails.

1.3 Article Structure

This article provides deep technical analysis of FortiOS 8.0's MCP/A2A protocol support from four dimensions: protocol principles, detection mechanisms, configuration details, and business scenarios. We will first analyze the technical architecture and communication mechanisms of MCP and A2A protocols, then delve into FortiGate's detection principles and signature system, followed by detailed configuration guides, and finally demonstrate the application's value through real business scenarios.

II. Deep Analysis of Protocol Principles

2.1 Model Context Protocol (MCP) Technical Architecture

2.1.1 MCP Protocol Positioning and Design Goals

Model Context Protocol is an open standard protocol led by Anthropic, designed to provide unified specifications for connections between AI models and external tools and data sources. MCP's design philosophy can be summarized as "the USB standard for AI applications"—just as USB interfaces unified connections for various peripherals, MCP attempts to establish unified communication specifications for AI model interactions with various tool resources.

Core design goals of the MCP protocol include:

Standardized interfaces: Defining unified interface specifications for interactions between AI applications and tools/data sources, reducing integration complexity and promoting ecosystem prosperity.

Security-first: The protocol includes a built-in authentication and authorization framework, supporting token-based authentication to ensure fine-grained control over AI access to external resources.

Extensible architecture: Adopting modular design, supporting selective implementation of different functional components based on application requirements, facilitating differentiated deployment for lightweight and complex applications.

2.1.2 Protocol Layered Architecture

The MCP protocol uses a layered architecture design, from bottom to top:

Transport Layer

MCP supports multiple transport mechanisms, with mainstream implementations including:

• STDIO Transport: Suitable for local inter-process communication, using standard input/output for data exchange when AI applications and tool services run on the same host.
• HTTP/SSE Transport: Suitable for networked deployment, where clients send requests via HTTP POST and servers push responses via Server-Sent Events (SSE), supporting real-time bidirectional communication.

In FortiOS 8.0 detection scenarios, HTTP transport MCP traffic is primarily involved, with typical endpoint paths including `/mcp`, `/sse`, etc.

Message Layer

MCP defines message formats based on JSON-RPC 2.0 specification, with all protocol messages conforming to JSON-RPC 2.0 structure requirements. The protocol defines three message types:

Feature Layer

The MCP protocol defines two core functional components:

Server Features:

• Resources: Allows servers to expose readable data resources to clients, such as files, database records, and API responses.
• Prompts: Predefined prompt templates with dynamic parameters, facilitating reuse of complex prompt engineering.
• Tools: Executable functions exposed by servers, where AI models can execute actual operations like sending emails, querying databases, and invoking APIs.

Client Features:

• Sampling: Allows servers to request AI inference from clients, which can be used to implement security filtering, human-machine collaboration, etc.
• Roots: Defines the file system root directory scope that clients allow AI to access.

2.1.3 MCP Session Lifecycle

MCP communication follows strict state machine management, with the session lifecycle containing the following phases:

Initialization Phase

Client → Server: initialize (capabilities, protocolVersion) Server → Client: initialized (serverInfo, capabilities)

The client first sends an `initialize` request, declaring supported protocol versions and client capabilities; the server replies with an `initialized` notification, confirming the negotiated capability set. This is the necessary handshake process for MCP communication, corresponding to `Protocol.MCP` signature in FortiGate logs with a risk level marked as "elevated".

Capability Discovery Phase

The client can query the list of features supported by the server:

• `tools/list`: Get available tools list
• `resources/list`: Get available resources list
• `prompts/list`: Get available prompt templates list

Tool Invocation Phase

This is the core application scenario for MCP. A typical tool invocation flow is as follows:

Client → Server: tools/call (name, arguments) Server → Client: tools/list_changed (notification) Server → Client: tools/call (result)

The AI model constructs tool invocation requests based on task requirements, and the server executes corresponding operations and returns results. The `Protocol.MCP.Tools` signature in FortiGate logs corresponds to such operations, recording tool names (such as `echo`) and invocation parameters (such as `{"message":"message mcp 1"}`).

Prompt Retrieval Phase

Client → Server: prompts/get (name, arguments) Server → Client: prompts/get (messages)

Clients can retrieve predefined prompt templates provided by the server. The `Protocol.MCP.Prompts` signature in FortiGate logs corresponds to such operations.

2.1.4 MCP Security Model

The MCP protocol includes a built-in HTTP-based authentication framework with the following main mechanisms:

Bearer Token Authentication: Clients carry Bearer tokens in request headers, and servers verify token validity before deciding whether to authorize access.

Capability Negotiation: Servers declare their supported capability subsets during the initialization phase, and clients decide which features they can use based on server capabilities.

Parameter Validation: Tool invocation parameters must conform to predefined schemas, with servers responsible for parameter validation and type conversion.

However, it should be noted that the MCP protocol itself does not provide end-to-end encryption—it relies on the security guarantees of the underlying transport layer. This means that in HTTPS environments, MCP communication can obtain transport layer encryption protection; but in HTTP environments, MCP messages are transmitted in plaintext, posing risks of eavesdropping and tampering. FortiOS 8.0's deep inspection functionality can decrypt and analyze encrypted traffic content when SSL deep inspection is enabled.

2.2 Agent-to-Agent Protocol (A2A) Technical Architecture

2.2.1 A2A Protocol Positioning and Design Background

Agent-to-Agent Protocol (A2A) is an open protocol led by Google, officially donated to the Linux Foundation as an open-source project in early 2025. A2A's core mission is to solve interoperability problems between AI agents built by different vendors using different frameworks.

Unlike MCP, which focuses on "agent-tool" interaction, A2A focuses on "agent-agent" communication. The relationship between the two can be compared as: MCP is the agent's "hand" for interacting with the external world; A2A is the agent's "mouth" for talking with other agents.

2.2.2 A2A Protocol Core Concepts

Agent Card

A2A protocol defines `Agent Card` as metadata description for agents, hosted at `.well-known/agent-card.json` endpoint. Each Agent Card contains the following key information:

• Identification information: Agent name, version, provider
• Capability declaration: Task types supported by the agent
• Endpoint information: A2A service address of the agent
• Authentication requirements: Authentication methods required to access the agent

{  "name": "Research Agent",  "version": "1.0.0",  "capabilities": ["web_search", "document_analysis"],  "endpoint": "https://agent.example.com/a2a" }

In FortiGate logs, requests accessing `.well-known/agent-card.json` endpoint correspond to `Protocol.A2A` signature.

Task

A2A organizes workflows with "tasks" as basic units. Each task has a unique identifier and lifecycle states:

Message

Messages are carriers for passing information between agents, supporting multiple formats:

• Text Part: Plain text messages
• Data Part: Structured data
• File Part: File attachments

A2A supports both synchronous and streaming message delivery modes:

• Synchronous mode: Client sends request, waits for complete response
• Streaming mode: Real-time reception of incremental responses via Server-Sent Events

In FortiGate logs, streaming messages correspond to `Protocol.A2A.Message` signature, with endpoint path `/v1/message:stream`.

2.2.3 A2A Communication Flow

A typical A2A communication flow contains the following steps:

Step 1: Agent Discovery

Client Agent → Server Agent: GET /.well-known/agent-card.json Server Agent → Client Agent: Agent Card (JSON)

The client learns about the target agent's capabilities and access requirements by obtaining its Agent Card. This is the starting point of A2A communication, corresponding to `Protocol.A2A` signature in FortiGate logs.

Step 2: Establishing Connection

The client establishes an A2A connection based on information in the Agent Card, which may involve obtaining and exchanging authentication tokens.

Step 3: Task Submission

Client Agent → Server Agent: POST /v1/message {  "method": "tasks/send",  "params": {    "taskId": "uuid",    "message": {...}  } }

The client submits a task request to the server, containing task identifier and message content.

Step 4: Result Retrieval

// Synchronous mode Server Agent → Client Agent: tasks/send$result // Streaming mode Server Agent → Client Agent: POST /v1/message:stream (SSE) event: result data: {...chunk1...} event: result data: {...chunk2...}

The server returns results after completing the task, or pushes intermediate results in real-time through the streaming interface.

2.3 Complementary Relationship Between MCP and A2A

2.3.1 Protocol Positioning Differences

Although both MCP and A2A are AI agent-related protocols, they solve problems at different levels:

2.3.2 Collaborative Working Mode

In actual AI application architectures, MCP and A2A typically work together to form a complete agent communication system:

┌─────────────────────────────────────────────────────────┐ │                      AI Agent                           │ ├─────────────────────────────────────────────────────────┤ │                                                         │ │   ┌───────────┐         ┌───────────┐                  │ │   │   MCP     │         │   A2A     │                  │ │   │ (Tool Layer)│        │ (Collab Layer)│              │ │   └─────┬─────┘         └─────┬─────┘                  │ │         │                       │                       │ │         ▼                       ▼                       │ │   ┌───────────┐         ┌───────────┐                  │ │   │ Tools/    │         │ Collaborating│                │ │   │ Data Sources│        │ Agents     │                  │ │   └───────────┘         └───────────┘                  │ │                                                         │ └─────────────────────────────────────────────────────────┘

For example, an "intelligent research assistant" might:

• Use MCP to invoke search engine APIs to retrieve information
• Use MCP to access local document databases
• Use A2A to collaborate with other specialized agents (such as data analysis agents)
• Use A2A to request confirmation from human experts

FortiOS 8.0 supports both MCP and A2A protocol detection, enabling complete monitoring of the two core communication behaviors of agents.

III. Deep Analysis of FortiOS 8.0 Detection Mechanisms

3.1 Detection Architecture Overview

FortiOS 8.0's detection of MCP/A2A protocols is built upon the mature application control framework, implementing protocol identification through the newly added GenAI application signature database. This design brings the following advantages:

Unified management: MCP/A2A detection shares the policy framework with application control, URL filtering, and other security functions, facilitating unified management.

Performance optimization: Reuses the high-performance detection engine of application control without introducing additional processing overhead.

Feature extension: Can be linked with IPS, SSL deep inspection, and other modules to provide multi-dimensional security protection.

3.2 GenAI Application Signature System

3.2.1 Signature Classification

FortiGate defines the following application signatures for MCP and A2A protocols:

MCP-related signatures:

A2A-related signatures:

3.2.2 Signatures and GenAI Classification

The above signatures are uniformly categorized under `GenAI` (Generative AI) application classification with classification ID 36. In application control policies, all GenAI-related protocols can be matched through the following methods:

config application list    edit "GenAI"        config entries            edit 1                set category 36                set action pass            next        end    next end

3.2.3 Signature Update Mechanism

The GenAI signature database is updated through the FortiGuard security subscription service. Database version can be checked with the following command:

# diagnose autoupdate versions | grep -A 6 GenAI GenAI Application Definitions --------- Version: 33.00033 signed Contract Expiry Date: Thu Jan 3 2030 Last Updated using scheduled update on Tue Jun 24 20:59:43 2025 Last Update Attempt: Tue Jun 24 23:10:03 2025 Result: No Updates

Note that GenAI database updates require the following conditions:

• Device holds a valid FMWR (FortiGuard Web Security) contract
• At least one firewall policy has application control profile enabled
• Device can access FortiGuard update servers

3.3 Deep Inspection and Extended Logging

3.3.1 SSL Deep Inspection Dependency

Some GenAI signatures require enabling SSL deep inspection for complete detection. Method to determine if a signature requires deep inspection:

1. Access Security Profiles → Application Signatures
2. Locate the target signature (such as `DevCycle_MCP.Tools`)
3. Hover to view signature details popup
4. Check if Requirements field contains SSL Deep Inspection

┌─────────────────────────────────┐ │  DevCycle_MCP.Tools            │ ├─────────────────────────────────┤ │  Category: GenAI               │ │  Risk Rating: Low             │ │  Requirements: SSL Deep...     │ ← Requires deep inspection │                                 │ │  [View Details] [Create Rule]  │ └─────────────────────────────────┘

After enabling deep inspection, FortiGate can decrypt MCP/A2A communication content in HTTPS traffic, extracting key information such as AI method names, function names, and parameters.

3.3.2 Extended Log Fields

After enabling Extended Log, application control logs will contain rich AI protocol information. The following are MCP-related extended log fields:

A2A protocol-related extended log fields include:

3.3.3 Log Format Examples

MCP tool invocation log:

date=2026-02-27 time=10:53:36 eventtime=1772218415610539888 logid="1059028704" type="utm" subtype="app-ctrl" eventtype="signature" level="information" vd="vd1" appid=59072 srcip=10.1.100.126 dstip=172.16.200.214 srcport=60037 dstport=3333 srcintf="port2" dstintf="port1" proto=6 service="HTTP" direction="outgoing" policyid=1 sessionid=439 applist="g-default" action="pass" appcat="GenAI" app="Protocol.MCP.Tools" hostname="172.16.200.214" url="/mcp" httpmethod="POST" msg="GenAI: Protocol.MCP.Tools" usecase="Utility_Tools" aimethod="tools/call" aifunc="echo" aiargs=""message":"message mcp 1"" cloudaiagent="APP=Protocol MCP, UseCase=Utility_Tools,    Method=tools/call, Function=echo,    Arguments='"message":"message mcp 1"'" apprisk="low"

A2A message transmission log:

date=2026-02-27 time=11:09:10 eventtime=1772219349846174869 logid="1059028704" type="utm" subtype="app-ctrl" eventtype="signature" level="information" vd="vd1" appid=59162 srcip=10.1.100.126 dstip=172.16.200.195 srcport=60174 dstport=10101 srcintf="port2" dstintf="port1" proto=6 service="HTTP" direction="outgoing" policyid=1 sessionid=828 applist="g-default" action="pass" appcat="GenAI" app="Protocol.A2A.Message" hostname="172.16.200.195" url="/v1/message:stream" httpmethod="POST" msg="GenAI: Protocol.A2A.Message" usecase="Utility_Tools" aimethod="message/stream" aimessage="message a2a 2" cloudaiagent="APP=Protocol A2A, UseCase=Utility_Tools,    Method=message/stream, Message='message a2a 2'" apprisk="low"

3.4 FortiView AI Application Visualization

FortiOS 8.0 has added AI Applications and AI Use Cases views in the FortiView module, providing security analysts with intuitive AI traffic analysis capabilities.

3.4.1 FortiView AI Applications

Access path: Dashboard → FortiView → FortiView AI Applications

This view displays AI traffic statistics by application, containing the following information dimensions:

• Protocol distribution: MCP vs A2A traffic ratio
• Session count: Session counts for each protocol
• Source/Target analysis: Endpoints initiating AI communications and target servers

Drill-down analysis supports viewing detailed session lists for individual protocols, with key fields including:

3.4.2 FortiView AI Use Cases

Access path: Dashboard → FortiView → FortiView AI Use Cases

This view organizes AI traffic by use cases, with the current version supporting the `Utility_Tools` (tool category) use case classification. This design reflects the primary classification method for AI agent application scenarios, facilitating security teams' understanding and analysis of AI traffic by business scenarios.

3.5 Detection Limitations and Known Constraints

3.5.1 Proxy Mode Inline IPS Limitation

When firewall policies use Proxy Mode, MCP and A2A protocol deep detection is not supported. This is because inline IPS processing under proxy mode conflicts with GenAI signature detection.

Solution: For scenarios requiring proxy mode, disable inline IPS:

config ips settings    set proxy-inline-ips disable end

This configuration applies to all firewall policies using proxy mode and explicit proxy policies.

3.5.2 NGFW Security Policy Limitation

NGFW (Next-Generation Firewall) security policy mode does not support MCP and A2A protocol detection. Enterprises needing advanced NGFW security policy features (such as user-based policy control) will be unable to enable GenAI protocol detection simultaneously.

3.5.3 Signature Coverage

The current GenAI signature database primarily covers mainstream AI framework and tool MCP/A2A implementations. Non-standard or proprietary protocol extensions may not be accurately identified. For special AI application requirements, it is recommended to contact Fortinet support team for signature customization.

IV. Configuration Details and Best Practices

4.1 Basic Configuration Process

4.1.1 Configuration Prerequisites

Before starting configuration, ensure the following conditions are met:

1. System version: FortiGate running FortiOS 8.0.0 or higher
2. License status: Device has valid FortiGuard service subscription
3. SSL certificate: CA certificate configured for deep inspection

4.1.2 Configuration Steps Overview

┌─────────────────────────────────────────────────────────┐ │                 Configuration Flow Overview             │ ├─────────────────────────────────────────────────────────┤ │                                                         │ │  Step 1: Create Application Control Sensor             │ │         ↓                                               │ │  Step 2: Enable Extended Logging (Optional but Recommended) │ │         ↓                                               │ │  Step 3: Configure SSL Deep Inspection Profile         │ │         ↓                                               │ │  Step 4: Apply Configuration to Firewall Policy         │ │         ↓                                               │ │  Step 5: Verify Detection Effect                        │ │                                                         │ └─────────────────────────────────────────────────────────┘

4.2 GUI Configuration Guide

4.2.1 Creating GenAI Application Control Sensor

Operation path: Security Profiles → Application Control

1. Click Create New to create a new sensor
2. Configure basic parameters:
   • Name: Fill in sensor name (such as `GenAI-Monitoring`)
   • Comments: Add description
3. Find the Generative AI category in the Categories area
4. Set this category to Monitor mode
5. Click OK to save configuration

Configuration notes:

• The reason for selecting Monitor instead of Block: During initial deployment of new features, it is recommended to first observe AI traffic characteristics and confirm detection accuracy before considering blocking policies.
• Application control supports fine-grained configuration, allowing different actions for specific signatures.

4.2.2 Enabling Extended Logging

When creating or editing an application control sensor:

1. Expand the Extended Logging option
2. Set it to Enable

Extended logging is crucial for obtaining complete AI protocol information and is recommended to always be enabled.

4.2.3 Configuring SSL Deep Inspection

Operation path: Security Profiles → SSL/SSH Inspection

1. Create or edit SSL inspection profile
2. Select Deep Inspection mode
3. Ensure CA certificate is correctly imported and distributed to clients
4. Configure whitelists, exclusion lists, etc., as needed

Notes:

• Deep inspection involves SSL/TLS decryption and may introduce performance overhead
• For known trusted AI services, exclusion rules can be configured to bypass decryption
• Some AI services (such as scenarios with mandatory certificate pinning) may conflict with deep inspection

4.2.4 Applying Configuration to Firewall Policy

Operation path: Policy & Objects → Firewall Policy

1. Create or edit target firewall policy
2. In the Security Profiles area:
   • Enable UTM Status
   • Select the created Application List (such as `GenAI-Monitoring`)
   • Select SSL/SSH Inspection profile (such as `new-deep-inspection`)
3. Ensure Action is set to Accept
4. Configure other necessary parameters (source/destination interface, address, service, etc.)
5. Click OK to save

4.3 CLI Configuration Details

4.3.1 Creating GenAI Application Control Configuration

config application list    edit "GenAI-Monitoring"        set extended-log enable        config entries            edit 1                set category 36                set action pass            next        end    next end

Command description:

• `edit "GenAI-Monitoring"`: Creates application control configuration named GenAI-Monitoring
• `set extended-log enable`: Enables extended log recording
• `config entries`: Configures matching signature entries
• `set category 36`: Matches GenAI (Generative AI) category with ID 36
• `set action pass`: Action is to pass

4.3.2 Applying to Firewall Policy

config firewall policy    edit 1        set uuid 13a56522-b12b-51f0-1d35-f6ecfe4e2568        set srcintf "port2"        set dstintf "port1"        set action accept        set srcaddr "all"        set dstaddr "all"        set schedule "always"        set service "ALL"        set utm-status enable        set ssl-ssh-profile "new-deep-inspection"        set application-list "GenAI-Monitoring"        set nat enable    next end

Command description:

• `set utm-status enable`: Enables UTM security features
• `set ssl-ssh-profile "new-deep-inspection"`: Applies SSL deep inspection
• `set application-list "GenAI-Monitoring"`: Applies GenAI monitoring configuration

4.3.3 Configuring Proxy Mode Exception (If Required)

For scenarios using proxy mode:

config ips settings    set proxy-inline-ips disable end

This configuration disables inline IPS under proxy mode, allowing GenAI signatures to work normally.

4.4 Advanced Configuration Scenarios

4.4.1 Fine-Grained Signature Control

If different policies need to be set for specific MCP/A2A signatures, signature IDs can be used for configuration:

config application list    edit "GenAI-Detailed"        set extended-log enable        config entries            edit 1                set category 36                set action pass            next            edit 2                set signature "Protocol.MCP"                set action monitor                set log enable            next            edit 3                set signature "Protocol.MCP.Tools"                set action pass                set log enable            next        end    next end

4.4.2 Blocking Specific AI Services

For AI services that need to be blocked, stricter policies can be created:

config application list    edit "GenAI-Blocked"        set extended-log enable        config entries            edit 1                set category 36                set action block            next        end    next end

4.4.3 User-Based AI Access Control

Combining FortiGate's user authentication functionality, user-based AI access control can be implemented:

config firewall policy    edit 100        set srcintf "port2"        set dstintf "port1"        set action accept        set srcaddr "all"        set dstaddr "all"        set schedule "always"        set service "ALL"        set utm-status enable        set ssl-ssh-profile "deep-inspection"        set application-list "GenAI-Monitoring"        set groups "AI-Developer-Group"        set nat enable    next end

This configuration only monitors and records traffic for members of the `AI-Developer-Group`.

4.5 Verification and Troubleshooting

4.5.1 Verifying Configuration Effectiveness

1. Check application control status:

diagnose application appctrl list

1. Check signature database status:

diagnose autoupdate versions | grep GenAI

1. Trigger test traffic: Start an MCP client application in the network to access the MCP server
2. Check logs:

# GUI path Log & Report → Security Events → Application Control Logs # CLI command fnsort -l | grep -E "MCP|A2A|GenAI"

4.5.2 Common Problem Troubleshooting

Problem 1: Extended fields missing in logs

Possible causes:

• Extended logging not enabled
• SSL deep inspection not enabled
• Signature does not require deep inspection

Solution: Confirm that `extended-log` is enabled in application control configuration and that the firewall policy is associated with SSL deep inspection configuration.

Problem 2: MCP traffic not identified

Possible causes:

• GenAI signature database version too old
• MCP server uses non-standard ports or paths
• Traffic matched by another policy first

Solution: Update GenAI signature database, check MCP server configuration, confirm firewall policy order.

Problem 3: Detection fails under proxy mode

This is a known limitation. Refer to the "Detection Limitations and Known Constraints" section for configuration adjustments.

V. Deep Analysis of Business Scenarios

5.1 Enterprise AI Workload Security Monitoring

5.1.1 Scenario Description

A large technology company is deploying an AI agent-based software development platform. Development teams use various AI tools to assist with code writing, testing, and deployment. These AI tools connect to internal code repositories, CI/CD systems, and document libraries through the MCP protocol.

Security challenges:

• Need to monitor how developers use AI tools
• Need to audit which internal resources AI tools accessed
• Need to detect anomalous AI behaviors (such as large-scale data downloads)

FortiOS 8.0 solution:

Deployment Architecture: ┌──────────────┐     MCP/A2A      ┌──────────────┐ │  Developer   │ ───────────────→│  AI Agent    │ │  Endpoint    │                  │  Server      │ └──────────────┘                  └──────────────┘       ↑                                   │       │                                   │       │         FortiGate                 │       │    (MCP/A2A Detection + Logging)  │       │                                   │       └───────────────────────────────────┘

Implementation effects:

• Records all MCP tool invocations, including invoked function names and parameters
• Identifies anomalous AI behavior patterns (such as large file reads within short time periods)
• Generates AI usage audit reports meeting compliance requirements

5.1.2 Key Configuration

# Create AI monitoring policy for development network config firewall policy    edit 50        set name "DevNet-GenAI-Monitoring"        set srcintf "dev-segment"        set dstintf "ai-server-segment"        set action accept        set srcaddr "all"        set dstaddr "ai-servers"        set schedule "always"        set service "ALL"        set utm-status enable        set ssl-ssh-profile "deep-inspection"        set application-list "GenAI-Monitoring"        set nat disable    next end

5.2 Multi-Agent Collaboration Security

5.2.1 Scenario Description

A financial institution has deployed multiple specialized AI agents to collaboratively process customer requests:

• Customer Service Agent: Receives customer inquiries, initially understands requirements
• Risk Control Agent: Evaluates transaction risks
• Product Agent: Provides product information
• Compliance Agent: Ensures operations comply with regulatory requirements

These agents collaborate through the A2A protocol, exchanging customer information and decision recommendations.

Security challenges:

• Data exchanged between agents may contain sensitive customer information
• Need to ensure agent collaboration complies with regulatory requirements
• Need to track complete agent collaboration chains for auditing

FortiOS 8.0 solution:

FortiGate deployed at agent network boundary, implementing through A2A protocol detection:

1. Message content recording: Records basic information of all A2A messages
2. Collaboration topology visualization: Displays communication relationships between agents through FortiView
3. Anomalous behavior detection: Identifies anomalous agent communication patterns

5.2.2 FortiView Collaboration Topology Analysis

Through FortiView AI Use Cases view, security teams can:

• Identify which agents frequently communicate with each other
• Discover unexpected agent collaboration relationships
• Track agent collaboration chains for specific customer requests

5.3 AI Data Leakage Prevention

5.3.1 Scenario Description

A healthcare organization uses AI agents to assist doctors with diagnosis. AI agents need to access patient Electronic Health Records (EHR), but must ensure:

• Only access records of patients currently seeking treatment
• Diagnostic conclusions cannot be obtained by unauthorized personnel
• AI usage complies with HIPAA compliance requirements

Security challenges:

• AI may "inadvertently" access large amounts of sensitive data
• Need to prevent data exfiltration through AI channels
• Need to establish complete AI data access audit trails

FortiOS 8.0 solution:

Combining application control and SSL inspection, FortiGate can:

1. Enhanced visibility: Identify when AI agents access systems containing sensitive data
2. Behavior baseline: Establish AI normal behavior baseline, detect anomalous access patterns
3. Log traceability: Provide complete AI data access logs to meet compliance audit requirements

5.3.2 Deep Inspection and Data Protection Integration

┌─────────────────────────────────────────────────────────┐ │              Protection Policy Layers                    │ ├─────────────────────────────────────────────────────────┤ │                                                         │ │  L7: Application Control - MCP/A2A Protocol ID & Logging│ │  ↓                                                      │ │  L7: DLP - Sensitive Data Detection & Masking           │ │  ↓                                                      │ │  L4: SSL Inspection - Encrypted Traffic Content Analysis│ │  ↓                                                      │ │  L3: Firewall - Network Layer Access Control           │ │                                                         │ └─────────────────────────────────────────────────────────┘

5.4 Compliance and Audit Support

5.4.1 Scenario Description

A multinational enterprise needs to meet AI regulatory requirements across multiple jurisdictions:

• EU AI Act transparency requirements for high-risk AI systems
• AI data localization requirements of various countries
• Industry-specific AI usage reporting requirements

FortiOS 8.0 compliance value:

5.4.2 Log Export Configuration

# Configure Syslog server config log syslogd setting    set status enable    set server "syslog.example.com"    set port 514 end # Configure log filter, export GenAI-related logs only config log syslogd filter    set filter "subtype app-ctrl AND appcat GenAI" end

5.5 Smart Home and IoT AI Integration

5.5.1 Scenario Description

A smart home platform uses a local AI assistant to coordinate various IoT devices. The AI assistant connects to the following through MCP protocol:

• Smart lighting systems
• Thermostat systems
• Security cameras
• Voice assistants

Security challenges:

• AI traffic in home networks needs identification
• Prevent malicious AI applications from exploiting IoT device vulnerabilities
• Parental controls need to identify AI interaction content

Although this is a consumer scenario, FortiOS's enterprise security philosophy equally applies—by enabling AI protocol detection at the network edge, providing additional security safeguards for home users.

VI. Security Considerations and Best Practices

6.1 Deployment Strategy Recommendations

6.1.1 Gradual Deployment

Given that MCP/A2A protocol detection is a new feature, a gradual deployment strategy is recommended:

Phase 1: Monitoring Only

• Configure as Monitor/Pass mode
• Only record logs, do not block any traffic
• Collect baseline data, understand AI traffic characteristics within the organization

Phase 2: Alert-Driven

• Configure alerts for key signatures (such as `Protocol.MCP` elevated risk events)
• Security team reviews alerts, adjusts strategies

Phase 3: Policy Optimization

• Refine policy configuration based on observed patterns
• Consider implementing blocking for specific scenarios

6.1.2 Network Segmentation Recommendations

It is recommended to deploy AI servers in independent network segments:

┌─────────────────────────────────────────────────────────┐ │               Network Segmentation Architecture          │ ├─────────────────────────────────────────────────────────┤ │                                                         │ │  [User Network] ──┬── [FortiGate] ── [AI Server Network]│ │               │           │                            │ │               │           └── MCP/A2A Detection         │ │               │           └── Log Recording             │ │               │                                         │ │               └── Regular Internet Traffic              │ │                                                         │ └─────────────────────────────────────────────────────────┘

6.2 Privacy Protection Considerations

6.2.1 Data Minimization

When enabling deep inspection, FortiGate will decrypt and inspect AI communication content. Consider:

• Only enable deep inspection for necessary traffic
• Configure automatic masking or exclusion rules for sensitive data
• Clearly inform users about policies that AI communications may be inspected

6.2.2 Log Data Protection

AI logs may contain sensitive information and need proper protection:

• Restrict permissions for log access
• Configure log encrypted storage
• Regularly clean up expired logs

6.3 Performance Optimization

6.3.1 Deep Inspection Performance Impact

SSL deep inspection introduces some performance overhead. Recommendations:

• Only enable deep inspection on necessary policies
• Use hardware acceleration (such as FortiGate's SSL acceleration chip)
• Monitor CPU/memory usage to ensure normal business is not affected

6.3.2 Log Volume Management

After enabling extended logging, log volume may increase significantly:

• Configure log disk space alerts
• Enable automatic log archiving and cleanup
• Consider log sampling or aggregation strategies

6.4 Integration with Other Security Functions

6.4.1 Integration with IPS

┌─────────────────────────────────────────────────────────┐ │            Security Function Integration Architecture    │ ├─────────────────────────────────────────────────────────┤ │                                                         │ │  MCP/A2A Detection ──→ Threat ID ──→ IPS Signature Block│ │       │                                                    │ │       ├──→ Risk Assessment ──→ Application Control Block │ │       │                                                    │ │       └──→ Compliance Record ──→ Logs/SIEM              │ │                                                         │ └─────────────────────────────────────────────────────────┘

6.4.2 Integration with Threat Intelligence

Combining AI protocol detection with Fortinet FortiGuard threat intelligence:

• Automatically identify malicious AI servers
• Block known malicious MCP/A2A endpoints
• Receive latest AI threat intelligence updates

VII. Summary and Outlook

7.1 Functional Value Summary

The MCP/A2A agent protocol support introduced in FortiOS 8.0 marks the formal entry of enterprise network security into the AI-native security era. Core values of this functionality are:

Improved visibility: Achieved complete identification and monitoring of AI agent communication protocols at the network layer for the first time, filling the blind spots of traditional security tools.

Risk identification: Through signature matching and risk assessment, helps security teams identify anomalous AI behaviors and prevent problems before they occur.

Compliance support: Provides technical means for AI activity auditing for regulated industries, meeting increasingly strict AI regulatory requirements.

Ecosystem integration: As part of the FortiGate security architecture, can seamlessly integrate with other security functions to provide comprehensive security protection.

7.2 Technology Development Trends

Looking ahead, AI agent protocol support functionality is expected to develop in the following directions:

Expanded protocol coverage: As the AI agent ecosystem evolves, new communication protocols will continue to emerge. Fortinet is expected to continuously expand the GenAI signature database, covering more protocol variants.

Enhanced detection capabilities: Developing from current application signature detection toward deeper semantic analysis, such as identifying AI prompt injection attacks (Prompt Injection).

Automated response: Combined with SOAR (Security Orchestration, Automation and Response) capabilities, achieving automatic threat response based on AI protocol detection.

Integration with AI security: Integrating with enterprise AI governance platforms to unify network layer detection with enterprise AI usage policies.

7.3 Implementation Recommendations

For enterprises planning to deploy FortiOS 8.0 MCP/A2A detection functionality, recommendations:

1. Thorough assessment: Before deployment, assess AI agent usage within the organization and determine monitoring scope.
2. Phased implementation: Adopt gradual deployment strategy, starting from monitoring mode and gradually transitioning to policy control.
3. Team preparation: Security teams need to understand the basic principles of AI agent protocols to effectively interpret detection results.
4. Process optimization: Establish response processes and responsibility matrix for AI protocol detection events.
5. Continuous improvement: Regularly review the effectiveness of detection policies and continuously optimize based on business development and technology evolution.

7.4 Limitations Statement

This article's analysis is based on publicly available documentation for FortiOS 8.0.0. Actual functionality may vary depending on specific versions and configurations. For support status of certain advanced features (such as NGFW security policy integration), it is recommended to refer to the latest updates in Fortinet official documentation or consult technical support for confirmation.

Appendix: Quick Configuration Reference

A.1 Minimum Configuration (Monitoring Only)

# 1. Create application control configuration config application list    edit "GenAI-Monitor"        set extended-log enable        config entries            edit 1                set category 36                set action pass            next        end    next end # 2. Apply to firewall policy config firewall policy    edit 99        set srcintf "internal"        set dstintf "external"        set action accept        set utm-status enable        set ssl-ssh-profile "deep-inspection"        set application-list "GenAI-Monitor"    next end

A.2 Check GenAI Signature Database Status

diagnose autoupdate versions | grep -A 6 GenAI

A.3 View AI Protocol Logs

# View recent MCP/A2A logs fnsort -l | grep -E "Protocol\.MCP|Protocol\.A2A" # Statistics by AI method fnsort -l | grep aimethod | awk -F'aimethod=' '{print $2}' | awk '{print $1}' | sort | uniq -c

A.4 FortiView AI Application Access

GUI path: Dashboard → FortiView → FortiView AI Applications