Architecture

How OpenScope Works

A thin client sends scoped requests to a broker daemon that holds privileged execution boundaries, enforces policy, and records decisions.

Architecture overview

OpenScope separates the agent-facing interface from the privileged execution layer. The agent calls a small client surface. The broker daemon validates the request, applies policy, performs the approved action through a protected executor, and records the result.

Request lifecycle

Every OpenScope request follows a predictable flow.

1. The agent asks for a scoped action

The agent requests a predefined operation rather than a raw tool surface.

2. The broker validates and authorizes

OpenScope checks agent identity, app, action, and parameter-specific allow rules.

3. The privileged operation stays inside the broker

Automation approvals, credentials, profiles, or targets stay in the broker boundary.

4. The broker records the decision

Allow and deny outcomes are auditable after the fact.

Scoped capabilities, not raw tools

A capability is narrower than a raw tool surface. Instead of generic shell access or raw automation access, the broker exposes named actions whose parameters can participate in policy.

Action examples

openscope notes list_notes --agent openclaw --folder Work
openscope notes read_note --agent openclaw --folder Work --note "Sprint Plan"
openscope mail list_messages --agent openclaw --mailbox Inbox --limit 20 --unread true

Policy examples

sudo openscope policy allow --agent my-agent --app notes --action list_notes --folder Work
sudo openscope policy allow --agent my-agent --app notes --action read_note --folder Work
sudo openscope policy deny  --agent my-agent --app notes --action list_notes --folder Private

Protected integrations

OpenScope starts with Notes and Mail and extends the same broker model to external systems through HTTP profiles, SSH targets, and YAML-defined custom apps.

Notes and Mail

Scoped actions for protected local apps instead of raw automation power.

HTTP profiles

Broker-owned base URLs and auth headers for integrations such as Jira.

SSH targets

Named targets and approved services rather than broad shell access.

Custom apps

YAML-defined actions that preserve the same trust boundary and policy model.

Jira example

A Jira integration can be split into a broker-owned HTTP profile and a user-defined app manifest. The broker keeps the base URL and authorization header while the manifest defines narrow actions.

Packaging and runtime shape

On macOS, OpenScope is designed to package a signed runtime so stable Automation approval attaches to the broker, not to the agent. The CLI stays lightweight while the privileged daemon remains the narrow execution boundary.

Signed app bundle for stable identity
LaunchAgent-managed daemon
CLI wrapper installed on PATH
Protected resources bundled with the broker runtime