Look for workflow definitions that trigger external HTTP calls, touch file descriptors, or reach internal services by private IP. Those patterns can indicate that code is being used for more than normal automation, especially when the workflow sits in a private area that administrators cannot easily inspect. Review any step that handles secrets or transforms sensitive inputs.
Why these workflow patterns are suspicious
A low-code code step becomes suspicious when it behaves like a covert transfer point instead of a normal business-rule function. External HTTP calls from inside the workflow, especially to unfamiliar domains, are a common exfiltration pattern because they let data leave through what looks like routine automation. The same concern applies when code reaches internal services by private IP or reads file descriptors that should not be relevant to the workflow’s stated purpose.
The strongest signal is not one odd action in isolation, but a combination of purpose mismatch and hidden reach. If a step that should validate, enrich, or route data is also handling secrets, transforming sensitive inputs, or making outbound requests, the workflow may be using legitimate execution authority to move data out quietly. That is why administrators should treat secret sprawl and credential exposure as part of the investigation, not a separate issue.
Code steps in low-code platforms can also hide intent because the surrounding visual flow may look benign while the embedded code performs the real action. In practice, the abuse often depends on the platform’s trust model: if the step can access files, network endpoints, secrets, or internal services, then it can move data outside the intended business boundary without needing an obvious exploit chain.
What to inspect when the code step sits inside a private workflow
Start by reviewing whether the code step has capabilities that exceed its declared function. A step that serialises form fields into an outbound request, joins data from multiple sources, or reads from attachments, temporary files, or environment variables deserves immediate scrutiny. In low-code environments, stealthy exfiltration often hides in ordinary-looking transformations, not in obviously malicious payloads.
Pay special attention to steps that reference secrets, tokens, API keys, or connection objects. If the code step can retrieve those values and then use them to call an external endpoint, the workflow may be converting privileged access into a data theft channel. The pattern is even more concerning when the workflow lives in a private area that is hard to inspect, because restricted visibility makes it easier for a malicious or compromised editor to bury the activity inside an otherwise normal automation path.
For broad exposure patterns, the same concern is documented in cases where exposed credentials or tokens were used to reach internal systems and exfiltrate data, such as the Sisense breach and the Schneider Electric credentials breach. Those incidents reinforce a simple rule, access that looks legitimate can still be abused to move sensitive data out.
Also look for telltale destination patterns. Repeated POSTs to unrecognised hosts, use of raw IP addresses, unexpected DNS lookups, or calls to internal endpoints that are unrelated to the workflow’s business function all suggest that the code is being used to bridge trust zones. If the step is the only part of the workflow with those permissions, it becomes the most likely place for data to leave the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Limits who can reach sensitive workflow data and services. |
| CIS 8 — Audit Log Management | Detects unusual outbound calls, file access and secret use in workflows. | |
| CIS 16 — Application Software Security | Covers insecure custom code embedded in low-code automation steps. | |
| Recommendation — Restrict workflow step permissions to the minimum access needed. Log workflow execution, secret access and outbound destinations. Review embedded code for unsafe data handling and external requests. | ||
| MITRE ATT&CK | T1041 — Exfiltration Over C2 Channel | Directly matches covert data leaving through outbound network traffic. |
| T1020 — Data Exfiltration | Applies when a workflow step is used to move data out stealthily. | |
| T1213 — Data from Information Repositories | Fits abuse of workflow access to read stored data before exfiltration. | |
| Recommendation — Hunt for covert outbound transfers that carry workflow data out. Inspect workflow steps that package and transmit sensitive data externally. Monitor for workflow code that reads repositories or stores beyond necessity. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Overprivileged and Overexposed Identities | Secret-bearing workflow steps often have more access than their task requires. |
| NHI-07 — Secrets Exposure and Leakage | Suspicious code steps frequently abuse exposed secrets to reach data. | |
| NHI-09 — Visibility and Governance Gaps | Private low-code areas can hide malicious workflow behavior from admins. | |
| Recommendation — Reduce workflow permissions and separate sensitive from routine access. Rotate and restrict any secrets a workflow step can access. Improve inventory and review of workflows that can touch sensitive data. | ||
Practitioner Guidance
What to verify: Confirm what the code step can access at runtime, including network egress, file handling, environment variables, secrets stores, and internal service reach. If the step can touch sensitive data and make outbound calls, assume it can be used for exfiltration until the traffic is explained.
What practitioners underestimate: Low-code abuse is often missed because the visual workflow appears harmless while the embedded code performs the decisive action. The key question is whether the step’s runtime authority matches its business purpose, not whether the surrounding canvas looks suspicious.
Practitioner takeaway: Treat unexplained outbound connectivity plus sensitive-data access as a boundary failure, because stealthy exfiltration in low-code platforms usually depends on ordinary automation permissions being broader than they should be.
Related resources from NHI Mgmt Group
- What are the signs that S3 access may be being misused for data exfiltration?
- Why do low-code workflow platforms increase identity governance risk around signing?
- How should IAM teams govern low-code workflow automation in identity programmes?
- Who is accountable when a low-code app exposes sensitive data through weak authentication?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
