Runne

English

Русский

English

Русский

Appearance

Security ​

Runne Engine is designed around default deny for protected side effects, least privilege with capability attenuation, and fail-closed enforcement. This page summarizes the model; the full contract lives in the runtime repository under docs/05-security/.

Capability grants and approvals ​

  • A Capability is a named ability (fs:read, fs:write, process:exec, network:outbound, …). A Capability Grant is an immutable, versioned grant with an exact action, normalized resource, constraints, scope, expiration, and delegation limit.
  • An operation is allowed only when an active grant fully covers the subject, action, resource, scope, and the current policy/revocation epoch. Unknown action/resource/constraint/version → deny.
  • A child (delegated TaskRun, plugin, MCP server, adapter) may hold only attenuated grants — never wider than its issuer.
  • An Approval is a human decision, not a grant. After approval the capability engine re-evaluates current policy, and the result can still be deny. Approval-derived grants are operation-specific and short-lived.

Sandbox and process containment ​

  • The sandbox helper (runne-sandbox-helper) and the platform sandbox backends constrain the agent's filesystem, process, and network capabilities.
  • Sandbox profiles range from read-only and workspace-coding up to plugin-host and mcp-local. trusted-admin remains short-lived, requires strong authentication and a reason, and carries mandatory audit.
  • Plugins and MCP servers run in separate processes (ADR-0007); every request passes through the capability engine with a fresh invocation binding and a single-use permit.
  • If the sandbox, policy, or audit layer is unavailable or unknown, enforcement fails closed — the operation is denied.

Credential service and macOS Keychain ​

  • runne-credential-service and runne-credential-service-core handle provider credentials (openai, deepseek). The CLI sets a credential only from non-TTY stdin — never argv, environment, or file paths.
  • On macOS the credential service stores items in the Data Protection Keychain behind an ACL — runne-macos-keychain-acl enforces the access-group contract (758F9Z45SR.com.runne.credential-service) with kSecUseDataProtectionKeychain=true, kSecAttrAccessibleWhenUnlockedThisDeviceOnly=true, and kSecAttrSynchronizable=false.
  • runne-secure-store holds secrets at rest; domain events and checkpoints carry only a SecretRef, never the secret value.

Pairing and platform identity ​

  • runne-pairing-crypto provides the pairing cryptography for authenticating hosts and clients.
  • Platform identity is established through native primitives — runne-macos-xpc (XPC service transport), runne-macos-process-identity, runne-sqlite-handle-identity, runne-sqlite-native-identity, and runne-windows-native-handle bind identity to OS-level handles.

What the repository defines ​

docs/05-security/ contains the target security contract (all ready): security model, threat model, trust boundaries, capability model, permission engine, approval model, sandbox profiles, filesystem/process/network policy, secrets management, MCP trust, plugin trust, audit requirements, and security testing. The mandatory side-effect path is:

intent → capability decision/grant → budget reservation → gateway
       → sandbox/process enforcement → side-effect evidence → audit

Audit failure vetoes the protected effect — no protected effect without durable audit evidence.