Status labels used here:

• Enforced: the application technically prevents it.
• Partially Enforced: enforced for some paths, with a named gap.
• Advisory Only: shown or recommended, but nothing prevents it.
• Not Implemented

Anything that relies on trust rather than enforcement is called out.

• Least privilege. The manifest requests asInvoker, so the app is never elevated. Only the MSI install itself needs administrator approval (it writes to Program Files).
• Secure defaults:
  • Privacy mode Fully Local.
  • Third-party extensions disabled.
  • Remote runtimes disabled.
  • Development Mode off.
  • Agent permission profile Ask Before Changes.
• Central services, never bypassed. Architecture tests check that Domain, Application, Integrations and Extensions reference no HttpClient, Socket or Process types.
• Fail safe. A missing key, an unknown network class, an unresolvable path, or a manifest with an unknown permission is refused.
• Everything external is untrusted: model metadata, Hugging Face data, Ollama responses, imported stack profiles, extension packages, environment variables, executable paths, agent output.

 User ── UI (WPF, view models) ── Application services ── Domain ports
                                         │
            ┌────────────── Security assembly (only implementation of the ports below) ───────────────┐
            │ ProtectedPathService  SecureProcessExecutionService  NetworkSecurityService            │
            │ SecureCredentialService  SecurityAuditService  ConfigurationProtectionService          │
            │ PackageVerificationService  UpdateSecurityService  SecurityPolicyService  Permission… │
            └──────┬──────────────────────┬───────────────────────┬────────────────────┬─────────────┘
           child processes          loopback / approved     Windows Credential     app data dir
       (agents: Claude Code, Codex)   HTTP(S) endpoints        Manager (DPAPI)     (%LOCALAPPDATA%)
                │                          │
        project folders            Ollama (local runtime) ── downloads models itself (outside app policy)
                                           │
 Extensions ── SdkCapabilityBroker ── (same services, Extension actor, permission-checked)

Boundaries:

• Built-in (not removable):
  • App data: the data root itself and its config, audit, logs, backups, extensions and staging folders are BlockAllAccess for agents and extensions (the app itself may write). test-projects (Quick Setup sample projects) and agent-profiles (isolated agent config such as Codex CODEX_HOME) are deliberately usable by agents.
  • Windows and Program Files: ReadOnly + NoAddOnAccess.
  • Credential stores (.ssh, .gnupg, .aws, .azure, .kube, .docker, Windows Credentials/Protect folders): BlockAllAccess.
• Default user rule (removable): %USERPROFILE%\Projects, ReadOnly + AskBeforeDeletion + NoAddOnAccess. An agent can still be started there deliberately: it needs explicit approval every time, and the session is forced to the Read-Only profile.
• Rules: Block All Access, Read Only, Ask Before Writes, Ask Before Deletion, No Process Execution, No Add-On Access. All matching rules combine and the most restrictive wins.
• Working folders that are a drive root, the whole user profile, a network share or removable media require approval.
• Enforcement scope: the app enforces these rules for its own operations and at agent launch. Inside a running agent session, file access is governed by the agent's own permission system. The app does not sandbox agent processes (Advisory beyond launch).

• Profiles: Read-Only, Ask Before Changes (default), Project Workspace Only, Standard Development, Advanced Development, and custom profiles.
• Coverage: every agent permission (file read, create, write and delete; directories; process execution; terminal; network; package installs; git; outside workspace; credentials; local services; external APIs; add-ons; privileged operations).
• Enforcement labels: each permission is shown with who enforces it: Application Enforced, Agent Configured, User Approval Required, Advisory Only or Unsupported. See the Agents screen.
• Never generated: bypassPermissions, --dangerously-skip-permissions, danger-full-access and approval never. These are covered by tests.

• Location: %LOCALAPPDATA%\DarkCipher\AgentControl\audit\security-audit.jsonl.
• Fields: Timestamp, Action, Component, Result, Affected Resource, Security Classification, Correlation ID, Detail (redacted), Prev, Mac.
• Recorded events:
  • Privileged operations, process starts, stops and blocks.
  • Protected-path violations and approvals.
  • Credential create and remove (no values).
  • Policy changes; weakening changes are classified High.
  • Endpoint approvals and network blocks.
  • Extension install, update, enable, disable, remove, tamper and capability denials.
  • Config changes and rollbacks.
  • Stack imports.
  • Cloud sessions.
  • Downloads.
  • Update signature checks.

1. Code extensions are not isolated (in-process). Out-of-process, low-integrity isolation is Planned.
2. A Job Object assignment race allows a tiny window for an early grandchild to escape.
3. The audit chain cannot detect tail truncation without an external anchor.
4. Once launched, an agent's actions inside its session are governed by the agent, not this app.
5. Ollama performs model downloads itself, so its network traffic does not pass through this app's network policy.
6. No code-signing certificate, so builds are unsigned and the updater stays disabled.
7. Development-time rule: this project was built without writing anything under %USERPROFILE%\Projects. The Projects default rule enforces the same idea at run time.
8. (0.1.6) Tool installs are only as trustworthy as winget's community repository: winget checks the installer's SHA-256 against the reviewed manifest, but this app does not verify publisher signatures of those installers itself.
9. (0.1.6) Extension health checks and model sources run in-process (code extensions are not isolated); they are time-limited and exceptions are contained, but a hostile extension could still misbehave inside the process.

| Starting software the app does not own (0.1.8) | Only Ollama's own tray app (ollama app.exe next to the detected ollama.exe), and only from Quick Setup after plan approval or from a Fix the user clicks. A running Ollama is never restarted. It is launched as a Background helper: same executable, argument, working-folder and environment validation as every launch; no window; CreateProcessW with handle inheritance off, so the helper holds none of this app's handles; a job without kill-on-close, so it survives the app and Stop still ends its tree. Background mode is refused for agents and extensions (ProcessBlocked). | Enforced |

| Wider catalogue (0.1.9): 17 more winget packages | Each entry is reviewed and pinned in code: an exact package id, an https homepage and a licence. Per-user installer availability was checked against the live winget source (Live_catalogue_entries_resolve_per_user_and_plan_without_installing). Packages without a per-user installer (GPT4All, Docker Desktop) were left out. Detection reads one shared winget list snapshot (cached 60 s, invalidated by every install, update and uninstall). It never starts GUI apps to read a version and ignores WindowsApps aliases. | Enforced | | Gateways installed "by name" | A gateway built into a runtime plans its runtime's install, and the plan says so. Update and uninstall are refused on the gateway and managed on the runtime. | Enforced | | Bundled gallery extensions (0.1.9) | Packed from the app's install folder by the shared packager and reviewed through ExtensionHost.ReviewBundled: all normal checks, plus data only and the darkcipher.gallery. prefix. Only that path may use the reserved identity (trust Verified). Install from file… and dcx-ext pack still refuse it. Bundled extensions load even when third-party extensions are disabled; Safe Mode still blocks them. | Enforced (integrity relies on the install folder being admin-writable only, as for the app's own binaries) | | Right-click menus | Menu items are the page's existing commands with their CanExecute rules. Destructive actions are always last, in the danger colour, and keep their confirmation dialogs. | Enforced |

New audit events: ToolOperationApproved, ToolOperationDeclined, ToolOperation, ToolPlanChanged, CustomAgentRegistered, CustomAgentValidated, ExtensionCatalogueEntry, TemplateRegistered, TemplateSaved, TemplateImported, TemplateImportRejected, ConfigTransactionCommitted, ConfigTransactionRolledBack, ConfigRemoved, StackVerified, DownloadQueued and DownloadFinished (now with stage and verification).