securitypermissionsbest-practices

Secure Defaults for TypeScript Apps That Want Desktop or Device Access

UUnknown

2026-02-18

10 min read

Checklist and TypeScript examples for secure defaults when apps request desktop or device access—manifest, sandboxing, consent, and CI checks.

Hook: Why desktop/device access in 2026 is a security crossroads

Modern TypeScript apps increasingly request powerful access: file systems, cameras, microphones, USB devices, GPIO pins on single-board computers, and even desktop automation. Recent product moves — from Anthropic's Cowork granting desktop-level file access to agent workflows, to the Raspberry Pi AI HAT+ 2 unlocking local AI on Pi devices — make these capabilities mainstream in 2025–2026. That means TypeScript teams must design safe defaults now, or risk breaches, privacy violations, and regulatory headaches.

What this article delivers

This is a practical checklist and cookbook for secure defaults when your TypeScript app asks for desktop or device access. You’ll get:

Concrete permission patterns and TypeScript code you can drop into Electron, Tauri, or Node-based device projects
Sandboxing and runtime hardening guidance
Manifest, tsconfig, linter, and CI pipeline rules to enforce least privilege
Testing strategies for permission and consent flows
2026 trends and practical recommendations shaped by Cowork and Pi AI HAT developments

2026 context: why this matters now

In late 2025 and early 2026 we saw two trends accelerate: desktop agents asking for broad file and system access (e.g., Anthropic’s Cowork) and powerful local-device-capable hardware (e.g., AI HAT+ 2 for Raspberry Pi 5) enabling offline ML and device control. These trends create a new threat surface — and a new responsibility for developers to ship secure defaults.

"Anthropic launched Cowork, bringing autonomous capabilities... to non-technical users through a desktop application." — Forbes, Jan 2026

Top-level principle: default to denial

Adopt the least privilege principle by default. Your app should request no device or desktop capability until it can explain why it needs that specific capability, and the request must be user-initiated and auditable. This ties closely to data sovereignty concerns for cross-border consent storage and retrieval.

Checklist: Secure defaults for device & desktop access (quick)

Permission manifest: declare all permissions in a static, versioned manifest.
Runtime gating: require explicit user consent at the moment of use, not at install.
Scoped access: restrict file/FS and device access to directories or device IDs.
Sandboxing: enable process-level sandboxes, context isolation, and OS-level restrictions.
Preload API: expose only minimal, validated APIs from privileged processes.
Policy checks in CI: enforce manifest changes and lint rules in pipeline gating.
Audit & telemetry: log every grant/revoke to a local, tamper-resistant store.
Secure storage: store consents in OS keystores or encrypted stores (avoid plain JSON).
Code signing & SBOM: sign releases, publish SBOMs, use sigstore/cosign.
Testing: unit + e2e tests cover consent UX and revocation.

Implementing permission manifests

A manifest is the single source of truth your CI and runtime can check. Keep it human-readable, versioned, and immutable in the release artifact. Example: permissions.json. If you operate in regulated environments consider patterns from hybrid sovereign cloud guidance to decide where manifests and consent artifacts are stored.

{
  "version": "1.0.0",
  "requested": [],
  "allowed": [
    {
      "resource": "filesystem",
      "scope": ["/home/user/MyApp/data"],
      "reason": "Store local models and user projects",
      "default": "deny"
    }
  ]
}

CI should fail the build if code imports a privileged API but that API isn’t listed (see CI section).

Desktop app patterns: Electron and Tauri examples

Electron secure defaults (recommended)

Electron is powerful but insecure by default. Use these defaults in main process creation:

// main.ts (Electron main process)
import { app, BrowserWindow } from 'electron';

function createWindow() {
  const win = new BrowserWindow({
    webPreferences: {
      contextIsolation: true,
      nodeIntegration: false,
      sandbox: true,
      preload: path.join(__dirname, 'preload.js')
    }
  });
  win.loadURL('app://index.html');
}

In your preload script, expose a minimal API via contextBridge and validate all input server-side (main process):

// preload.ts
import { contextBridge, ipcRenderer } from 'electron';

contextBridge.exposeInMainWorld('secureAPI', {
  requestPermission: (payload: PermissionRequest) => ipcRenderer.invoke('request-permission', payload),
});

Tauri (stronger defaults out of the box)

Tauri favors a minimal Rust backend and WebView front-end. Keep tauri.conf.json's allowlist strict and use tauri::api::dialog for consent. For broader orchestration and edge-device scenarios see hybrid edge orchestration patterns — Tauri’s built-in separation helps, but you still need a manifest and CI checks.

Example: Type-safe PermissionManager in TypeScript

Create a small, testable permission manager that enforces manifest rules, prompts the user, and stores consent.

// types.ts
export type Resource = 'filesystem' | 'camera' | 'microphone' | 'usb' | 'gpio';

export interface PermissionRequest {
  resource: Resource;
  scope?: string; // e.g. path or device id
  reason: string; // short user-facing reason
}

export interface PermissionRecord {
  resource: Resource;
  scope?: string;
  granted: boolean;
  grantedAt?: string;
}

// permissionManager.ts
import keytar from 'keytar'; // secure storage
import fs from 'fs';

const MANIFEST_PATH = './permissions.json';

export class PermissionManager {
  private manifest: any;

  constructor() {
    this.manifest = JSON.parse(fs.readFileSync(MANIFEST_PATH, 'utf8'));
  }

  async request(req: PermissionRequest): Promise {
    // 1) check manifest
    if (!this.isDeclared(req)) throw new Error('Permission not declared in manifest');

    // 2) check stored consent
    const key = this.storageKey(req);
    const stored = await keytar.getPassword('MyApp-Permissions', key);
    if (stored) return JSON.parse(stored);

    // 3) prompt user (UI code should call this via IPC)
    const granted = await this.promptUser(req);

    const record: PermissionRecord = { ...req, granted, grantedAt: granted ? new Date().toISOString() : undefined };

    // 4) store securely
    await keytar.setPassword('MyApp-Permissions', key, JSON.stringify(record));

    // 5) audit log (append-only, tamper resistance via signing recommended)
    this.audit(record);

    return record;
  }

  private isDeclared(req: PermissionRequest): boolean {
    return this.manifest.allowed?.some((p: any) => p.resource === req.resource && (!p.scope || p.scope.includes(req.scope)));
  }

  private async promptUser(req: PermissionRequest): Promise {
    // Implement UI modal that explains req.reason and origin
    // Placeholder: return false in non-UI context
    return false;
  }

  private storageKey(req: PermissionRequest) {
    return `${req.resource}:${req.scope ?? 'global'}`;
  }

  private audit(record: PermissionRecord) {
    // Append to local audit file; sign with release private key in production
    fs.appendFileSync('./audit.log', JSON.stringify(record) + '\n');
  }
}

This design separates manifest checks, user consent, and secure storage. The promptUser method is intentionally UI-layered so that UI frameworks can provide clear, accessible, and localized consent dialogs.

Sandboxing & process hardening

Use multiple layers of sandboxing:

Language-level: use TypeScript strict mode and memory-safe languages for native components (Rust recommended over C/C++).
Process-level: enable contextIsolation, nodeIntegration: false, and OS sandbox flags.
OS-level: use Seccomp, AppArmor, or sandbox APIs; use Flatpak/Snap/AppImage for Linux distribution isolation.
Containerization: for background services, use small, hardened containers with minimal capabilities.

For Raspberry Pi device access (GPIO, I2C, etc.), isolate hardware control into a privileged native helper process with a well-defined IPC surface. Keep the high-level app in the webview sandbox. See hardware helper patterns like the Smart365 Hub Pro for examples of controller minimization and isolation.

tsconfig, linter, and build settings that enforce safe defaults

Make unsafe patterns visible and push checks into CI.

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "strict": true,
    "noImplicitAny": true,
    "noUncheckedIndexedAccess": true,
    "esModuleInterop": true,
    "skipLibCheck": false,
    "forceConsistentCasingInFileNames": true
  }
}

ESLint rules (sample):

// .eslintrc.json (relevant parts)
{
  "rules": {
    "no-eval": "error",
    "no-implied-eval": "error",
    "no-new-func": "error",
    "security/detect-dangerous-regexp": "error",
    "security/detect-child-process": "warn",
    "no-console": ["warn", { "allow": ["warn", "error"] }]
  }
}

CI pipeline: enforce permission and security checks

Integrate permission manifest validation, TypeScript/ESLint, SAST, dependency scanning, and SBOM generation into CI. Sample GitHub Actions snippet:

// .github/workflows/ci.yml (excerpt)
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npm run lint
      - run: npm run build --if-present
      - run: npm test
      - name: Validate permissions manifest
        run: node ./scripts/validate-manifest.js
      - name: SCA & SAST
        uses: github/codeql-action/analyze@v3
      - name: Generate SBOM
        run: npm run generate-sbom

Automated CI checks should be paired with incident readiness — keep a postmortem template and incident comms plan in your repo so permission regressions trigger clear responses.

Testing permission flows

Test both the logic and UX:

Unit tests for PermissionManager behavior (manifest enforcement, storage, audit writes).
E2E tests with Playwright or Spectron that simulate user consent, revocation, and denied flows.
Fuzz tests on IPC endpoints and inputs to privileged processes.

// example Jest unit test
import { PermissionManager } from '../permissionManager';

test('denies when manifest missing', async () => {
  const pm = new PermissionManager();
  await expect(pm.request({ resource: 'usb', reason: 'test' })).rejects.toThrow(/manifest/);
});

A consent dialog should:

State exactly what resource is requested and the requested scope (path, device ID).
Show the reason the app provided and who is requesting (app name + process signature).
Offer allow-once, allow-until-restart, or persistent allow options.
Link to a privacy policy and a quick revoke option.
Log consent events locally and (if telemetry enabled) securely send an anonymized consent telemetry event with user opt-in.

Never store consent in plaintext config files. Use platform keystores (Keychain, DPAPI, Linux secret stores) via libraries like keytar. Provide an in-app revocation UI that also invalidates any cached device tokens.

Auditability and tamper resistance

Keep an append-only audit log of permission grants and revocations. In production, sign the audit records using a release private key or use hardware-backed keystore attestation where available. Publish an SBOM for each release and sign artifacts with Sigstore — this aligns with emerging requirements for hybrid sovereign deployments.

Native helpers for device access: isolate and minimize

When you need native device access (e.g., GPIO, serial, USB), prefer a small native helper with:

Minimal API surface
Strict input validation
Process isolation and hardened compilation (use Rust)
Independent update channel and signature verification

Real-world example: Pi AI HAT integration pattern

For Pi HATs like AI HAT+ 2, follow this pattern:

Expose hardware via a privileged helper (Rust binary launched with caps limited to /dev entries).
The web frontend requests access via PermissionManager which validates manifest and prompts the user.
On grant, the helper creates a scoped token with limited TTL and device handle; the frontend uses the token via IPC.
Revoke destroys tokens and closes handles immediately.

Monitoring & post-deployment controls

Post-deploy, continuously monitor for abuse patterns (sudden mass file reads, unexpected device enumerations). Use automated alerts and a safety switch that forces all privileged operations to be denied until human review.

Future predictions and trends (2026+)

Expect these trends through 2026:

Capability manifests become standard across desktop ecosystems, much like Android/iOS permission models.
App stores and OS vendors will require SBOMs and signed permission manifests for apps requesting sensitive desktop/device access.
More frameworks (Tauri-style) will ship with finer-grained OS integration points to let apps continue being web-first while preserving device safety.
Regulatory attention toward automated agents with desktop access will force stricter audit and consent rules.

Actionable takeaways (start today)

Declare a permissions manifest for your app and enforce it in CI.
Make consent runtime user-initiated and scoped; implement a PermissionManager typed in TypeScript.
Enable strict TypeScript and ESLint rules; fail CI on unsafe patterns.
Use secure storage (keytar) and signed audit logs for consent records.
Isolate device access in a small, hardened native helper (prefer Rust).
Sign releases, publish SBOMs, and integrate SAST/SCA in your pipeline.

Closing: Safe defaults are a product and security win

Until platform-level defaults catch up, your app must be the guardian of user trust. Implementing strict manifests, runtime consent, limited-scope helpers, and CI enforcement not only reduces risk — it makes your product more trustworthy and competitive in a 2026 landscape where local AI and desktop agents are ubiquitous.

Next steps

Start by adding a permissions.json to your repo and a PermissionManager stub. Put a pipeline gate on manifest changes and add one unit test that fails when a declared permission is unused — it’s an effective guardrail.

Call to action

If you’re converting a legacy Electron app or building a device-integrated TypeScript product, download the sample PermissionManager and CI templates from our repo, run the manifest validator in your pipeline, and join the discussion on safer desktop agents in our 2026 security roundtable. Ship features fast — but ship safe by default.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.