What Gurd is
Rune Guard runs on employee laptops. It discovers the AI coding agents, local harnesses, MCP tools and browser-based AI applications in use, and monitors what they do and what they reach. Policy decides what is allowed, and Guard records evidence of what happened and why.
We monitor agents, not developers.
Guard reports what AI tools do:
- the credential files they read;
- the credential commands and screen captures they run;
- the tool calls they make.
What Gurd isn't
| Guard is not | Why |
|---|---|
| A replacement for your EDR | It does no malware, memory or ransomware detection. It complements the EDR you already run. |
| Only DLP | It watches agent processes, tools and permissions as well as data. |
| A box for your agent | Guard lets agents work and wards off the risks: freedom for agents, security for data. |
If you want an environment where your agent can roam freely but with receipts, see Rune Box.
Components
| Component | What it does |
|---|---|
| Guard agent | Runs on the device (macOS and Linux; Windows is not yet qualified). Collects OS events and harness hook events, attributes them to an AI tool, and turns them into findings. |
| Guard Cloud | The management and policy service. Receives findings from enrolled devices and distributes signed policy. Self-hosted; see guard-cloud.md. |
| Guard Console | The administrator web app, served from the same HTTPS origin as Guard Cloud's browser APIs. See console.md. |
Managed SaaS operated by Runeward Labs is a deployment goal. Both options use the same endpoint protocol and backend.
On the device
The agent watches what AI tools do. What ships today differs by platform:
| Signal | macOS | Linux | Windows (not qualified) |
|---|---|---|---|
| Process launches | Endpoint Security events through the eslogger bridge |
Process connector and /proc |
ETW, plus audit event 4688 (needs the command-line audit policy) |
| Credential file opens | Endpoint Security (same limits) | fanotify; opt-in read prevention, off by default | ETW, after the fact |
| Keychain or keyring | Endpoint Security (same limits) and security exec; the legacy SecurityServer path is unseen on macOS 14 to 26 |
secret-tool and kwallet-query exec |
Not collected |
| Screen capture | screencapture exec and permission changes (same limits), TCC scan |
Desktop portal requests, not whether the user allowed them; tested only in a container with a fake portal, not validated live | Not collected |
| AI service connections | lsof polling, which can miss short connections |
Opt-in eBPF, with DNS and TLS SNI; no retained live result | ETW TCP connection attempts and UDP datagrams to resolved AI endpoint addresses only |
| Prompts and tool calls | Harness hooks; Chrome-only extension, not yet qualified, under the human-to-AI sharing opt-in; doesn't prove screenshot provenance | Harness hooks; the same Chrome extension, built but not yet run with Chrome on a Linux desktop | Harness hooks, not yet run live in a harness |
By default collectors only observe. Enforcement comes from harness hooks and, on Linux, opt-in session freeze and read prevention. See Packages and device management and Known limits before relying on a signal.
Prompt content leaves the device only under the human-to-AI sharing or session content opt-in; see Privacy below. Harness hooks cover agents such as Claude Code, Codex, Copilot, Cursor and MCP tools. See hooks.md and mcp.md.
Guard attributes each event to an AI tool's process tree, using the code signature where it can, then interpreter arguments, then the executable name. The core rule is simple: anything a CLI agent's process tree reads can end up in the model context. So a credential read by that tree is the finding. Network flow metadata then adds evidence that data left the machine.
Note: Some parts of the architecture are not built yet, including mTLS enrollment, an ingestion queue, a columnar event store, an encrypted local store and general remote response. Today devices use signed Ed25519 requests, Guard Cloud uses PostgreSQL, and the agent keeps its state in files. See limits.md for current coverage.
How data flows
- The agent observes an AI tool's activity on the device.
- It turns the activity into a finding and attributes it to the tool.
- It sends findings and metadata to Guard Cloud over signed device requests.
- Guard Cloud stores them and serves them to the Guard Console.
- Guard Cloud signs tenant policy, and the agent verifies the signature before applying it.
Privacy
By default Guard monitors agents only and never reads a person's chats or prompts. It sends metadata such as rule, category, tool, device, user, time and a hashed path key. Raw file paths, prompt excerpts and screenshots stay on the device.
Two separate per-company opt-ins, both off by default, widen this:
- Human-to-AI sharing: secrets in prompts, and screenshots and images pasted or uploaded to AI sites.
- Session content: redacted excerpts of agent sessions. These can also be read through a time-bound, audited escalation for a critical incident, requested with a reason.
Turning an opt-in on is logged and visible to end users. Anyone at a device can see what is collected about them:
guard status --privacyRead the full statement at /trust/privacy/.
Trust boundaries
- A local user with admin rights can stop any user-space agent. Tamper detection reports this; it does not prevent it.
- Hook enforcement depends on the harness honoring hook results, so it is best effort.
- Findings describe what Guard observed. They never claim what an AI provider retained.
Next steps
- install.md: install the agent.
- deploy.md: packages, MDM, enrollment and retiring devices.
- scan.md: run the local assessment.
- approvals.md: approve risky agent actions.
Written from docs/positioning.md, docs/architecture.md at commit fb79778d02f0. Rune Guard is in early access.