AWS SSM shared documents create a hidden trust gap in accounts

At a glance

What this is: AWS Systems Manager shared documents can enter an account as ready-to-run content without an acceptance step, creating a hidden trust gap in how external artefacts are governed.

Why it matters: IAM and cloud security teams need to treat shared operational content as an access-control problem, because execution-ready artefacts can become a policy bypass if they are trusted by presence alone.

Context

AWS Systems Manager is the control plane many teams use to patch instances, run commands and orchestrate maintenance across AWS estates. The governance gap appears when shared documents, automations and packages arrive in an account as if they already belong there, even though no internal owner has explicitly approved them.

This is a trust-model problem rather than a feature problem. In cloud operations, the question is not whether a document is visible, but whether the account is authorised to execute logic that originated elsewhere and whether that publisher is controlled as part of the environment's identity and access model.

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. That means an operator may run external logic under normal permissions simply because it looks native to the environment. The failure is not visibility. It is the assumption that appearance equals authorisation.

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. If the receiving account cannot verify provenance, a familiar-looking document can carry unreviewed commands into runtime. The risk is highest where operators rely on console placement instead of explicit publisher approval.

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. If the account has no allowlist or alerting for inbound shares, the environment is relying on memory and manual review rather than control.

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.

Technical breakdown

How shared SSM documents become execution-ready in another account

AWS Systems Manager documents are JSON or YAML definitions that tell SSM what to run and how to run it. Because they can drive Run Command, State Manager and Automation, they are operational artefacts rather than passive configuration. When an external AWS account shares a document, automation or package, the receiving account can see it in the console as an object ready for use, often with limited context beyond the owner account ID and name. The technical issue is that the visibility state and the trust state are not the same thing.

Practical implication: Treat any externally shared SSM artefact as untrusted until the publisher is explicitly approved and tracked.

Why cross-account sharing creates a governance blind spot

Cross-account sharing removes the normal friction that would otherwise force review before execution. There is no inbox-style acceptance gate, so the presence of content under a shared area can be mistaken for approval. That makes the control problem administrative as much as technical: if operators can run shared documents without a governed review, then naming, packaging and account ownership become the attacker's social-engineering surface. This is especially relevant in multi-account AWS estates where operators assume shared content has already been vetted upstream.

Practical implication: Build an allowlist of trusted publisher accounts and require review of every new external publisher before use.

How attacker-influenced logic can reach runtime through SSM

The abuse path is simple: a malicious or compromised external account shares a document that looks familiar, perhaps with a benign-sounding operational name. If an operator runs it, the commands or workflow steps execute within the target environment subject to IAM permissions and SSM's execution model. The important mechanism is trust confusion, not exploitation of SSM itself. The attacker is using a legitimate distribution path to get unreviewed logic into a place where operators expect managed automation. That is a governance failure around provenance and execution authority.

Practical implication: Monitor for new shared artefacts continuously and investigate any document whose publisher is outside your approved control set.

Threat narrative

Attacker objective: To get unreviewed or attacker-influenced logic executed inside a victim AWS account by exploiting trust in shared SSM artefacts.

1. Entry occurs when an external AWS account shares an SSM document, automation or package into the target environment as apparently legitimate operational content.
2. Credential or privilege abuse follows when an operator executes the shared artefact under normal AWS permissions, allowing attacker-influenced logic to run inside the account.
3. Impact is achieved when the executed document performs actions in the environment that the operator would not have approved if the artefact's true provenance had been obvious.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Shared operational artefacts create a provenance gap: the problem is not that SSM can distribute automation, but that ownership and approval can be decoupled from execution. In cloud estates, that gap is especially dangerous because the same path that supports standardisation also supports abuse. The control question becomes who may publish into the environment, not merely who can run commands. Practitioners should formalise publisher allowlists and review triggers for every external share.

Cloud security teams should treat cross-account SSM sharing as a privilege decision. The article shows that an artefact's presence in the console is not evidence of entitlement, and that assumption is what attackers can exploit. This intersects directly with IAM because the right to execute shared logic is effectively delegated access, even when no one calls it that. The practitioner conclusion is to govern shared content with the same seriousness as any other inbound privilege path.

Hidden trust gaps are now part of machine identity governance. Shared documents, automations and packages are not identities in the classic sense, but they act like authorised execution carriers inside the account. That means the environment needs inventory, owner attribution and lifecycle control for externally sourced operational objects. The practitioner conclusion is to extend identity-style governance to shared cloud artefacts before they become invisible execution paths.

What this signals

Shared operational content needs provenance controls, not just visibility. The deeper lesson is that cloud consoles can make external artefacts look native long before anyone checks who published them. For practitioners, that means shared documents should sit inside the same governance boundary as other inbound access paths, with allowlisting and review tied to account identity, not console presence.

Provenance blindness is the named risk here. When the environment cannot tell the difference between approved automation and merely shared automation, operators will eventually normalise the wrong thing. That is why inventory, publisher attribution and continuous alerting matter: they move control to the point where execution becomes possible, not after a click has already occurred.

For practitioners

• 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.
• Monitor for new shared content continuously Run scheduled checks across enabled regions and alert when previously unseen shared artefacts appear or when an unknown owner publishes into the account.

Key takeaways

• AWS Systems Manager shared documents can create a hidden trust gap when external artefacts arrive execution-ready inside an account.
• The central weakness is not the sharing feature itself but the absence of an approval model that separates visibility from authorisation.
• Teams should inventory shared artefacts, restrict trusted publishers and alert on new inbound shares before they are executed.

Key terms

• SSM Document: An SSM Document is a JSON or YAML definition that tells AWS Systems Manager what action to perform and how to perform it. Because it can drive commands, automation, and maintenance workflows, it should be treated as executable operational content rather than passive configuration.
• Cross-Account Access: Cross-account access is a trust relationship that allows a principal in one account to reach resources in another account. It is often necessary for operations, but without tight scope and review it becomes one of the most common paths for unintended NHI exposure.
• Trust Confusion: Trust confusion happens when an operator treats something as approved because it is visible, familiar or present inside a console. In cloud operations, that mistake can turn shared artefacts into execution paths unless provenance, ownership and authorisation are checked separately.
• Publisher Allowlisting: Publisher allowlisting is the practice of restricting execution to known, approved account IDs or content sources. It reduces trust confusion by making the source of shared artefacts part of the control decision instead of assuming anything visible in a console is safe to run.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps identity and security practitioners build stronger control models for governed access, delegation and lifecycle management.