Skip to navigation
AboutCore Concepts

Security and Trust

Dev
View as Markdown

Security boundaries control which files, tools, credentials, and delivery actions a model can access in DocsFab. Repositories, model output, provider responses, and command output supply data; they do not grant authority.

Use these boundaries to understand what a local session can change and which artifacts you can share. Exact controls, platform limits, storage details, and refusal codes are in the DocsFab Security Reference.

Current Product Scope

These controls describe the current local runtime and a separately gated private pilot. They do not establish a released multi-tenant security model.

Boundaries at a Glance

The following table summarizes each boundary and its purpose.

BoundaryPurpose
Repository to workflow workspaceKeep named workflow work bound to tracked files at a selected revision.
Workspace to modelLimit a workflow step to its allowed tools and context.
Live agent to checkoutAllow documentation-scoped edits and separately approved host commands.
Host credentials to providersRetain configured credentials in fixed-purpose adapters, outside model prompts and durable evidence.
Result to deliveryRecheck authorization before a host action changes GitLab.
Skills to jobBind executable skills and quality inputs through their catalog locks.

Trust Principles

The following principles explain the controls you encounter during work.

  • Product evidence supports claims; it does not grant permission to write, merge, or publish.
  • Direct live-agent edits are enabled by default. Read-only mode removes edit, write, and host-command tools.
  • Host commands need terminal approval and use filesystem isolation. Approved commands can still use the host network and existing Git authentication.
  • Named workflows retain their own tool, write-scope, and delivery checks.
  • Raw run records and patches are private operator artifacts. Share sanitized projections of them.
  • A resumed conversation cannot revive a revoked grant or override the current process flags.

For the exact controls, refer to Session Permissions, Command Lifetime, and Linked Worktrees.

Data Handling

Local sessions keep conversation and task state on your machine. The private pilot has separate storage, retention, and request handling. A deletion on one surface does not remove every copy.

Refer to Local CLI Data for local storage and cleanup, or Private Pilot Data for pilot retention and individual data requests.

Network and Model Access

Provider adapters control where a configured model key is sent. The optional outbound proxy applies its own credential and destination controls. These controls do not give a model unrestricted network access.

For exact behavior, refer to Outbound Proxy, Proxy Credentials, Doctor Output, Refusal Codes, and Proxy Failures. For model requests and validation commands, refer to Where a Model Key Is Sent and Check Scripts.

Operator output still directs the following codes to this overview. Continue with the corresponding reference topic.

  • credential-endpoint-untrusted: Model Key Destinations.
  • outbound-proxy-auth-required, outbound-proxy-denied, outbound-proxy-invalid, outbound-proxy-not-enabled, and outbound-proxy-unreachable: Proxy Refusal Codes.

Credential-Like Content

DocsFab distinguishes its own configured credentials from text that resembles one. Exact configured credentials are refused at protected boundaries. Credential-shaped text can instead become a finding for review. The behavior depends on the output surface.

Refer to Text That Looks Like a Credential, DocsFab’s Own Credentials, Redaction, and What the Detector Flags. The Screen Behavior Reference explains surfaces that flag findings instead of refusing output.

Continue with the following pages for the relevant level of detail.