Because an attacker does not need raw network egress if the runtime can exchange data through an approved service. Object reads, writes, and polling can simulate a remote shell when access is broad enough, especially if the interpreter can use presigned URLs or cross-account buckets.
How allowed cloud services become a covert command channel
An approved cloud service can carry attacker instructions because it already fits the runtime’s trust model. If the application is allowed to read from, write to, or poll that service, the attacker can encode commands in ordinary objects, messages, or responses instead of opening a direct network session. The security issue is not the protocol itself, but the breadth of the permitted access path.
The pattern becomes more dangerous when the runtime can both fetch instructions and send results back through the same sanctioned channel. That turns a business integration into a bidirectional control loop, which is enough to approximate remote execution even when traditional egress is blocked or heavily filtered.
Why object access can resemble a remote shell
In practice, the attacker only needs a place the runtime is already allowed to touch. A poller that checks a bucket or queue, processes the contents, and posts output can be repurposed into an interactive loop: read a task, act on it, write back the result, repeat. The runtime does not need raw internet access if the cloud service is already a permitted destination and source.
Presigned URLs and cross-account buckets increase that risk because they can widen access beyond the original trust boundary. When the interpreter can fetch arbitrary objects or write into shared storage, the approved service stops being a passive data exchange and becomes an execution relay that is hard to distinguish from normal application traffic.
Where the real control failure sits
The failure is usually overbroad service permissioning combined with weak separation between “data the app should process” and “instructions the app should execute.” Once the runtime is trusted to consume content from the service, the attacker can abuse object names, message bodies, polling cadence, and response payloads as covert control primitives. That is why this pattern often persists even in environments that claim to block direct command-and-control traffic.
For readers who want a control baseline for the runtime and its allowed services, NIST SP 800-190 on container security is a useful reference for thinking about image, registry, orchestrator, and runtime risk, while the OWASP Non-Human Identity Top 10 is a useful lens when cloud permissions are effectively acting as machine access. OWASP’s API Security Top 10 also helps when the approved service is being used as a programmable control surface rather than a simple data store.
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, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits runtime access to approved cloud services and object scope. |
| IA-9 — Service Identification and Authentication | Covers service-to-service trust when runtimes use cloud services as execution paths. | |
| SC-7 — Boundary Protection | Applies because the approved service can become the effective boundary for command flow. | |
| Recommendation — Restrict runtime permissions to the minimum service actions and resource scope needed. Require strong service authentication for every runtime-to-cloud interaction. Constrain and monitor allowed egress paths as trust boundaries. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Broad cloud permissions can let a runtime act on attacker-supplied commands. |
| NHI-07 — Long-Lived Secrets | Presigned URLs and durable access often extend the lifetime of misuse. | |
| Recommendation — Reduce non-human access scope to prevent approved services becoming control channels. Shorten credential and URL lifetimes that enable repeated abuse. | ||
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | Attackers can move instructions and payloads through sanctioned cloud services. |
| T1071 — Application Layer Protocol | Approved services can be abused as application-layer command channels. | |
| Recommendation — Detect staged payload exchange through approved cloud objects and messages. Hunt for command traffic hidden inside legitimate application protocols. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Cross-account buckets and broad object access can expose unintended control surfaces. |
| Recommendation — Enforce object-level authorization on every cloud service interaction. | ||
Practitioner Guidance
What to verify: Determine whether the runtime can both retrieve and emit data through the same approved cloud path. If it can, treat that path as a potential control channel, not just a storage or messaging dependency.
Decision rule: If the service can influence execution order, parameter values, or tool invocation, reduce the permission scope before you investigate whether it has already been abused. The relevant question is blast radius, not just whether the service is officially approved.
Common mistake: Teams often secure network egress and assume the problem is solved. In these cases, the meaningful boundary is the cloud service permission, the object scope, and the polling logic, not the firewall rule.
What good looks like: The runtime should only consume narrowly scoped inputs, should not interpret untrusted object contents as instructions, and should have distinct paths for input retrieval and output publication where possible.
Practitioner takeaway: If an approved service can carry commands as easily as data, it is part of the attack surface, and its access scope should be governed as tightly as any other execution-capable interface.
Related resources from NHI Mgmt Group
- Why do public API keys create more risk once AI services are enabled on the same cloud project?
- Why does network-based access control create risk for modern cloud and AI-driven environments?
- Why do AI companies often end up using multiple cloud providers, and what risk does that create for identity and access control?
- Why do backdoors that pull command-and-control data from public cloud files create higher operational risk?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org