Greeter: How an Abandoned AI Agent Server Becomes a Door to Your Cloud Credentials

In early November 2026, researchers at Era Security described a campaign they named Greeter. It targets legacy, unpatched deployments of Flowise, a widely adopted open source platform for building AI agents, and it has two features that should interest anyone responsible for cloud security. First, it is built to leave almost nothing behind. The attack payload is delivered fresh with every request, so the stored workflow never changes, and the chat history shows only the word “hello.” Second, its goal is not the AI server itself. It is the cloud account behind it, reached by asking the host’s metadata service for temporary credentials.

In Era’s honeypots, all 4,972 recorded user messages read “hello,” sent at steady intervals of about 3.5 seconds. Behind those greetings, the server was returning complete environment profiles, process listings, host configuration and stolen credentials.

Era’s honest summary is that the number of actively vulnerable deployments is relatively small. This is not a mass-compromise story, and we are not going to inflate it into one. It matters because of what it shows about a category of infrastructure that has appeared in most engineering organizations in the last two years: self-hosted AI orchestration tools that were stood up quickly, given generous cloud permissions, and then forgotten. When the upstream project is retired, as Flowise was in August 2026, those servers become permanent exposure unless somebody owns them.

This post walks through what was reported, how the attack works, why standard monitoring misses it, what a cloud metadata service actually does (and what the well-known “IMDSv2” fix does and does not protect against), and a step-by-step guide to finding your own AI infrastructure, shrinking what it can reach, and detecting abuse at the layer where it is actually visible. You will leave with commands you can run and a prioritized plan.

Primary source: TechTarget’s report on the Era Security findings. The shell commands, policy examples and detection rules below are our own guidance, not Era’s, and should be tested in your environment before you rely on them.

---

What Happened

Here is what Era Security reported, as relayed by TechTarget.

The target. Greeter is a Chinese-language exploitation framework aimed at self-hosted Flowise instances. Flowise is an open source tool for building LLM-powered agents and chat workflows, with a visual builder and an API for invoking the flows you create. Workday acquired the project in August 2025 to power its internal AI agent builder. A year later, the platform was sunset: Workday told TechTarget that Flowise was retired on August 31, 2026, that enterprise customers were migrated off, and that the remaining users are self-hosted. The source code remains available, but no support is offered, and the GitHub repository was archived. The final community release was version 3.1.4, and the project still has roughly 25,000 forks.

The flaw. The campaign abuses CVE-2024-58351, a runtime configuration flaw in Flowise versions before 2.1.4. It lets a remote attacker supply a javascriptFunction key inside the overrideConfig request parameter. When the flow runs, the framework replaces the code of its Custom JavaScript Function nodes with the attacker’s code, on the fly, for that request only.

The stealth. Because the injection is per request, the stored chatflow definition in the database is never modified. Defenders who inspect workflow definitions will see a clean flow. Defenders who read chat history will see nothing but “hello.” Era’s lead researcher told TechTarget the malicious function “could change with each request without altering the saved chatflow, leaving an incomplete picture for defenders inspecting workflow definitions or chat history alone.”

The payload. According to Era, the code returns host reconnaissance and credential harvesting results, and probes cloud metadata services.

The goal. The long-term objective is a pivot into the host’s associated cloud account. By querying the instance metadata service, the attacker can try to extract temporary AWS IAM credentials or Google Cloud service account tokens attached to the underlying virtual machine or container. Era did not observe a successful cross-account takeover in its honeypots, and its lead researcher was careful to say that stealing an instance role’s credentials grants that role’s existing permissions, not automatic administrative access. What Era observed was behavior consistent with a documented cloud-compromise pathway, similar to the SCARLETEEL 2.0 campaign that Sysdig documented in 2023, in which attackers used compromised container workloads and metadata credentials to gain admin rights and launch unauthorized compute instances.

The exposure. Using Shodan data, TechTarget reports 4,372 unique Flowise instances visible on the public internet. Of 3,277 that reported a recognizable version, 703 had no authentication enabled, and 46 of those matched the vulnerable configuration Era recreated. That is a small fraction, and Era says so. But experts quoted in the article describe Greeter as marking an evolution in how AI infrastructure is targeted: an ephemeral, log-evading technique that turns exposed AI workloads into quiet beachheads for broader cloud account takeover. Era also notes that forks built on vulnerable versions without patching are probably vulnerable too.

The speed. Era’s founder highlighted “the speed and precision with which [the AI-powered attack framework] exploits and investigates a compromised host.”

---

Why This Is Bigger Than Flowise

If you do not run Flowise, it would be easy to file this under “not my problem.” That would miss the pattern, which has three parts.

1. AI orchestration tools are a fast-growing, weakly governed category. Flowise, Langflow, n8n, Dify, LiteLLM, MLflow, Ray and similar tools make it easy to build and deploy agents. They are often installed by a developer or data team on a cloud VM or in a cluster to “try something out,” and they tend to need credentials: model provider keys, database connections, cloud permissions. A third-party tally by Valyu counts 11 vulnerabilities in AI orchestration and LLM infrastructure that CISA has added to its Known Exploited Vulnerabilities catalog this year (see also what is the CISA KEV catalog), across Langflow, LiteLLM, n8n, Ray and MLflow (we have not independently verified the count, but the direction is consistent with what defenders are seeing).

2. Open source projects end. Projects get acquired, archived or abandoned. When that happens, nobody ships patches, but the container image you pulled last year keeps running. Flowise is a clean example: a well-known project, retired by its steward, with thousands of instances still on the internet and tens of thousands of forks.

3. These servers hold the keys to other things. An AI agent platform is, by design, a broker. It connects to model providers, vector databases, internal APIs and cloud services. Compromising it yields not just the server but everything the server was trusted to touch. That makes the blast radius, not the vulnerability, the real measure of risk. We explain the concept in what is blast radius in cloud security.

---

How Greeter Works, Step by Step

Understanding each stage tells you which control to apply where.

Stage 1: Find an exposed, unauthenticated Flowise

The actor scans for Flowise instances reachable from the internet, then looks for the ones with no authentication and a vulnerable runtime configuration. This is cheap, automatable and indiscriminate. You do not have to be a target. You only have to be reachable.

Stage 2: Inject code per request

The attacker sends a normal-looking chat request to the flow’s prediction API, with an overrideConfig object containing a javascriptFunction key. Flowise swaps in the supplied JavaScript for the function node and executes it on the server, with the privileges of the Flowise process. That is remote code execution through a legitimate feature. The flaw is that the application accepts configuration overrides from untrusted callers.

Stage 3: Hide in plain sight

The visible message is just “hello.” Meanwhile the response carries the output of the injected code. Because the payload travels in a request parameter and not in the stored flow or the chat text, the usual places a defender looks (flow definitions, conversation logs) show nothing.

Stage 4: Reconnaissance and credential harvesting

The injected code collects the environment, running processes, host configuration and any credentials accessible to the process. On an AI platform, that often includes model provider API keys, database passwords and cloud credentials stored in environment variables or configuration.

Stage 5: Cloud metadata probing

The code requests temporary credentials from the instance metadata service. If the host has a cloud role attached, those credentials can be used from anywhere until they expire, with whatever permissions the role grants. The role’s permissions, not the vulnerability, set the ceiling on what happens next.

---

Why Your Existing Monitoring Probably Misses It

Greeter is a useful case study in monitoring gaps. Consider what each common control would see.

Control	What it sees	Why it misses
Workflow or flow audit	An unchanged chatflow	The payload is delivered per request and never saved
Chat or conversation logs	A stream of identical “hello” messages	The malicious content is in a request parameter, not the message
Application-layer detection	Noise at best	Sysdig’s Crystal Morin advises defenders to ignore application-layer detections for this activity because they create more noise than signal
Vulnerability scanning	Possibly the CVE, if the version is identifiable	Only helps if the instance is in inventory and scanned
Network allowlisting	Nothing, if egress is open	The host can call the metadata service locally

Morin’s guidance, quoted by TechTarget, is that “the real malicious behavior is visible at runtime.” She recommends monitoring Linux runtime signals with eBPF-based tools such as Falco, and using automated runtime policy to kill or block shell spawns and egress to metadata IP addresses. We will turn that into concrete rules below. The broader point is that detection has to sit at the host and cloud-control-plane layers, because the application layer was designed to look normal.

---

The Metadata Service: What It Is, and What IMDSv2 Does and Does Not Do

Because this campaign’s goal is metadata credentials, it is worth explaining the mechanism carefully. Many teams “have IMDSv2 covered” without being sure what that actually buys them.

What the metadata service is. Cloud virtual machines (and containers running on them) can call a link-local address, 169.254.169.254, to retrieve information about themselves. That includes temporary credentials for the IAM role (AWS), managed identity (Azure) or service account (Google Cloud) attached to the machine. It is how applications get credentials without storing any, which is a good design. The risk is that anything that can run code on the host can ask for the same credentials.

AWS IMDSv1 versus IMDSv2. IMDSv1 answers simple HTTP GET requests. That made it exploitable through server-side request forgery (SSRF), where an attacker tricks an application into making a request to the metadata address on their behalf. This is the mechanism behind the 2019 Capital One breach. IMDSv2 requires a session token obtained with a PUT request and a custom header, which most SSRF bugs cannot produce. Requiring IMDSv2 and a hop limit of 1 also stops containers on the host from reaching the metadata service by default. AWS documents the settings in its guide to configuring the instance metadata service, and we discuss the fix in more detail in our podcast on AWS threat detection and in Top 13 AWS EC2 misconfigurations.

Azure and Google Cloud. Azure’s Instance Metadata Service requires a Metadata: true header and rejects requests carrying forwarding headers. Google’s metadata server requires a Metadata-Flavor: Google header. These are similar speed bumps against SSRF.

The honest limit. None of these protections stop an attacker who has code execution on the host. If the attacker can run JavaScript inside your Flowise process, they can add the required header, perform the PUT and read the token just as your own application would. Greeter is an RCE campaign, not an SSRF one. That means:

• IMDSv2 is still worth enforcing everywhere. It closes a large class of SSRF-based credential theft, and it makes container escape of credentials harder.
• But it is not the control that defeats this specific attack. The controls that matter against RCE are: not letting the vulnerable software run, not exposing it, giving the attached role as few permissions as possible, and detecting use of the stolen credentials.

Being precise here protects you from a common false comfort: “we enforce IMDSv2, so metadata theft is handled.” It is handled for SSRF. For code execution, the answer is blast-radius reduction.

---

The Response Guide

The steps are ordered by urgency. Steps 1 to 3 find and cut exposure. Steps 4 to 6 limit damage and detect abuse. Steps 7 and 8 are the lasting process fixes.

Step 1: Inventory every AI orchestration and agent platform

You cannot assess what you cannot find. Start with the obvious and work outward.

# Containers on a host running Flowise (and other common AI orchestration tools)
docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}' \
  | grep -Ei 'flowise|langflow|n8n|dify|litellm|mlflow|ray'

# Kubernetes: pods across all namespaces with matching images
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -Ei 'flowise|langflow|n8n|dify|litellm|mlflow|ray'

# Node-based installs
npm ls -g 2>/dev/null | grep -i flowise

Then go beyond your own hosts:

• Check your external attack surface for the default Flowise port and web UI, using your attack surface management tooling or a service like Shodan or Censys filtered on your IP ranges and domains.
• Search code and infrastructure-as-code for Flowise images and package references, since a Terraform module or Helm chart deployed it.
• Ask teams directly. Data science, product and innovation groups are where “temporary” AI experiments live. A short survey often finds what scanners miss.
• Include forks. Because the upstream is archived, many users moved to forks. A fork of a vulnerable version is still vulnerable.

Record, for each instance: owner, version, whether it is internet-reachable, whether authentication is enabled, which cloud role or identity is attached, and which credentials it holds. Our guides to cloud asset management and shadow AI cover the discovery problem in more depth.

Step 2: Decide for each instance: retire, migrate or isolate

For each instance you find, pick one path.

1. Retire it if it is an experiment nobody owns. This is the best outcome and more common than people expect.
2. Migrate it to a supported platform if the workflow has real value. Flowise is end of life, so any long-term use needs a replacement or an internal owner who accepts responsibility for maintaining the fork.
3. Isolate it as a stopgap if migration will take time. Upgrade to the last release (3.1.4) at minimum, since versions before 2.1.4 are affected by this flaw. Treat that as risk reduction only, because there will be no future fixes.

Write down an owner and a deadline for each. An “isolate for now” without a date tends to become permanent.

Step 3: Take it off the public internet and require authentication

Whatever the decision, remove the easy attack path.

• Do not expose the service publicly. Put it behind a VPN, an identity-aware proxy or a private load balancer. A reachable, unauthenticated AI server is the entry point this campaign needs.
• Turn authentication on and use a strong, unique credential or, better, your single sign-on through a proxy.
• Restrict who can call the prediction API. Many deployments embed a chatbot in a public website, which is exactly why the endpoint is exposed. Put a gateway in front that authenticates callers and validates request shape.
• As a stopgap, block the dangerous parameter at the edge. If you must keep an old instance reachable while you plan, a web application firewall rule that rejects requests whose bodies contain a javascriptFunction key can block this specific technique. For example, a ModSecurity-style rule (with JSON body processing enabled):

SecRule REQUEST_BODY "@rx (?i)\"javascriptFunction\"" \
  "id:1000101,phase:2,deny,status:403,\
   msg:'Blocked Flowise overrideConfig javascriptFunction injection'"

Test it carefully. A signature rule is a speed bump, not a fix, and attackers can vary encodings. Its job is to buy time while you retire or isolate the instance.

Step 4: Shrink what the host’s cloud identity can do

This is the highest-leverage step, because it determines the real damage if the host is compromised.

Ask the central question: if an attacker held this machine’s cloud credentials right now, what could they do? To answer it on AWS:

# What role is attached to the instance, and what can it do?
aws ec2 describe-instances --instance-ids <INSTANCE_ID> \
  --query 'Reservations[].Instances[].IamInstanceProfile.Arn'

aws iam list-attached-role-policies --role-name <ROLE_NAME>
aws iam list-role-policies --role-name <ROLE_NAME>

# Which services has the role actually used? (helps you cut unused permissions)
aws iam generate-service-last-accessed-details --arn <ROLE_ARN>

Then act:

• Remove the role entirely if the AI platform does not need cloud access. Many do not.
• Cut permissions to what is actually used. The goal is a role that cannot list buckets, create instances or read secrets it has no business touching. Wildcard actions and AdministratorAccess on an AI test server are common and are exactly what a metadata-theft pivot needs.
• Put the workload in its own account, project or subscription with no trust path to production. If the AI experiment is compromised, it should be a contained incident, not a lateral-movement route.
• Enforce IMDSv2 with a hop limit of 1 on every instance, and make it the default so new instances inherit it:

# Require IMDSv2 and a hop limit of 1 on an existing instance
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
  --http-tokens required --http-put-response-hop-limit 1 --http-endpoint enabled

# Make IMDSv2 the account default for new instances in a region
aws ec2 modify-instance-metadata-defaults --region <REGION> \
  --http-tokens required --http-put-response-hop-limit 1

• Stop it from coming back with a Service Control Policy that denies launching instances without IMDSv2:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireImdsV2",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals": { "ec2:MetadataHttpTokens": "required" }
      }
    }
  ]
}

• Keep containers away from the node’s metadata service. On Kubernetes, give pods their own identity (IAM Roles for Service Accounts or EKS Pod Identity on AWS, Workload Identity on GKE and AKS) and block pod access to the metadata address. A basic egress NetworkPolicy that excludes the metadata IP looks like this, and you should pair it with an allowlist for the destinations the pod genuinely needs:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata-egress
  namespace: ai-apps
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32

On Azure, give the workload a managed identity with only the roles it needs (and remember that a managed identity token is exactly what the metadata service hands out). On Google Cloud, run the workload as a dedicated service account with minimal roles and avoid the default Compute Engine service account, which historically carries broad access.

Step 5: Remove and rotate the credentials the host could read

An AI platform host usually holds more than a cloud role. Assume anything it could read is exposed if the instance was reachable and vulnerable:

• Model provider API keys (OpenAI, Anthropic, Google and others). Stolen AI keys are monetized directly, which we cover in our post on LLMjacking and AI developer platform breaches.
• Database and vector store credentials.
• Third-party integration tokens configured inside the tool.
• Cloud credentials in environment variables or files, plus any role sessions that were active.

Move forward by replacing stored secrets with a managed secret store or, better, short-lived credentials, and rotate the old ones. If you cannot prove the instance was clean, rotate. The cost of rotation is far lower than the cost of discovering the key was used.

Step 6: Detect abuse where it is actually visible

Because the application layer is blind here, build detections on the host and in the cloud control plane.

Host and container runtime. A Falco rule that flags a Node process contacting the metadata endpoint inside a container is a good starting point (test and tune it in a non-production environment first):

- rule: Node process contacts cloud metadata service
  desc: A Node.js process inside a container connected to 169.254.169.254
  condition: >
    evt.type = connect and evt.dir = < and fd.sip = "169.254.169.254"
    and proc.name = node and container.id != host
  output: >
    Node process reached the metadata service
    (user=%user.name container=%container.name image=%container.image.repository
     cmdline=%proc.cmdline connection=%fd.name)
  priority: WARNING
  tags: [cloud, credential_access, ai_platform]

Also alert on shells spawned by the AI platform process, outbound connections to new destinations, and unexpected package installs. Sysdig’s recommendation to kill or block shell spawns and egress to metadata addresses automatically is worth adopting for hosts that should never need them. See what is Falco runtime security and Kubernetes runtime security.

Cloud control plane, AWS. Instance role credentials are meant to be used from the instance. Credentials used from elsewhere are a strong compromise signal. Amazon GuardDuty has findings built for this: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS and ...InsideAWS. Make sure GuardDuty is enabled in all regions and its findings reach someone who will act. You can also query CloudTrail yourself (the example below uses Athena or CloudTrail Lake syntax):

-- Where is this instance role's credential being used from?
SELECT sourceipaddress, count(*) AS calls,
       min(eventtime) AS first_seen, max(eventtime) AS last_seen
FROM cloudtrail_logs
WHERE useridentity.arn LIKE '%assumed-role/<ROLE_NAME>/%'
  AND eventtime > date_format(date_add('day', -30, now()), '%Y-%m-%dT%H:%i:%sZ')
GROUP BY sourceipaddress
ORDER BY calls DESC;

Any address that is not your instance, your NAT gateway or your known automation deserves an investigation. On Azure, review managed identity sign-ins (the AADManagedIdentitySignInLogs table) for unexpected source addresses. On Google Cloud, review service account activity in Cloud Audit Logs for unusual callers.

Application layer, for the signal that is there. Even though the application layer is not the best place to detect this, make it less blind. Log full request bodies and parameters for AI platform APIs (with care for sensitive content), and alert on requests that include configuration override keys from unauthenticated callers. Repeated identical messages at fixed intervals, like Era’s 3.5-second “hello” cadence, are a behavioral tell worth a low-severity alert.

Step 7: Hunt for signs of compromise on instances that were exposed

For any instance that was reachable, unauthenticated and on a vulnerable version, assume it may have been touched and look.

• Processes and persistence. Unexpected child processes of the Node process, new cron jobs, new SSH keys or users, modified startup scripts.
• Outbound connections. Connections to unfamiliar hosts, especially right after API requests.
• Cloud activity from the instance role outside normal patterns, as in the query above. Look especially for discovery calls (list, describe, get caller identity), secrets access and attempts to create compute or modify IAM.
• Cost and quota. Unexpected compute launches or model-provider usage spikes.

If you find evidence, treat the host and its attached identity as compromised: isolate, preserve evidence, rotate everything it could reach, and review the cloud account for persistence. Our guide on how to respond to a data or security breach gives a structured playbook.

Step 8: Fix the process, so the next orphaned tool does not become the next Greeter

The technical steps clean up this incident. These process changes prevent the pattern:

• Maintain an AI platform inventory with named owners. Anything without an owner gets a retirement date.
• Track upstream health. Before adopting an open source tool, check who maintains it. After adoption, watch for archival, acquisition or end-of-life announcements, and create a ticket when one occurs. Flowise’s retirement was public; the exposure came from nobody acting on it.
• Require a security baseline for AI experiments. Authentication on, no public exposure by default, scoped credentials, no cloud role unless justified, logging enabled. Make the secure path the easy path with a template.
• Generate and watch SBOMs. Knowing which images contain which components lets you answer “are we running Flowise?” in minutes. See our guide to SBOM generation.
• Treat AI platform credentials as high-value non-human identities, with the same lifecycle discipline as any service account. See understanding non-human identities.

---

Where Cloudanix Fits

We want to be direct about the boundary. Cloudanix does not patch Flowise, and it cannot make an end-of-life project supported again. No platform can, and any vendor implying otherwise is selling you comfort. What a platform can do is tell you where this software is, show you how far a compromise would reach, remove the standing permissions that make that reach large, and notice when credentials are being misused.

Finding it. The unified asset graph and cloud asset inventory give you a single view of workloads across AWS, Azure and GCP, so “where are we running AI orchestration tools, and which are internet-exposed?” becomes a query. Software composition analysis and SBOM generation in Code Security identify vulnerable or end-of-life components in repositories and container images, including forks of retired projects.

Seeing the real risk. A vulnerability finding in isolation is a list item. A vulnerable AI server that is internet-facing, unauthenticated, and attached to a role with broad permissions is an attack path. Correlating exposure, vulnerability and identity is how you prioritize this server above a hundred lower-risk findings, which is the reasoning behind contextual severity and why isolated findings mislead you.

Closing the posture gaps. Posture checks for EC2 and similar compute flag instances without IMDSv2 enforced and roles with excessive permissions, and CIEM shows which entitlements are unused so they can be removed. That is steps 4 and 5, maintained continuously rather than as a one-time audit.

Removing standing credentials. If the host did not hold long-lived keys, a stolen role session or environment variable would be worth far less. Cloud JIT and Agentic JIT replace standing access for people, pipelines and AI agents with scoped, time-limited grants that revoke automatically.

Detecting misuse. Cloud detection and response and cloud UEBA watch cloud activity for credentials being used in ways their owners do not: unfamiliar locations, unusual API sequences, and discovery or privilege activity from an identity that has never done it.

What this does not do. It does not stop a request from reaching an exposed endpoint, it does not fix the application flaw, and it cannot see an instance that is outside your connected accounts. It reduces and reveals risk around the vulnerability. Retiring or isolating the vulnerable server is still the primary fix.

---

Quick Reference Checklist

Priority	Action	Why it matters
Today	Inventory Flowise and other AI orchestration tools, including forks and shadow deployments	You cannot protect what you have not found
Today	Remove public exposure and require authentication	Unauthenticated, reachable servers are the campaign’s entry point
Today	Rotate model keys, database credentials and cloud secrets the host could read	Assume exposed instances leaked what they held
This week	Cut the attached cloud role to least privilege, or remove it	The role sets the ceiling on what stolen metadata credentials can do
This week	Require IMDSv2 with hop limit 1; add an SCP; block pod access to metadata	Closes SSRF-based theft and limits container exposure
This week	Add runtime detections and GuardDuty or equivalent credential-misuse alerts	The application layer will not show this attack
This month	Retire or migrate end-of-life instances; set owners and deadlines	Support will not return
This month	Establish a secure baseline and upstream-health tracking for AI tools	Stops the next orphaned tool from becoming the next incident

---

Key Takeaways

1. Greeter is a targeted, relatively small campaign with a large lesson. Era found few vulnerable deployments, but the technique (per-request injection, a log full of “hello,” a pivot to cloud credentials) is reusable against other AI platforms.
2. End-of-life software is permanent exposure. Flowise was retired on August 31, 2026. Unmaintained instances stay vulnerable until someone retires, migrates or isolates them.
3. The vulnerability is not the real risk. The blast radius is. A compromised AI server with no cloud role is an incident. The same server with a broad role is a cloud breach.
4. IMDSv2 is necessary but not sufficient. It defeats SSRF-based metadata theft. It does not stop an attacker who already has code execution on the host.
5. Detect at runtime and in the cloud control plane. Flow audits and chat logs were designed to look clean. Process, network and credential-usage signals are where the activity shows.
6. Own your AI infrastructure. Inventory, owners, a security baseline and upstream-health tracking prevent the next orphaned tool from becoming an open door.

---

Want to see which of your internet-facing workloads carry vulnerable components and broad cloud roles, and what an attacker could reach from each? Book a session and we will map the paths with you.

People Also Read

• AI Agents Are Scanning GitHub for Your Secrets, and One Reached Azure Key Vault in Five Minutes
• One Prompt, Every Agent: What the AWS Bedrock AgentCore Flaw Means for Your Cloud
• Zimbra CVE-2026-73570: Why the Answer Is Exposure Management, Not Just Patching
• CISA Flags an Ivanti Connect Secure Zero-Day: Why the Fix Is Exposure and Blast Radius
• What is Blast Radius in Cloud Security?
• What is Attack Path Analysis?
• Cloudanix: Attack Path

Related Resources

• What is an Attack Path and Why Isolated Findings Mislead You
• Why Flat Per-Rule Severity Is Broken and What Contextual Severity Fixes
• Top 13 AWS EC2 Misconfigurations to Avoid
• Kubernetes Security Checklist 2026: Hardening EKS, AKS and GKE
• AWS Threat Detection and Monitoring of Uncommon Services (Podcast)
• What is Shadow AI?
• Understanding AI Security Posture Management (AISPM)
• What is Software Supply Chain Security?
• What is Falco Runtime Security?
• Cloudanix Cloud Asset Inventory
• Cloudanix Cloud JIT