What happens when an attacker gains control of a shared code runtime in a low-code automation account?

The attacker can act as the runtime for the duration of the exploit. That can expose input data, steal secrets passed into the workflow, manipulate outputs, and abuse the platform for malicious activity such as distributed denial of service. The consequence is usually account-scoped compromise, not a single workflow issue, because the shared runtime becomes the attack surface.

How shared runtime compromise changes the blast radius

A shared code runtime is more than a single workflow step. If an attacker controls it, they inherit the runtime’s authority and can observe or alter whatever the runtime can access during execution. In practice, that means the risk is not limited to one malformed action, because the compromise sits beneath every workflow that reuses the same execution context.

That distinction matters in low-code automation because the platform often centralises inputs, outputs, connectors, and stored secrets to make integration easier. When the runtime is shared, the attacker can pivot from one workflow into the broader account context, which makes compromise account-scoped and potentially persistent until the runtime, credentials, and trust relationships are reset.

One useful way to think about this is that the runtime becomes the enforcement point for the account. If it is subverted, the attacker can tamper with data in transit, change outputs without breaking workflow logic, and use any delegated access the runtime already has. NHIMG’s Ultimate Guide to NHIs is a useful reference for the broader identity and access issues that appear when automation credentials and secrets are part of the execution path.

What the attacker can actually do inside the runtime

The immediate consequence is visibility into workflow data. If the runtime processes customer records, system messages, tokens, or API payloads, the attacker can read those values as they pass through. They can also modify outputs, which is often more dangerous than simple theft because downstream systems may trust the altered result and continue the automation chain.

Secret exposure is usually the highest-value outcome. A shared runtime frequently receives credentials, session material, API keys, or tokens needed to call external services, and those values may be available long enough for capture or replay. NHIMG’s Guide to the Secret Sprawl Challenge is directly relevant here because it addresses how credentials embedded in automation and delivery paths become an attack multiplier.

The runtime can also be abused as an execution platform. An attacker who can launch jobs, loop calls, or trigger parallel actions may use the account for fraud, spam, data exfiltration, or distributed denial of service, especially when the platform allows outbound connectivity at scale. For that reason, platform abuse is not an edge case, it is a normal downstream possibility once the runtime itself is trusted and active.

Real-world compromise patterns reinforce this point. The 52 NHI breaches Report shows how attackers repeatedly turn machine-side access into broader compromise, while Dropbox Sign breach illustrates how compromise of a backend service account can expose API keys and OAuth tokens beyond the original entry point.

What practitioners should verify before treating the account as recovered

Do not stop at the workflow that first showed suspicious behaviour. The key judgement is whether the shared runtime can be reused by other automations, whether the same secrets are still valid elsewhere, and whether the platform caches tokens or outputs in ways the attacker may have already observed. If those conditions exist, the remediation scope must extend to the full account, not just the failing flow.

What to verify: confirm which workflows share the same runtime, which connectors inherit its authority, and which secrets were passed through the execution context. Then check for unexpected job launches, unusual data egress, altered outputs, and any newly created triggers or approvals that could re-establish control.

Decision rule: if the compromised runtime can call production systems, send external messages, or mint new access, treat it as a privileged account incident and rotate or revoke the associated credentials before you resume automation. CISA cyber threat advisories are a strong external reference point for tracking current attacker behaviours that abuse trusted access paths, and CIS Controls v8 supports the operational discipline of account management, logging, and access restriction.

Risk and Threat Considerations

A shared runtime concentrates trust, so compromise can scale faster than the original intrusion suggests. The main risk is not just stolen data, but delegated access abuse, because the attacker can use the runtime’s existing permissions to move laterally into connected systems, trigger repeated actions, or keep exploiting still-valid secrets after the initial event is contained.

Failure mechanism: the attacker subverts the execution context that multiple workflows depend on, then reuses its access to read inputs, alter outputs, or invoke external services until credentials are rotated and trust paths are rebuilt.

Impact: the business impact can extend across every workflow sharing that runtime, including data exposure, fraudulent automation, downstream service abuse, and loss of confidence in outputs that were generated while the runtime was compromised.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secret Sprawl and Credential Exposure	Shared runtimes often handle secrets and tokens that attackers can capture or replay.
	NHI-02 — Overprivileged Non-Human Identity	A compromised shared runtime inherits excessive access across reused workflows and connectors.
	NHI-07 — Lifecycle and Revocation	Incident recovery depends on revoking the runtime's access and reissuing trusted credentials.
Recommendation — Move runtime secrets into managed storage and rotate any credential exposed through execution. Reduce runtime privileges to the minimum needed for each workflow and connector. Revoke and reissue runtime credentials immediately after compromise is suspected.
CIS Controls v8	6 — Access Control Management	The attack succeeds by abusing trusted access paths inside the automation account.
	8 — Audit Log Management	Detecting runtime abuse requires traceable records of execution, output changes, and job launches.
	5 — Account Management	Shared automation accounts need tight lifecycle control because compromise affects the whole account.
Recommendation — Restrict access to the shared runtime to the smallest set of approved workflows. Enable and retain execution logs that can show anomalous runtime activity. Inventory, review, and disable unused automation accounts and connectors promptly.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	The incident is fundamentally about abused account authority and access control in the runtime.
	DE.CM — Continuous Monitoring	Runtime compromise must be detected through abnormal execution, data movement, or output changes.
	RC.RP — Recovery Planning	Containment requires restoring trust after the shared runtime has been abused.
Recommendation — Apply access control to bound what the shared runtime can reach and do. Monitor runtime behaviour for unexpected execution patterns and connector abuse. Plan to rotate credentials and rebuild trusted automation paths after compromise.
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	A subverted runtime is often used to execute attacker-controlled logic and automation.
Recommendation — Hunt for attacker-authored commands or scripts executed through the automation runtime.

Practitioner Guidance

What to prioritise: isolate the shared runtime first, then determine whether the automation account is acting with standing privileges that exceed the minimum required for the task. If the runtime can reach multiple systems with the same token or connector, assume the blast radius is larger than the single incident record.

What to measure: track how many workflows depend on the same runtime, how many secrets are injected at execution time, and how quickly those credentials can be revoked or rotated. A runtime that cannot be cleanly rotated is a recovery problem, not just a detection problem.

Practitioner takeaway: treat shared runtime compromise as an account-control event, not a workflow defect, because recovery depends on shrinking the runtime’s authority and invalidating whatever access it could already exercise.