What happens when protected macOS folders are accessed after an SSH login?

The protected folders can become readable even when the same paths are blocked through normal local applications or Terminal access. In practice, that means a user or attacker with SSH access may retrieve files such as browser session data from locations that Mojave tries to shield. The result is a privacy bypass that undermines the intended security model.

Why SSH access can expose folders that local apps cannot

On macOS, SSH can land you in a trust path that does not always behave like a local Finder session or a normal Terminal launch. That matters because the access check is often tied to the session, process context, or who initiated the request, not just the path itself. If the remote login is sufficiently privileged, protected data can be exposed even though the same folder appears blocked locally.

The practical takeaway is that “protected” in the user interface does not guarantee “unreachable” to every execution path. SSH is not a cosmetic front end, it is a remote command channel, so any gap between local app enforcement and remote shell enforcement becomes a privacy boundary problem.

When this happens, the folder is not necessarily “unlocked” in a permanent sense. Rather, the SSH session may inherit enough authority to enumerate or read files that macOS privacy controls would normally intercept, which is why the behaviour feels inconsistent to users but is very real from a security perspective.

What the privacy bypass means for real data

The risk is not abstract. If the accessed folder holds browser profile data, cookies, session state, or other user artefacts, SSH can turn a remote login into a shortcut around the intended local protection model. That can expose data that was meant to be visible only after explicit user consent or only within approved desktop contexts.

This is especially important because the file contents themselves can be more valuable than the folder name suggests. Session data and browser state can support account access, impersonation, or lateral movement into other services, so the exposure is often a security issue as well as a privacy issue.

In practice, defenders should treat the gap as a control inconsistency between path protection and process access. A directory that is blocked in one interface but readable in another is a sign that the protection boundary is not being enforced uniformly across access methods.

How to think about SSH, folder protection, and macOS trust boundaries

The right mental model is that SSH may provide an alternate execution environment with different effective privileges, entitlements, or privacy exemptions than a local interactive session. That means the question is not only whether the folder is protected, but also which process, session type, and user context are being trusted to reach it.

For practitioners, the important distinction is between “blocked by the UI” and “blocked by the underlying access control.” The former is a usability signal; the latter is the security control. If SSH can still read the files, then the underlying control is not closing the path you care about.

That is why this behaviour should be evaluated as a trust boundary bypass rather than a simple macOS quirk. The security model has to be consistent across local and remote access paths, otherwise an attacker only needs one less visible route to reach protected content.

Risk and Threat Considerations

SSH access can become a quiet bypass for macOS privacy boundaries when the remote session can read data that the same user cannot access through standard local apps. The exposure matters because the affected files may contain session material, personal browsing artefacts, or other sensitive content that supports follow-on compromise.

Failure mechanism: A remote shell session inherits enough authority to bypass the normal application-layer protection path, so the system enforces the restriction inconsistently across access methods.

Impact: Sensitive local data can be disclosed to a remote actor, and in some cases that disclosure can enable account abuse, persistence, or broader privacy loss.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	SSH bypasses show access must be limited by session and path.
	IA-9 — Service Identification and Authentication	Remote shell and service access depend on strong authentication context.
Recommendation — Restrict remote shell access to only the data paths the session genuinely needs. Authenticate remote sessions strongly and bind them to approved access contexts.
ISO/IEC 27001:2022	A.8.3 — Information Access Restriction	Protected folders should enforce consistent restriction across local and remote access.
Recommendation — Apply information access restrictions uniformly across all access methods.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	The issue is inconsistent access control across SSH and local sessions.
Recommendation — Align access control so remote and local sessions enforce the same protection rules.
MITRE ATT&CK	T1021.004 — Remote Services: SSH	SSH is the remote access path enabling the protected-folder exposure.
Recommendation — Monitor SSH sessions for access to sensitive local file locations.

Practitioner Guidance

What to verify: Test the same protected path through local apps, local Terminal, and SSH, then confirm whether the observed access difference is intended or a policy gap. If a remote login can read data that local interactive access cannot, treat that as a boundary mismatch that needs explicit review.

Decision rule: If the folder contains browser state, tokens, or other session-bearing files, prioritise exposure analysis over convenience fixes. The key question is not whether the directory looks protected, but whether any remote access path can still reach material that helps an attacker impersonate the user or pivot further.

What good looks like: The same sensitive folder should have a consistently enforced access policy across all relevant access paths, with no surprise exceptions for remote shells. Where that consistency is not achievable, the sensitive data should be moved, minimised, or isolated so SSH access cannot reach it unintentionally.

Practitioner takeaway: A protection control is only as strong as its least-restricted access path, so inconsistent SSH behaviour should be treated as a real exposure until proven otherwise.