Shared execution means one user’s code can influence the same runtime used by other users in the account. That creates a privilege boundary problem, because a low-privilege actor may inspect inputs, alter outputs, or reach secrets that were never meant for them. In practice, the platform may still be secure, but the workflow design can create account-wide exposure.
Why shared execution changes the security model
Low-code automation platforms often optimise for reuse, speed, and convenience, but shared execution means those benefits are coupled to a shared trust boundary. If multiple workflows, users, or connectors run in the same account context, the platform must prevent one workflow from seeing or influencing another workflow’s state, inputs, outputs, and attached credentials. The risk is not the visual builder itself, but the fact that execution can become account-scoped even when intent is user-scoped.
That is why the question is really about boundary design. In a shared runtime, a low-privilege user may not need direct admin access to cause damage, because they can still interact with objects that the platform treats as common to the account. When execution context, storage, and connector permissions are shared, the control plane has to enforce separation very precisely or privilege can be inferred through workflow behaviour rather than explicit role assignment.
Shared execution also tends to hide where trust is actually anchored. A workflow may appear to belong to one user, yet it may inherit broader account-level permissions, cached tokens, or shared variable stores underneath. That creates a mismatch between the user interface and the effective authority of the code, which is exactly the kind of design gap that turns convenience into an exposure path.
Where the intra-account escalation path appears
The escalation path usually emerges when one workflow can read or influence a runtime object that another workflow assumes is private. Common examples include shared inputs, environment variables, connector responses, temporary files, logs, queues, and stored secrets. If the platform does not isolate those objects per workflow or per principal, a low-privilege actor can move from “can run a flow” to “can inspect or reuse data that should have been invisible.”
This is especially dangerous when the automation platform lets users chain actions through the same account-wide connectors. Even without direct access to a secret, a malicious or careless workflow can trigger operations that expose token material, privileged output, or downstream side effects. For that reason, the privilege problem is often less about a classic role change and more about unintended reuse of a higher-trust execution context.
A useful way to think about it is blast radius. Shared execution can make the entire account behave like a single protection domain, so the security question becomes whether every workflow is constrained to the least amount of data and authority needed to run. If the answer is no, one user’s automation can become a stepping stone into another user’s credentials, data, or action space.
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 NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Shared execution can expose reusable secrets and tokens across workflows. |
| NHI-04 — Privilege and Access Management | The issue is account-wide overreach from shared runtime authority. | |
| NHI-06 — Visibility and Inventory | Shared execution hides which workflows can access shared runtime objects. | |
| Recommendation — Isolate and rotate secrets so one workflow cannot reuse another workflow's credentials. Apply least privilege to each automation path and remove unnecessary account-wide access. Inventory shared connectors, variables, and execution scopes to expose hidden cross-workflow access. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The question concerns enforcing boundaries between users and workflows in a shared runtime. |
| PR.DS — Data Security | Shared execution can expose inputs, outputs, logs, and secret-bearing data. | |
| Recommendation — Enforce access boundaries so workflows cannot reach data or actions outside their assigned scope. Protect workflow data at rest and in transit, including temporary and shared execution artifacts. | ||
| CIS Controls v8 | 6 — Access Control Management | Shared execution increases the need to control which users and workflows can access shared resources. |
| 3 — Data Protection | Shared runtime state can reveal sensitive inputs, outputs, and secrets across workflows. | |
| Recommendation — Restrict access paths so low-privilege users cannot inherit broader account authority. Protect sensitive workflow data from cross-context exposure and unintended reuse. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | A low-privilege workflow can leverage shared runtime weaknesses to gain more authority. |
| T1552 — Unsecured Credentials | Shared execution can expose secrets or tokens to other workflows in the same account. | |
| Recommendation — Look for abuse of shared execution paths that elevate a user's effective privileges. Monitor for credential material exposed through shared variables, logs, or connector state. | ||
Practitioner Guidance
What to verify: Confirm whether execution isolation is per user, per workflow, or only per account. If the platform shares connector state, variable stores, logs, or cached tokens across workflows, treat that as a privilege boundary issue rather than a simple configuration detail.
What to prioritise: Focus first on the objects that can leak authority, especially secrets, token-bearing connectors, and reusable service integrations. Those are the places where a seemingly harmless read path becomes an account-wide escalation path.
What good looks like: A workflow should only be able to see the secrets, outputs, and side effects it strictly needs, and there should be a clear audit trail showing which principal initiated which action. If you cannot explain that boundary cleanly, the platform is relying on trust that is too broad for shared execution.
Practitioner takeaway: Shared execution is risky because it turns the runtime itself into the boundary, so the design must prove separation of authority and data at runtime, not just rely on user roles in the UI.
Related resources from NHI Mgmt Group
- Why do cross-account roles increase privilege escalation risk in AWS?
- Why do shared ML artifacts increase code execution risk?
- Why does placing a hub role in a lower-security account increase AWS privilege escalation risk?
- Why does a Linux kernel flaw in packet handling become a host root and container escape risk after low-privilege code execution?
