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.
Editorial analysis by NHI Mgmt Group, based on content published by Pentera: “Looks Legit, Runs Malicious: The Quiet Trust Gap in AWS SSM”.
Key questions
Q: What breaks when shared SSM documents are trusted by default?
A: The trust model breaks because execution-ready content can appear in the console without a true approval step.
Q: Why do externally shared SSM artefacts create execution risk?
A: They create execution risk because the publisher and the executor are separated by a weak governance boundary.
Q: What are the signs that shared SSM content is being misgoverned?
A: The main signs are unknown publishers, newly shared artefacts that were never approved, and operators using shared documents because they look routine or vendor-like.
Practitioner guidance
- Inventory all shared SSM artefacts List every shared document, automation and package visible in AWS accounts, then map each item to a known publisher account and business owner.
- Create a trusted publisher allowlist Approve only specific 12-digit account IDs for inbound SSM sharing, and block or flag anything outside that publisher set.
- Require review before execution Put a manual approval checkpoint in front of any first-time use of externally shared SSM content, especially when the name looks familiar.
Bottom line: AWS Systems Manager shared documents can create a hidden trust gap when external artefacts arrive execution-ready inside an account.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 10:54 pm
Trust confusion has become a cloud governance issue, not just a social-engineering trick. When execution-ready content appears inside an account without an explicit acceptance step, operators are forced to infer trust from appearance. That breaks the assumption that visibility implies approval, and it pushes provenance checks into ad hoc human judgement. The practitioner conclusion is that shared operational content must be governed like any other inbound trust boundary.
A question worth separating out:
Q: How should teams govern shared SSM content across AWS accounts?
A: Teams should treat shared SSM documents, automations and packages as inbound execution rights. That means defining who may publish, maintaining an allowlist of trusted account IDs, requiring review before first use, and monitoring continuously for new or unexpected shares. The goal is to govern provenance before runtime, not after.
👉 Read our full editorial: AWS SSM shared documents create a hidden trust gap in accounts