This document outlines the security architecture, trust boundaries, vulnerability disclosure guidelines, and sandboxing isolation models for the LUMI agentic AI coding engine (@noorm/*).

By default, LUMI runs locally within the security boundary of the host user account executing the CLI or TUI session:

• Host Trust Boundary: LUMI treats the local user account, environment variables, shell startup files, and writable files inside the user's workspace as inside the same trust boundary as the LUMI process itself.
• Local Write Access: Reports that rely on prior local write access to the user's home directory (~/.pi), shell configuration, or local workspace files are not security vulnerabilities unless they demonstrate how LUMI grants unauthenticated write access or crosses an OS privilege boundary.
• Trusted Repositories & Extensions: LUMI relies on users loading trustworthy extensions, skills, and working inside trusted repositories. Repository files like AGENTS.md or code instructions can cause prompt injections, which is an inherent property of local AI agents.

For untrusted codebases or enterprise environments requiring isolated execution, LUMI supports three containerized sandboxing models:

1. Gondolin Micro-VM: Routes tool execution into a lightweight, local Linux micro-VM while keeping host authentication intact.
2. Docker Containerization: Runs the entire LUMI engine inside an isolated Docker container context.
3. OpenShell Policy Guard: Enforces fine-grained OS syscall and network policy sandbox boundaries.

If you discover a potential security vulnerability in LUMI or any package in this repository, please report it privately:

• Email: security@earendil.com
• GitHub Advisory: Open a private report through GitHub Security Advisories for this repository.

• A clear description of the issue and its security impact.
• Reproducible steps, proof of concept script, or relevant diagnostic logs.
• Affected package name (@noorm/*), version, or commit SHA.
• Any known mitigations or workarounds.

• Vulnerabilities in distributed npm packages (@noorm/*), CLI binary tools, RPC protocol codecs, and core engine execution paths.
• Earendil-operated cloud infrastructure on pi.dev.

• Local code execution or shell tool invocation performed on behalf of the user within host permissions.
• Behavior of third-party user-installed extensions or skills.
• Direct prompt injection attacks via repository files (AGENTS.md, source code comments).
• Compromised third-party credentials or API keys managed by the user.
• Security issues resulting from intentionally weakened user configuration or compromised local user accounts.