Privacy statement

Every collector on the device.

What each Rune Guard collector on the device observes, what turning it off does, and what stays on the device.

Every request a device makes

On the device

What each collector observes, and what stays on the device.

Collectors with their category, what they observe, what happens when their opt-in is off, and what stays on the device
Collector	Category	What it observes	When its opt-in is off	What stays on the device
Harness tool hooks	Agent activity	Each tool call an AI agent makes through an installed harness hook, checked against policy: the rule, decision, harness, hashed session key and identifiers. Tool input and output are read on the device to decide; they are not uploaded outside the session_content opt-in.	Always on.	Tool input and output text, commands, paths. Package names an agent installs, except a look-alike of a public reference name and a name the public registry doesn't have, which a package finding carries. Message recipients: only their domain and a keyed hash of the address, in a recipient finding when the organization's recipient rules are on; never the local part, a chat channel's name or the message. The package and runtime inventory and its paths, except the name, version and advisory of a package a public advisory names, which a package advisory finding carries.
Process and file sensor	Agent activity	Processes, credential and agent-configuration file opens, and network destinations of processes attributed to an AI tool (Endpoint Security or eslogger on macOS, the Linux sensor, ETW on Windows).	Always on.	Events of processes that aren't attributed to an AI tool are not reported. On Linux the root sensor matches agents' MCP server launches against the launch index each user hands the local root receiver (launch signature digests, harness names, registry names or hashed mcp-server- labels and classifications, never a command, argument, path, environment value or config name); the index never leaves the device, and the root sensor never reads users' MCP configs. Hosted DeepSeek, Kimi/Moonshot and Alibaba Model Studio recognition uses only catalog API hosts, including single-label regional workspace patterns. It does not inspect provider request bodies, model names, credentials or responses. IP-only pollers resolve exact catalog hosts only; wildcard recognition adds no DNS enumeration or provider request.
Screen capture sessions	Agent activity	That a process attributed to an AI tool started a screen capture through an operating-system capture service, with the process, the agent and the method (its rule): ScreenCaptureKit on macOS, from Endpoint Security or eslogger XPC events, and the desktop portal's ScreenCast and Screenshot calls on Linux, from a D-Bus monitor that runs as each login user and that the bus sends only those calls. guard scan also reads the TCC databases read-only for screen recording permissions held by AI tools or their host apps.	Always on with the sensor; guard-sensor live --screen-portal off stops the Linux portal monitor.	Screen contents, window titles, D-Bus message bodies and call arguments are never read; TCC clients named by path are reduced to the executable name.
Posture and inventory	Agent activity	Installed AI tools, MCP servers, agent settings that loosen guardrails, and macOS privacy (TCC) permissions granted to AI tools or to the terminals and editors agents run inside, because agents inherit those grants. guard scan reads the TCC databases read-only for the Full Disk Access, Accessibility and Input Monitoring grants AI tools already hold. For local model servers (Ollama, LM Studio, llama.cpp, vLLM, LocalAI, Jan, GPT4All, LiteLLM, MLX-LM, SGLang): version, listening ports, whether they listen beyond loopback, and the names, count and total size of the models they hold, from the socket table and directory listings. Also, for each local model server listening on the device: the public names of the models it lists (a bare name such as llama3.1:8b, or owner/name with an owner in the signed catalog's local_models.public_model_publishers; any other name is uploaded as a device-keyed hash, model- and 16 hex digits), their size or quantization when given, and whether it answered, from one read-only request to its own loopback address (GET /api/ps on Ollama-compatible servers, GET /v1/models on OpenAI-compatible ones). Only /api/ps reports memory-resident models; /v1/models lists available or served models.	The inventory is always on. The loaded-models request is on by default and is turned off by the signed catalog setting local_models.loaded_model_probe: false, which leaves each server's loaded models unrecorded.	Configuration file contents and paths, beyond hashed keys. TCC clients named by path are reduced to the executable name, and TCC code requirements aren't read. The loaded-models request goes only to 127.0.0.1 or ::1, on a port the operating system shows the server listening on, with no credentials, no body and no redirects. It is never sent to a LAN address, and a server that asks for credentials is recorded as auth_required and not retried. Guard never calls a generate, chat or completion endpoint, never loads or unloads a model, and never reads model files, prompts or chats. A listed model name that isn't public, such as a private or organization repository, a path or a file name, never leaves the device: it is replaced with a hash keyed by the installation's private inventory salt, stable on that device and not comparable across devices. A harness's model endpoint URL is not copied, only that it is local and which runtime it names. On Linux and macOS, bounded listener-owner arguments identify only the script basename or top-level module in memory; arguments, executable paths, environment values and credentials from that lookup are never recorded or uploaded. Installation alone does not authorize a probe of an unattributed listener on a generic port.
Mcp gateway calls	Agent activity	Each MCP tool call an agent makes through the local Guard MCP gateway, counted per UTC day: the server's registry name or hashed mcp-server- label, the tool name escaped to printable ASCII, the agent harness, the gateway's decision (allowed, redacted, blocked, or ask_refused when a rule asked and the gateway refused) and the number of calls. The gateway's local call log is read from a saved position, so each call is counted once. For the same calls, a call-identity summary of the bearer token each carried, per day, server, harness and decision: how the gateway saw it (decoded, uninspectable, absent or not_visible), and for a decoded JWT the issuer's host, the scope names it held (at most 16, each printable ASCII of at most 96 bytes, never token-shaped), the scopes the catalog counts as excess, the expired and over-scoped flags, the subject class (user, client or unknown) and subject_digest: SHA-256 of the issuer and subject, which Guard Cloud keys per organization with HMAC-SHA256 on receipt and stores only as that mcp-subject- hash.	Only servers whose configuration runs the gateway are covered; a device with no gateway call log sends nothing. A device whose gateway made no calls sends one empty report a day, so Guard Cloud can tell no calls from no report.	The whole call log: arguments (even with log_arguments on), results, secrets and their redactions, tokens, the issuer URL beyond its host, audiences, the subject itself and the device-keyed subject hash, timing, the pinned server key, the configured server name, commands, URLs and paths.
Session steps	Agent activity	The ordered step list of an agent session: step kind, time, decision and rule names, including that a prompt was submitted. For the attack path (#697), an MCP tool call's server by registry name or hashed inventory label, a file step's class (credential, environment, ssh_key, config, source or other), a reference to the earlier step of the session that started the step (for a sensor exec, the hook's shell tool call that ran it, #1048), and whether the privacy tier withheld the step's detail.	Always on.	The prompt text: a prompt step records only that a prompt was submitted and whether it was blocked. File paths (only the class leaves the device), MCP server URLs, commands and configured names, including in an MCP tool's name (#1048). The command digests that link a sensor exec to its tool call stay in the local step store and are stripped before upload.
Prompt scanning	Human ai sharing	Prompt hooks scan the prompt a person submits to an AI tool for secrets and custom data identifiers, and block or redact it before it is sent. Attachments named in a prompt are checked for credential files.	Prompt hooks don't inspect the prompt or its attachments; the prompt goes to the AI tool unchanged.	The prompt text, always. Only rule names leave the device, in findings.
Browser extension	Human ai sharing	On AI sites only, the browser extension (Chrome, Edge and Brave; the Firefox build reports selection and paste, never upload) reports screenshot selection, image paste and upload, with the event kind, a SHA-256 digest of the image and the AI destination host.	guard monitor refuses browser events and doesn't listen for them.	Images, page content and browsing of non-AI sites.
Browser ai app use	Human ai sharing	Which AI web apps in the signed directory a person opens in the browser: per UTC day, the app ID, the page origin (https://host) and a count of top-level visits. The native host accepts exactly {kind, app_id, origin, day, count} and refuses anything else. Counts wait in the browser's session memory until the native host takes them, then in the Guard home until Guard Cloud accepts them; a day older than 7 days is dropped.	The native host refuses every ai_app_use message, nothing is counted or kept, and Guard Cloud refuses reports from the device.	URL paths, query strings, page titles, prompts, page content, and every site that isn't in the directory.
Browser ai app enforcement	Human ai sharing	The published Shadow AI policy acting in the browser: the extension's warning and block pages for AI web apps whose response is warn or block (block only with the policy's blocking opt-in). Each block page shown is logged by the native host as the finding ai_app_blocked_by_policy with the app ID, its category and state. "Request a review" on the block page keeps the app ID and the time it was asked for, which guard cloud sync uploads. The native host accepts exactly {kind, app_id, origin} for a block and {kind, app_id} for a review request.	The native host gives the extension no policy and refuses ai_app_block and ai_app_review_request, so nothing is warned, blocked, logged or kept; kept review requests are removed and Guard Cloud refuses the upload and the finding.	URL paths, query strings, page titles, the page's origin for a block, page content, anything typed, and whether a warning was shown or continued past.
Screenshot watcher	Human ai sharing	guard monitor --dir hashes new screenshots in the folder it watches, so an upload of the same bytes to an AI site can be recognised.	guard monitor doesn't scan the folder.	Screenshots and their file names; only digests are compared, locally.
Session content capture	Session content	Prompt hooks and tool hooks keep a redacted excerpt of the prompt, the tool input or the tool output (at most 2 KiB, secrets replaced) and guard cloud sync uploads it. Tool output is kept where the harness hands it to a post-tool hook: Claude Code, Codex, GitHub Copilot CLI (including the current VS Code Copilot target), Cursor, Gemini CLI and Cline (when Cline passes the result); Kimi Code Node provides only its shortened asynchronous preview (currently 2000 characters), which cannot withhold output; Qwen Code provides tool_response on reviewed classic/ACP dispatch paths, and only output Guard did not withhold is eligible for capture; not Windsurf, Kiro or Amazon Q, whose hooks Guard does not read output from. Reply hooks keep the agent's reply where the hook delivers it (Claude Code Stop, reading the latest assistant message from its transcript only when the payload lacks it; Codex Stop; Cursor afterAgentResponse; Gemini CLI AfterAgent; Windsurf post_cascade_response), and permission hooks keep the action a harness asked the person to allow (Claude Code and Codex PermissionRequest, Gemini CLI ToolPermission notifications) with a digest of the call ID; a Claude Code call that ran after its prompt is recorded as allowed.	Nothing is captured: hooks keep no text unless the tenant-wide opt-in or an escalation covering this device or session is in force.	Files, tool output Guard withheld or replaced, and any excerpt that still contains a recognised secret after redaction.
Windows security audit 4688	Agent activity	On Windows, when kernel process events are unavailable, the sensor reads process creation events (4688) from the Security log, only to attribute processes to AI tools. Enabling that audit policy makes Windows record every process's command line in the Security log for every reader of that log: a system-wide side effect, not a Guard upload.	Off unless the installer runs with -AuditProcessCreation -AcceptSystemWideAudit; by default the sensor uses kernel process events only.	Command lines of processes that aren't attributed to an AI tool.
Document label reader	Agent activity	When a process attributed to an AI tool opens a Word, Excel, PowerPoint or PDF file, or a file with an extended attribute the signed catalog names, the sensor reads the sensitivity label that is already stored in the file: the MSIP_Label properties in an Office file's docProps/custom.xml part, in a PDF's XMP packet, or in the named attribute (macOS and Linux). The open is counted in the data class the catalog's label_map maps the label to, and the data access report carries that class and a SHA-256 digest of the label ID per agent, with counts of opens whose file had no label, was rights-protected, or could not be read within the size, time and rate bounds. Reads are bounded (at most 1 MiB read from a file, 256 KiB of XML, a time limit and a catalog rate limit) and never parse or inflate the document body.	Off unless the organization sets privacy.document_labels in the signed catalog (recorded in Guard Cloud's audit as privacy.document_labels.enabled). Off means no file is read for a label and the data access report has no labels section.	Label display names (used on the device to match the catalog's map), file paths and file names beyond the existing hashed path_key, document text and every part of the file other than the label properties. A rights-protected file is not decrypted.
Ai account check	Agent activity	Which account an AI tool is signed in to, from the tool's own local account file: Claude Code's ~/.claude.json, Codex's auth.json, Gemini CLI's google_accounts.json, Cursor CLI's cli-config.json and GitHub Copilot's sign-in files. Only the email domain, an organization, workspace or host ID and the plan name are read, and they are compared on the device with the allowed domains and tenants in the signed catalog's ai_account_policy. A personal or other-organization account raises the finding ai_tool_signed_in_to_non_company_account with the harness, personal or foreign, what it rests on, and the email domain or a keyed hash of the tenant ID.	Off unless the signed catalog has an ai_account_policy section: nothing is compared and no finding is raised. guard ai-accounts still shows the result on the device.	Email addresses (the part before the @ is dropped as the file is read), raw organization and tenant IDs, names, tokens and keys. Codex's ID token is decoded for its public claims only; its access and refresh tokens, and any token in the other files, are never looked at. A sign-in kept in the OS keychain is never read, so it is reported as not visible.