GhostGet

Explanation · security model · GhostGet 0.19.0

How GhostGet limits what an agent can do on the web

An authenticated GhostGet operation binds one named outcome to an exact provider, transport, account realm, contract version, implementation, input, and risk. Credentials stay opaque to the caller. When those facts drift, the operation stops instead of changing transports or falling back to general browser control.

This guide describes GhostGet v0.19.0. Report vulnerabilities through GitHub private vulnerability reporting, never a public issue containing private material. If GitHub reporting is unavailable, email hraness@pm.me.

Foreign data is parsed; authority is selected separately

GhostGet treats CLI input, URLs, manifests, packages, plugin messages, provider responses, browser output, files, durable state, and subprocess diagnostics as untrusted. Foreign values are strictly parsed and bounded, and sensitive values are redacted from terminal output, receipts, and diagnostics.

Operations expose semantic jobs such as messaging.list, not raw cookies, selectors, scripts, arbitrary HTTP, native command arguments, or every signed-in tab. The exact auth locator is bound to one provider account and transport. GhostGet does not silently move between an official API, browser session, linked-device store, pinned local CLI, or portable plugin.

Account-bound reads stay under local custody

A successful R1 provider read with a verified account subject can publish an encrypted snapshot of the exact validated query and bounded provider output. The same query can later load from local ciphertext without contacting the provider. Within those snapshots, inputs, account subjects, cursors, private identifiers, and provider output remain inside authenticated local encryption. The separate owner messaging host retains private plaintext history and journals; see the privacy guide for storage and retention boundaries.

A failed refresh or publication does not erase the last verified snapshot. Replacing or removing an auth locator rotates its local lifetime identity, so ciphertext from an earlier account incarnation cannot become current after recreation. GhostGet reports the provider’s own paging and completeness as they are and never claims a result is more complete than the provider reported.

Risk levels keep reads and writes distinct

R1
A reviewed read with no intended remote mutation.
R2
One bounded, normally reversible change.
R3
An externally visible or consequential change.
R4
Blocked.

Generic R2 and R3 operations create an exact, short-lived preview. The confirmation binds the adapter, transport, account realm, input, attachment hashes, side effect, contract hash, and dispatch schedule. The separate owner messaging host can submit an exact prepared plan under explicit managed permissions and a revocable conversation grant with action, expiry, interval, and capacity limits. Its messaging.automation.* catalog entries are permission ceilings, not commands available through generic invoke or confirm; current account and runtime capabilities must also admit the action.

If a request left the machine but its response was lost, GhostGet retains the indeterminate result and does not retry or switch transport. A separate reconciliation needs exact external evidence. Cancellation or revocation stops remaining work but does not prove an already-started action was unsent. Provider acceptance is distinct from delivery or read status.

Provider drift fails closed

A changed origin, account proof, request, status, field, or response shape returns the affected operation to capture-required. An operation in that state can’t plan or run until authorized evidence supports a newly reviewed contract.

This rule keeps capability gaps visible. For example, LinkedIn's official contact adapter does not grant authority to its separate consumer-web inbox adapter, and an Instagram inbox summary does not authorize an individual thread read. Review current state in the provider support reference.

A provider CLI is pinned bytes behind a semantic contract

A source plugin can use the local-cli transport only when it records the exact executable SHA-256 for every supported platform and binds every upstream archive or release-manifest artifact that the provider publishes. Each operation owns a fixed argument template and strict projection. Callers cannot select a command, flag, endpoint, target, environment variable, plugin, or output path.

GhostGet starts the exact executable without a shell under private config, data, cache, and temporary roots. It strips ambient credentials and defaults, enforces its own deadline and byte bounds, and treats a lost or malformed post-dispatch response as indeterminate. A version range, package-manager channel, tag, launcher, or reported version cannot replace executable-byte identity.

CLI updates use verified releases

Supported global installations check the fixed GhostGet GitHub repository for a stable immutable release. The updater verifies the selected archive and its published SHA-256 before asking the installation's package manager to replace it. It waits for running commands to finish and leaves connected accounts and saved content in place. Source checkouts and project dependencies keep their existing package-manager workflow.

Automatic checks run before ordinary commands, at most once a day. Use ghostget update disable to opt out, ghostget update status to inspect the setting, or HRANESS_NO_UPDATE=1 for a command that must use the installed version. Exact version pins require ghostget update enable before following new releases. See the update guide for requirements and limits.

Portable plugins are contained, not treated as hostile code

Source plugins ship as trusted in-process code. A portable plugin requires an explicit trust decision for one verified, content-addressed bundle and runs through a denied-by-default child-process protocol. The protocol limits the services a well-behaved plugin can request and contains ordinary crashes.

It is not a hostile native-code sandbox. Plugin code still runs with the ambient operating-system authority of the current account. Review code before trusting it, keep GhostGet state on a trusted local filesystem protected for that account, and follow the plugin verification workflow.

Archive integrity is verifiable, but local same-user processes remain trusted

Completed media archives use versioned manifests and SHA-256 records that ghostget verify recomputes. GhostGet invokes media tools without a shell and does not persist cookies, request headers, signed media URLs, raw yt-dlp metadata, or transport fragments.

Archive locks and atomic same-volume publication coordinate GhostGet processes. They are not a boundary against another process running as the same user. Keep archive roots and transcription configuration on a trusted local filesystem, obtain selected native tools and models from trusted sources, and use verification to detect later changes.