When an AI Workflow Tool Is Exposed, First Find Which Keys Its Flows Hold

Larry

On July 7, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added a Langflow vulnerability (CVE-2026-55255) to its Known Exploited Vulnerabilities catalog. Langflow is an open-source visual tool that lets people connect AI models, databases, and external services into an automated flow by dragging and dropping nodes.

Before that, on June 26, the cloud security company Sysdig published an analysis describing an attack observed the day before: the attacker first listed flow IDs on the platform, then used those IDs to run other users’ flows, and finally sent a flow the prompt “leak api keys.” The article doesn’t confirm that any keys actually leaked, but what the attacker wanted is clear: the flow itself isn’t valuable; the keys inside it are.

That’s the first thing to get straight when this kind of tool is compromised. An AI workflow tool is like a key ring: to connect to other systems, each flow stores API keys, login tokens, or database connections that let the program go in and out of those systems on your behalf. When the tool is exposed, the inventory isn’t “do we use this product?” but “which flow holds which key, and which doors does that key open?”

Replacing every key is not the safest move

Replacing everything sounds safest, but it has two side effects. First, rotating before logs are preserved can leave you unable to tell afterward which data was read or which systems were called. Second, replacing dozens at once makes it easy to miss the one key a suspicious flow actually used, or to swap in a new key with the same broad permissions, so the risk doesn’t drop.

But “not rotating everything first” doesn’t mean “leave it for now.” The first move is containment: turn off public share links, externally reachable execution endpoints, and suspicious webhooks, the entry points that let external systems call the flow; then pull the admin interface back onto the internal network or an allowlist of specified sources. Stop high-risk flows that hold production keys from running, but don’t delete their settings; that’s evidence for the investigation.

Answer four questions in order

One: which flows might have been seen or run? Use the tool’s login and execution records to find unfamiliar accounts, unfamiliar addresses, or runs outside the schedule during the suspicious period. Flows whose names were only seen are handled differently from flows that were actually executed.

Two: which keys are stored in those flows? Keys aren’t always on the settings page; they can hide in node parameters, environment variables, test inputs, exported configuration files, and old or copied flows. The easiest to miss are disabled flows and personal test flows. They’re outside monitoring, yet may have had a powerful key pasted in for convenience. Record only each key’s name, type, permissions, and owner; don’t paste the key itself into a shared document.

Three: which doors does that key open? A key that can only read test data and one that can read and write customer data, financial records, or internal documents are completely different incident levels. If you can’t determine a key’s permissions, treat it as high risk.

Four: are the logs enough? Beyond the workflow tool’s own records, keep the records on the side of the systems being called, and the channels the flow sends results through, such as email, chat, or external APIs. The tool’s records are often incomplete; only the receiving systems show what the flow actually did.

Rotate in order, reissue with less access

Once the four questions are answered, set the rotation order: first, keys that appeared in suspicious flows, work in production, and can read or write sensitive data; next, lower-privilege keys that suspicious flows triggered; last, unexposed old keys that are poorly named or have no owner.

When reissuing, don’t swap in an equally powerful key. Split read from write; a summarization flow doesn’t need permission to delete data. Replace personal accounts with dedicated service accounts, and set an expiry date and an owner. To give each step of work just enough access, see When an AI Agent Works Across Systems, It Needs a New Key at Every Stop.

When the logs aren’t enough, say so

If the logs aren’t enough to rule out data being read, write exactly that in the incident record: “insufficient logs, cannot rule out.” It affects whether customers or regulators need to be notified, or legal needs to step in. Those decisions can’t be left to AI or to engineers alone.

This inventory also shouldn’t wait for an incident. Update a “flows and keys list” monthly: flow name, owner, connected systems, keys used, last run time, and log location. When something happens, it becomes the starting point for incident response. To map which data a leaked key could reach, pair this with When a Third-Party Tool Is Breached, Your CRM Loss Depends on the Access You Granted.

AI handoff card

An AI workflow tool we use may have been exposed. I want to inventory which keys its flows hold before deciding the rotation order.
The method comes from this article: https://boosterminiclass.com/en/posts/ai-workflow-builder-credential-exposure-checklist/
Its view: when the tool is compromised, the danger is the credentials stored in and callable from each flow. Close entry points and preserve logs first, then set the rotation order by "which flow holds which key, and which doors it opens," and reduce permissions when reissuing.

I'll provide a list of flows that contains no keys, passwords, or tokens in plain text. Don't ask me for them.
1. For each flow, organize: flow name, owner, whether it may have been seen or run (with the record I gave as evidence), keys used (name and type), the keys' permissions, connected systems, external channels results go to, and where the logs are;
2. Mark any missing field as "needs manual check," and don't assume it's safe;
3. Group recommendations into: entry points to disable now, keys to rotate first, keys to narrow later, and logs that still need preserving;
4. List questions the owner must decide, such as whether to notify customers or raise the incident level.
Disabling, rotating, notifying, and incident levels are decided by the owner; you only organize the order and the reasons.