Governed workstations

Developer-alpha preview

This page documents real workstation controls, not a complete fleet control plane. Enrollment automation, central lifecycle management, compliance certification, and a production SLA are not part of the current alpha.

There is no enterprise edition. The binary a company deploys is the binary a hobbyist installs, and what differs is which config scope exists on the machine and who is allowed to write it.

That framing matters when you evaluate this: nothing below is a paid tier or a separate build. It is a file, a set of locked keys, and a handful of commands that verify the result.

The shape of a governed workstation

/etc/moxxy/config.yaml        system scope. Root-owned. Loads first.
                              Its `locked:` keys are stripped from
                              everything below.
        ▼
~/.moxxy/config.yaml          user scope. The person's own preferences.
        ▼
./moxxy.config.yaml           project scope. Committed with a repo.
        ▼
--flags                       explicit, per-invocation.

On Windows the system scope is %PROGRAMDATA%\moxxy\config.yaml; anywhere, $MOXXY_SYSTEM_CONFIG overrides the path.

Start from the profile

moxxy profile list
moxxy profile enterprise

moxxy profile enterprise prints a baseline. It deliberately does not install one: the target file is root-owned, and the profile carries site-specific entries — your proxy URL, your audit sink, your internal registry — that have no safe default. A command that silently wrote a machine-wide security policy would be doing the reviewing for you, and a guessed proxy URL is indistinguishable from an outage.

Review it, fill in the commented entries, then place it:

moxxy profile enterprise | sudo tee /etc/moxxy/config.yaml
# or, to a staging path for review:
moxxy profile enterprise --write ./moxxy-system.yaml

--write refuses to overwrite an existing file. A system config already in place encodes decisions somebody made, and clobbering it could silently unlock a control.

What the baseline turns on

security:
  enabled: true                            # enforce declared capabilities
  requireDeclaration: true                 # refuse tools that declare none
  thirdPartyRequireDeclaration: enforce    # ... especially outside @moxxy
  strict: true                             # fail closed on unrecognised fields

plugins:
  isolator:
    default: subprocess                    # a real process boundary

config:
  allowExecutable: false                   # never execute a project config

audit:
  enabled: true
  retentionDays: 400
  includePromptText: false

channels:
  mobile:
    bindHost: 127.0.0.1                    # loopback, not the office LAN

locked:
  - security.enabled
  - security.requireDeclaration
  - security.thirdPartyRequireDeclaration
  - security.strict
  - plugins.isolator
  - config.allowExecutable
  - audit
  - channels.mobile.bindHost

Every locked: entry is a control a user must not be able to switch off on their own machine. Everything left unlocked is either site-specific or carries no security weight; locking those would only generate support tickets.

Three entries ship commented out, because a wrong value is worse than none: the proxy URL, the audit sink, and the internal plugin registry.

Verify a workstation

moxxy doctor                    # environment, auth, services
moxxy config path               # which config files are actually in effect
moxxy config get security.enabled
moxxy sync --check              # plugin drift against the manifest; exits 1
moxxy security audit-log        # verify the audit chains; exits 1 on a break

The last two exit non-zero on a problem, so a provisioning pipeline or a scheduled compliance job can gate on them without parsing output.

Rolling out plugins

plugins.packages in the merged config is a manifest: a reviewable, committable description of what a workstation should run. Push it from the system scope, or commit it with a project, and machines converge on it.

moxxy sync             # install what the manifest declares and is missing
moxxy sync --check     # report drift, change nothing, exit 1 if anything is missing

Only missing is a hard failure. An extra package is a local decision, and removing something a user installed is their call, so it is reported and never done for them.

See supply chain for how those packages are resolved and why install scripts never run.

The pieces

Concern	Page
Who did it	Identity
What a user cannot change	Policy and locked config
What happened, provably	The audit trail
Where packages come from	Supply chain
Getting through the network	Egress and proxies

What moxxy does not claim

• Hash chaining is tamper-evident, not tamper-proof. Whoever can write the file can recompute the chain. It catches silent selective deletion, which is the realistic threat; a remote sink gives you a chain head the workstation cannot rewrite.
• Isolation is off unless enabled, and inproc is best-effort: it cannot contain a hostile plugin. Use subprocess when the boundary has to hold.
• The runner documents a Windows named-pipe DACL gap that the unix socket's 0600 mode does not have.

These are stated here for the same reason SECURITY.md states them: a control you have overclaimed is worse than one you never had.