What breaks when a self-hosted AI assistant runs with user-level filesystem access?

Why This Matters for Security Teams

A self-hosted AI assistant with user-level filesystem access is not just “a chat tool with a shell.” It can inherit the user’s local trust boundary and read far more than prompts or documents, including session caches, configuration files, synced credentials, and API tokens. That turns a convenience feature into an identity boundary failure, because the assistant’s runtime scope now overlaps with secrets and services it was never intended to touch.

This matters because the breach path is often indirect. An attacker does not need to break the model first if they can induce it to inspect local files, reuse cached tokens, or chain actions into connected tools. The risk is well illustrated in NHIMG research on LLMjacking: How Attackers Hijack AI Using Compromised NHIs and the broader NHI attack patterns in Ultimate Guide to NHIs. OWASP’s Non-Human Identity Top 10 also reinforces that over-privileged non-human workloads are a recurring control failure, not an edge case.

In practice, many security teams encounter the compromise only after the assistant has already accessed local tokens or pivoted into a connected SaaS account.

How It Works in Practice

Once an assistant runs under a normal user account, it can operate with the same filesystem visibility that the user has. That means the assistant may read shell history, browser profiles, local caches, agent config files, cloud CLI state, SSH material, and application secrets stored on disk. If the assistant can invoke tools, those files can become stepping stones from passive access into active compromise.

The operational fix is not “add a stronger prompt.” It is to narrow the identity and runtime boundary. Current guidance suggests treating the assistant as a distinct workload identity, not an extension of the human user. That means separating local execution context, constraining filesystem mounts, and issuing short-lived credentials only when the assistant needs them. The control model should favor just-in-time access over static presence, and runtime policy evaluation over pre-approved assumptions.

• Run the assistant under a dedicated account with the minimum filesystem scope needed for the task.
• Store secrets outside the assistant’s readable paths and prefer ephemeral token exchange over long-lived local keys.
• Use workload identity and short-lived tokens where possible, rather than reusing the user’s session state.
• Enforce request-time authorization for tool calls and file access, especially when the assistant can chain actions.

NIST SP 800-53 Rev. 5 emphasizes least privilege and access control discipline, and NHIMG’s 52 NHI Breaches Analysis shows how frequently identity scope creep becomes the real failure point. These controls tend to break down in developer laptops and shared automation hosts because local convenience often overrides filesystem separation and secret hygiene.

Common Variations and Edge Cases

Tighter filesystem isolation often increases setup friction, so organisations have to balance usability against blast-radius reduction. That tradeoff is especially visible in local development environments, where assistants need limited project access but must not inherit browser or shell state. Best practice is evolving here, and there is no universal standard for every workstation pattern yet.

The risk is different across environments. On a personal laptop, the assistant may see tokens cached by CLI tools or browser logins. On a shared build server, it may read service credentials, deployment configs, or artifact signing material. In either case, the dangerous pattern is the same: a user-level assistant inherits more trust than its task requires. This is why NIST’s security control model and the Ultimate Guide to NHIs both point toward scoping identity to the workload, not the operator.

For teams using autonomous or tool-using assistants, the safest assumption is that local files are part of the attack surface. Once the assistant can read a credential, it can often reuse that credential faster than a human can detect the misuse. The practical answer is to keep secrets out of user-writable paths, separate assistant storage from human storage, and revoke anything the assistant can touch as soon as the task ends.

Related resources from NHI Mgmt Group

• When is it crucial to implement least-privilege access for AI agents?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?