Skip to content

Security: YuLab-SMU/Rho-core

Security

SECURITY.md

Rho Core security boundary

main contains the rebuild design and the first managed flow, a Unix-only Rust library whose behavior is specified in the managed-run contract. The former implementation and its assumptions remain on codex/legacy-core-before-rebuild. This document states requirements; only the behavior described in that contract and exercised by its regressions is implemented. Responsibilities are defined in Architecture.

The first selected deployment is a trusted, single-user local project. Core enforces the request identity, object association and access scope of its own managed calls, including direct programmatic calls. Native owners enforce changing preconditions where the operation actually occurs. Model output, tool descriptions, skills and protocol adapters cannot establish or expand authority. Already authorized work receives no additional Rho approval.

Agents may use external tools directly within their actual environment's access boundary. Such actions do not acquire Core's acceptance, deduplication or continuation guarantees. Core records and locks do not isolate a shared native resource from external actors; the owner must check its actual identity and state.

Optional protocol adapters own connection authentication, exposure, protocol compatibility and transport limits. They depend on Core's programmatic boundary. Authentication at an edge does not remove Core or native constraints. A local stdio connection's trust cannot simply transfer to a network deployment.

The actual execution environment owns its process, file, network and isolation controls. Arbitrary code may use the user's OS privileges; path containment is not a process sandbox. If Core starts or holds processes, it must enforce the limits and lifetime behavior it declares for those resources.

In the first managed flow the application, not the request, configures executors as absolute program paths; a request can only name one of them. Runs inherit the user's privileges and Core's environment. A workdir must resolve inside the project root, which is a containment check rather than isolation. Each run gets its own process group, held and signaled only by Core until it is reaped. A process that leaves that group is outside Core's hold. Bounded resources reject new work explicitly. The caller name is a namespace in a trusted single-user setting, not authentication. The library opens no network listener. The rho-core serve host listens only on a mode-0600 Unix socket in its state directory and refuses peers whose uid differs from its own; any process of that user may still use any caller name. See Host and CLI.

Remote sharing, multi-user policies and stronger isolation need concrete requirements and verification, rather than a general security framework or a model's judgment.

Engineering checks exercise rejection through the direct programmatic boundary; selected protocol edges additionally test their own authentication and limits. Core tests run on disposable resources without model or publication credentials. Build/test jobs cannot deploy or replace a user's runtime as an incidental step. Agent-generated changes follow the same scoped review and verification process as other changes; a suggested repair cannot expand execution authority or replay an uncertain native action. There is no blanket extra approval for writes or network access already authorized in the selected environment. See the engineering guide for regression and delivery boundaries.

For suspected vulnerabilities, use private vulnerability reporting. Include the affected source or artifact, platform, impact and minimal reproduction. Keep credentials, private project content and unredacted diagnostics out of public reports. Historical development artifacts should not be assumed to receive fixes. Data-handling requirements are described in PRIVACY.

There aren't any published security advisories