Skip to main content
bettyzhang
Staff
Staff
July 15, 2026
Question

FortiCNAPP: Detecting Cloud Threats with Graph Neural Networks

  • July 15, 2026
  • 0 replies
  • 138 views

Modern Cloud Threats Need More Context

Modern cloud environments generate a constant stream of activity: users sign in, services call other services, automation creates and updates resources, and workloads shift across accounts and regions. Hidden inside that routine activity are the early signs of credential compromise, privilege escalation, reconnaissance, and resource manipulation.

 

Traditional detectors often evaluate events one at a time. That can work well for known bad indicators, but it struggles when the risk comes from a sequence of ordinary-looking actions. For example, a console login, a few ListRoles or DescribeInstances calls, a CreateAccessKey event, and a later policy or security group change may each look explainable in isolation. A single API call is usually not enough to tell the story and can get lost in the noise. When combined together, however, these events form a suspicious activity pattern. The relationship between the identity, the resource, the action, the source IP address, and recent history is what makes the behavior suspicious.

 

FortiCNAPP already uses ML-driven anomaly detections to help identify behavior that deviates from a customer-specific cloud baseline, as discussed in our FortiCNAPP: Securing the Cloud via Anomaly Detection post. Polygraph v2 builds on that foundation with resource-aware graph neural network based alerts that add abundant relationship context for cloud investigations.

 

Polygraph v1 established the foundation for graph-based cloud activity detection by maintaining a stateful, fixed-schema activity graph over entities such as account, source, call type, user identity, region, service, API, resource, and error code. It compared new activity against that graph state and generated new-node or new-edge events when previously unseen entity relationships appeared. That approach was effective for surfacing deviations from known activity structure, but it was less focused on learning specific resource-change behavior per identify: how a specific identity’s current resource, API, and source-IP neighborhood differ from its historical behavior.

 

Polygraph v2 is a new set of FortiCNAPP graph-based anomaly alerts integrated with Composite Alerts. While still Anomaly based, Polygraph v2’s expansion into threat activity propagation is well represented by the Intrusion Graph and Observation Timeline. It extends FortiCNAPP's broader anomaly detection approach with a resource-centric graph neural network that helps security teams detect unusual cloud behavior with richer context and clearer explanations.

 

Figure 1. Polygraph v2 models cloud activity as a graph of identities, actions, resources, and context.

 

Why a Graph Neural Network Fits Cloud Security

A graph is a natural way to describe cloud activity. In FortiCNAPP, identities such as IAM users, assumed roles, root accounts, and AWS accounts can be represented alongside the resources and services they touch. Connections between them capture important context, including API action, target resource, source IP address, account, location, user agent, and frequency.

 

A graph neural network, or GNN, learns from those relationships. Instead of only asking whether an action such as CreateAccessKey occurred, the model can evaluate who performed it, what resource was involved, whether the source IP address is new, and whether the surrounding activity looks different from the identity's normal graph neighborhood.

 

In plain language, the model learns what normal cloud behavior looks like as a connected map. When today's map changes in a meaningful way, Polygraph v2 can highlight the identity, resource, and action that made the activity stand out.

 

Before getting into the model architecture, it is useful to call out what this gives defenders. Neural networks are strong at learning similarity: they can recognize that two behaviors are related even when the exact words, identifiers, or sequences vary. In language, that helps models handle different phrasings with similar meanings. In cloud security graphs, the same idea helps Polygraph v2 recognize related user activity patterns even when the API names, resources, source IPs, or timing are not identical. GAT adds another layer of value by learning which relationships in that activity graph deserve more attention.

 

A GAT-Based Architecture with Scalable Graph Inference

Polygraph v2 uses a GAT- based graph neural network architecture designed for cloud activity graphs. The model uses GATConv layers, which apply an attention mechanism to learn that some relationships are more important than others. For example, a rare credential creation or role assumption may deserve more weight than a routine read-only action that appears constantly across the environment.

 

For inference at cloud scale, Polygraph v2 uses sampled graph neighborhoods. This helps generate embeddings in batches without requiring the entire dense graph neighborhood to be processed at once, which keeps inference practical for high-volume cloud environments.

 

Together, this design gives Polygraph v2 two useful properties: attention to identify relationships that matter most, and sampled inference to handle high-density cloud graphs more efficiently. The resulting embeddings can then be compared with the historical baseline to identify behavior shifts and rare new access patterns.

 

 Before jumping into implementation details. Add signposting on what GAT will give us. (also in this signposting, also add something about NNs having good similarity methodology to handle deviations in variation in language, and for GNNs particularly, also handling variation and similarity of user activity.

 

Figure 2. From cloud activity graph to anomaly signal

 

What Polygraph v2 Learns

Polygraph v2 learns from a customer-specific historical baseline of cloud activity (up to a month). The window is adaptive: lower-volume environments can use a longer baseline to make sure we have enough data, while very high-volume environments may use a shorter window. That historical view helps the model understand recurring administration patterns, normal automation, common resource access, and the usual relationship between identities and services.

 

The model uses both identity and resource context. Examples include the type of identity, the type of cloud service, the action performed, source IP context, event counts, and the diversity of locations, user agents, recipient accounts, and accessed resources. These signals are combined into graph embeddings, which are compact representations of behavior that can be compared over time.

 

This matters because new is not always suspicious. Cloud environments change constantly. Polygraph v2 weighs novelty in context so routine infrastructure changes are less likely to dominate the alert stream, while rare new connections to sensitive resources or unusual services receive more attention.

 

Figure 3. Polygraph v2 moves from baseline learning to behavior comparison, rarity weighting, explainability, and Composite Alert correlation.

 

From Anomaly Score to Analyst-Ready Context

An anomaly detector is only useful if the output helps an analyst make a decision. Polygraph v2 is designed to explain not just that behavior changed, but what changed. Alert context can include the user or role, whether the identity is new or previously observed, the target resource or service, the API action, source IP details, rarity indicators, and the reason the activity was considered interesting.

 

This turns raw model output into a more practical investigation trail. GNNs take as input a mass of activity, convert it into graphs, and output a 0 or 1 decision. This says that the mass of activity is flagged, but does not say why. Instead of a generic alert that only says this user is flagged, an analyst can specifically see that a role accessed a new service from a previously unseen source IP address, created a credential, enumerated permissions, or modified a security-sensitive configuration.

 

Create, Discovery, and Manipulation

To make the output easier to investigate, Polygraph v2 organizes suspicious activity into categories that map to how defenders think about cloud attacks.

  • Create actions include resource creation, credential generation, or new infrastructure enablement, such as creating access keys, roles, key pairs, security groups, or functions. These actions can indicate persistence, staging, or privilege of expansion.
  • Discovery actions include reconnaissance and enumeration, such as listing roles, describing instances, reading bucket permissions, or querying account attributes. These are often early signs that an actor is learning about the environment.
  • Manipulation actions include policy changes, configuration updates, or direct modifications to resources, such as attaching role policies, changing security group ingress rules, or updating function code. These actions can show that an actor has moved from exploration to changing the environment.

 

Detection Coverage Observed in Polygraph v2 Output

In observing detection coverage made by Polygraph v2, the model surfaces behavior that looks much closer to intrusion or pen test activities such as credential creation, reconnaissance, role and policy changes, remote-access preparation, and security-sensitive infrastructure changes clustered around the same identity or source context.

 

One useful pattern is credential and privilege activity from a new source IP address. The model surfaces access-key creation, role creation, inline role policy changes, and follow-on discovery such as DescribeInstances, DescribeVolumes, ListRolePolicies, and ListAttachedRolePolicies. In one observed case, the same identity created multiple access keys, deleted an existing key, attempted or performed policy attachment, queried bucket settings, and touched secrets-related APIs.

 

Figure 4. Intrusion graph connecting a cloud identity to IP context and API activity.

 

Another surfaced pattern is infrastructure staging and remote access. The model can identity  EC2 Instance Connect activity such as SendSSHPublicKey and SendSerialConsoleSSHPublicKey, CreateKeyPair, RunInstances, PutBucketEncryption, and AuthorizeSecurityGroupIngress. Seen together, these actions can resemble a hands-on operator preparing access, opening or changing network paths, and validating reachable infrastructure.

 

Polygraph v2 also surfaces reconnaissance with failed or denied access in the right context. Observed actions include DescribeAccountAttributes, DescribeInstances, DescribeKeyPairs, DescribeLoadBalancers, GetBucketOwnershipControls, GetBucketVersioning, and GetSecretValue with AccessDenied, UnauthorizedOperation, ResourceNotFound, or failed console login context. Failed discovery is still useful: it can show that an identity is probing what it can reach before attempting creation or manipulation.

 

Just as important, Polygraph v2 is not meant to treat every unusual event as equally suspicious. Some reviewed outputs show common discovery actions, such as ConsoleLogin or ListBuckets from a new source IP address, where the output notes that the action appears common. Those events may still be worth retaining as context, but they should not carry the same weight as rare credential creation, policy manipulation, or security group changes.

 

Integrated with Composite Alerts

Polygraph v2 detections are surfaced as a new set of anomaly alerts and integrated with FortiCNAPP Composite Alerts to reduce noise. By correlating graph-based anomaly signals with other indicators of compromise and cloud activity context, FortiCNAPP helps security teams focus on higher-priority alerts instead of investigating thousands of isolated events.

 

Figure 5. Relationship view with resource names and IPs

 

The goal is to give analysts better starting points: fewer isolated signals, more context, and clearer explanations of why a cloud identity or resource interaction deserves attention.

 

Why This Matters

The strength of Polygraph v2 is not simply that it uses a graph neural network. It is the combination of graph-based behavior modeling, customer-specific baselining, novelty weighting, explainable output, and Composite Alert correlation. Together, these capabilities help answer three practical security questions:

  • Did this identity behave differently than usual?
  • Did it touch resources or services that are genuinely rare for this environment?
  • Was the activity primarily creation, discovery, or manipulation?

That combination makes graph-based threat detection a practical fit for cloud-scale security operations and helps FortiCNAPP customers find suspicious behavior earlier, with context that is easier to act on.

Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.
Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!