Trust & Privacy

Workloom is built for organizations that take AI agent governance seriously. Every asset is classified by risk level, and trust gates enforce approval requirements before anything dangerous touches disk. Privacy isn't an afterthought — it's enforced at the schema layer.

Trust Classification

Every asset in a Workloom package carries a trust class — a risk classification that determines what gates must pass before the asset can be rendered to disk.

Trust Class	Examples	Default Projection
passive_text	Instructions, prompts, CLAUDE.md, AGENTS.md prose	generated_local
configuration	Provider settings, editor config, .codex/config.toml	manual_review
tool_permission	Sandbox settings, permission grants	approval_required
executable_hook	Pre-commit hooks, shell commands, .claude/hooks/**	approval_required
networked_mcp	MCP server configs with URLs, remote server declarations	approval_required
telemetry_emitting	Telemetry schema definitions, event configs	manual_review

Trust Escalation

Trust class escalation is monotonic — it only goes up, never down:

• If a configuration file contains a hook definition, the entire file is promoted to executable_hook
• Package authors cannot downgrade trust classes
• Only workspace operators can override classification via workspace policy, and only upward to stricter defaults

The precedence order from least to most restrictive:

passive_text < telemetry_emitting < configuration < tool_permission = executable_hook = networked_mcp

tool_permission, executable_hook, and networked_mcp are peers at the highest restriction level.

Projection Policies

Projection policies control how rendered output lands on disk. Workspace manifests declare policies per provider:

Policy	Behavior	Use Case
generated_local	Written locally, usually .gitignored	Claude skills, generated configs
committed_projection	Generated and expected to be committed	Copilot instructions, shared rules
user_local	Written to user config, never synced	Personal settings, local preferences
manual_review	Diff shown, user applies manually	Provider settings changes
approval_required	Blocked until explicit approval	Hooks, MCP servers, permissions
forbidden	Cannot render for this target/provider	Unsupported asset types

Trust Gates Are Non-Optional

Workloom will never silently write a hook, MCP server config, or tool permission grant to disk. These asset types always require explicit approval, regardless of workspace configuration. Workspace policies can only increase restriction levels — never decrease them.

Per-Surface Risk Analysis

Hooks

Risk: Hooks execute arbitrary shell commands on the developer's machine. A malicious or misconfigured hook can exfiltrate data, modify system files, or escalate privileges.

Gate: Explicit operator approval per hook. The full command is displayed before the approval prompt. No bulk approval. Re-approval required if the hook command changes after a package update.

MCP Servers

Risk: MCP server configurations connect AI providers to external network endpoints. A malicious server can receive prompt content, exfiltrate workspace context, or execute tool calls against external systems.

Gate: Explicit operator approval per server URL. Approval is URL-and-scheme scoped (not wildcard). Changing the URL — even by port only — invalidates the prior approval.

Tool Permissions

Risk: Tool permission grants expand what the AI provider can do (file writes, subprocess execution, browser control). Over-broad grants can cause unintended data modification.

Gate: Approval per permission set. Adding a new permission to an existing approved set triggers re-approval for the full set.

Provider Settings

Risk: Settings can enable debug modes, disable safety features, or enable experimental features with unknown side effects.

Gate: Manual review — a diff is generated and displayed. Settings containing hooks or tool permissions escalate to approval_required.

Committed Projections

Risk: Files committed to version control are visible to all repo contributors and stored in git hosts, CI systems, and backups. A committed projection with embedded secrets is a supply-chain risk.

Gate: Pre-commit validation scan. Trust-sensitive assets require a review gate before staging for commit.

User-Local Projections

Risk: User-local files persist across workspace sessions and affect all workspaces for that user.

Gate: Workspace config must explicitly set allow_user_local: true for the provider. Each user-local path must be listed in the lock file.

Workspace Policy Overrides

Workspace operators can tighten (never loosen) trust defaults:

{
  "projectionPolicy": {
    "claude": "approval_required",
    "codex": "manual_review"
  }
}

Attempts to set a policy value lower than the default for a given trust class are rejected at validation time.

Privacy-First Telemetry

Workloom's telemetry system is designed with a default-deny approach.

Opt-In Only

Telemetry is disabled by default. No events are emitted until the operator explicitly opts in. Opt-in is workspace-specific — global opt-in does not automatically apply to new workspaces.

Forbidden Fields

The following fields are permanently forbidden in any telemetry event. This isn't a policy — it's enforced at the Zod schema validation layer, meaning the event is rejected at the call site before it can be emitted:

Forbidden Field	Why
rawPrompt	Could contain proprietary instructions or user data
rawOutput	Model outputs may contain sensitive information
sourceCode	Source code is intellectual property
fileContents	File contents may contain secrets or PII
exactPath	Absolute paths expose system structure and usernames
diff	Diffs may contain source code or secrets
stackTrace	Stack traces can expose internal architecture
username	Personal identifier
email	Personal identifier
token	Authentication credential
secret	Sensitive value
password	Authentication credential
apiKey	Service credential
credential	Generic sensitive value

What IS Collected (When Opted In)

Only operational metadata:

• Event type (workspace_sync, package_install, etc.)
• Anonymous hashes of org, workspace, and user IDs (SHA-256, one-way)
• Provider name
• Package name and version (not contents)
• Command name (pull, sync, validate)
• Duration in milliseconds
• Result (success, failure, skipped, timeout)
• Platform (darwin, linux, win32)
• Source (local-cli, ci, web, desktop)

Enterprise Confidence

The forbidden-fields enforcement is tested with dedicated negative test fixtures. Each of the 14 forbidden fields has an explicit test case that verifies rejection. This means your security team can audit the test suite and confirm that sensitive data can never leak through telemetry.

Debug Bundles

Debug bundles collected for support or diagnostics are never auto-collected. They require:

1. Explicit wl debug bundle invocation
2. Confirmation of data scope with --confirm flag
3. Local output only — never automatically uploaded
4. Exclusion of user_local file contents
5. Exclusion of environment variables unless --include-env is passed

Trust in CI

In CI pipelines, wl sync --check verifies that the workspace is in the desired state:

• Exit code 0 — all files match desired state
• Exit code 1 — drift detected
• Exit code 5 — trust policy violation

CI service accounts use scoped tokens with read/check-only access — they cannot publish packages or modify workspace configurations.

Next Steps

• Learn about Drift Detection to understand how Workloom tracks file state
• See the CI/CD Integration guide for enforcing trust in your pipeline
• Read about Providers to understand provider-specific trust considerations