Notifications
Clear all
Topic starter
01/08/2026 10:44 pm
TL;DR: AWS Systems Manager shared documents, automations, and packages can appear execution-ready inside another account without an explicit approval workflow, creating a trust-confusion path that attackers can exploit, according to Pentera. The security problem is not the feature itself but the assumption that anything visible in a console is already trusted and governed.
NHIMG editorial — based on content published by Pentera: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
Q: How should security teams handle externally shared SSM documents in AWS?
A: Treat them as untrusted until the publisher is validated and explicitly allowlisted.
Q: Why do shared cloud artefacts create governance risk even when access is authorised?
A: Because authorization to access a tool does not prove the content inside it is safe to execute.
Q: What breaks when cloud automation content is trusted by default?
A: The trust boundary collapses between internal operations and external publishers.
Practitioner guidance
- Inventory externally shared SSM artefacts regularly Scan for privately shared documents, automations, and packages across all enabled regions, then compare the publisher against a short trusted-account allowlist before any execution occurs.
- Require publisher allowlisting for execution-ready content Define which 12-digit AWS account IDs are allowed to publish into your environment, and treat everything else as untrusted until reviewed and approved.
- Add continuous detection for new shared objects Use a scheduled Lambda or equivalent watcher to detect newly shared SSM content and alert when unexpected publishers appear in the environment.
What's in the full article
Pentera's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step walk-through of how shared SSM documents appear and can be executed inside an AWS account.
- The lightweight scanner workflow for listing externally shared artefacts and flagging unknown publishers.
- The Lambda-based continuous detection design for spotting new shared content over time.
- Deployment guidance for allowlisting trusted publisher account IDs and integrating alerts.
👉 Read Pentera's analysis of AWS SSM shared documents and trust confusion →
AWS SSM shared documents: is your trust model holding up?
Explore further
01/08/2026 10:54 pm
Implicit publisher trust is the failure mode here, not SSM sharing itself. The problem is that execution-ready artefacts can arrive inside an account without a separate governance decision about whether the publisher should be trusted. That turns a cloud convenience feature into an identity and authorization blind spot. In NHI terms, the shared document behaves like an externally sourced machine identity candidate until it is explicitly governed. Practitioners should treat publisher trust as a lifecycle decision, not a console assumption.
A question worth separating out:
Q: How can organisations reduce the risk of shared SSM content being misused?
A: Use a combination of trusted-publisher allowlists, continuous detection, and approval logging for every external artefact that can execute. This makes the publisher identity visible, gives operations a repeatable review process, and reduces the chance that a shared document becomes an unnoticed execution path.
👉 Read our full editorial: AWS SSM shared documents create a hidden trust gap in accounts
