Known limits: Cloud and Console

Device-side limits are in Known limits: devices and agents.

Sessions and investigation data

• Hook sessions and sensor sessions are separate. Session rules, taint and attack paths don't join them; the step timeline joins them for viewing only, and ambiguous cases stay unattributed.
• A harness payload without a session ID gets no session rules. Under the built-in taint rules, it fails closed: every egress call is denied and every publish asks.
• A call the user declined after ask isn't seen as blocked, and it still leaves taint labels.
• Untrusted input is classified by source, not content. Files from a cloned repo read later, pasted content and unlisted tools don't count.
• Cross-server MCP flow (cross_server_mcp_flow) shows that output from one MCP server came before a sensitive call on another, not that data moved between them. A tool counts as sensitive by its name only. Cline's MCP calls, tools without an mcp__, mcp_ or mcp: prefix and calls through the MCP gateway don't feed it.
• Cross-agent links join files by resolved path, so symlinks, hard links and renames aren't joined. Subagents sharing a session ID count as one agent.
• Untrusted pickle loads are seen only when the file is named in the command or in -c code, not when a script or notebook opens it. Only files an agent session downloaded or wrote after taking in untrusted content count, and a file moved or renamed after the download doesn't. The file is never read, so a harmless model and a malicious one look the same. The rule only reports.
• Attack paths are linked within one session from local history only. No path isn't proof that no chain happened, and predicted paths don't check that tools are installed.
• Session taint, attack paths, the rule history and the handoff ledger stay on the device and aren't uploaded to Guard Cloud.
• The timeline holds 512 steps per session and 128 sessions locally. guard timeline enqueue must run before upload; it isn't automatic.
• A hook tool step is an attempt. Only a sensor or span step shows a call ran.
• Only Claude Code identifies sub-agents in hooks, and those hooks are tested against fixtures, not a live release.
• Session replay uses the device clock to place steps before a detection, and links findings to steps by time, not causality.
• Replies are captured from Claude Code, Codex, Cursor, Gemini CLI and Windsurf only. No hook reports a person's answer to a permission prompt.
• Tool-output excerpts exist only where a post-tool hook receives output (not Windsurf, Kiro, Amazon Q or the Cline VS Code extension).
• Kimi Code supplies only a shortened asynchronous output preview, not the full result or an opportunity to withhold it. Qwen's reviewed classic/ACP output path has fixture coverage; unqualified dispatch paths do not gain output coverage from being installed.
• Remote agent-to-agent protocols are out of scope.

Model-assisted detection

• It is an optional, off-by-default word-statistics classifier, not a language model. Unfamiliar paraphrases are missed and benign text about credentials or uploads can be flagged.
• It judges tool output alone and can't compare it with the user's request.
• It runs on tool output in Claude Code, Codex, Cursor, Gemini CLI and Cline only, and can only warn.
• There is no loader for other on-device models.

Policy and rules

• Rule modes apply only to rules with a decision. The sensor never blocks, and credential exposure and prompt secret blocking are always enforced.
• Device rule simulation replays only what local history kept; that history is not uploaded. The Console's rule preview instead estimates changed rules from findings already stored in Guard Cloud. Findings contain no path, command, arguments or tool name, and actions that matched no rule left no finding. New or widened rules therefore have bounds or unavailable estimates, never evidence of zero impact. Only rule entries in hook actions, session rules, session taint and identity policy, and tuning exceptions, are replayed. Profiles and other changed sections, such as egress destinations, MCP tool access, custom data identifiers, encoded secrets and credential writes, are listed without counts.
• In the preview, device counts of 1 or 2 are withheld, and so are any finding counts that would let someone work them out.
• Policy profiles apply to hook decisions only. Profiles have no Guard Cloud authoring yet, and selection markers belong to the device's user.
• The policy language covers some catalog sections only; others stay in JSON. Conflicts are checked against the built-in catalog only.
• guard policy draft is a template matcher that never calls a language model. Drafted rules need a person to review them.
• Guard Cloud stores policy versions, checks drafts and publishes signed catalogs through administrator policy grants. Server signing separates author and publisher; local signing still requires an administrator to sign the exact prepared catalog. A preview estimates impact and does not publish, replay full device history or prove an endpoint applied the policy.
• Custom data identifiers apply in hooks only and match literally. Look-alike letters, paraphrase, encodings and images aren't understood, and text over 1 MiB per surface isn't scanned.
• guard policy remediate supports attack paths and rule detections only, and is a local administrator CLI with no Guard Cloud workflow.
• Remediation playbooks can only notify, repair hooks or set a safe value. They edit plain JSON only, and run automatically only while guard posture monitor --remediate is running.

Response and approvals

See Approvals.

• Devices pull commands on guard cloud sync; nothing is pushed. A command expires after at most 24 hours, and a device that never reconnects never acts.
• Devices refuse every command until an operator pins Guard Cloud's command key with guard cloud command-key.
• Results are what the device reports, not independent verification. A local administrator can release isolation, clear a kill switch or release a quarantine.
• Every command needs an administrator and a reason. Findings never trigger a response on their own.
• The kill switch stops future hook calls only. It doesn't stop actions already running, harnesses without a blocking hook, or activity after hooks are removed. The current user can clear it. It can be sent to one device, a device group or every device, and each device applies it on its next sync.
• Remote process kill needs catalog attribution, and the account running Guard must be able to signal or open the agent's processes. On Windows a protected process Guard can't open is neither attributed nor killed.
• Network isolation is tested live on Linux only, in containers. It needs root or Administrator, keeps DNS open, and doesn't survive a reboot until the next sync re-applies it.
• Cloud approvals depend on the installed hook. Removed hooks, fabricated metadata and actions already running are outside coverage, and structured modification is limited to Claude Code Write content.

Package detonation

• Detonation is opt-in, needs a Rune Box URL and Charter, and its results aren't uploaded or shown in the Console.
• Live Rune Box integration hasn't been qualified end to end.
• Guard can't see every isolation setting through the API; the operator must set them.
• The tracer is visible to the sample, which can detect it or wait it out. no_behavior_observed is never a safety verdict.
• Only Linux environments are supported.

Gurd Cloud

See Guard Cloud.

• Healthy means a recent authenticated report from the device, not independent attestation. Suspected tampering needs investigation; it isn't proof of compromise.
• Stale or missing inventory is unknown, not zero, and session counts are a lower bound.
• MCP tool definitions aren't uploaded, so they are unavailable in agent profiles.
• Findings carry a harness, not an install, so two installs of one harness on a device share findings.
• Agent risk is computed on request from what Guard Cloud holds and isn't stored, so there is no history or trend.
• Severity is a rule's typical worst case. It doesn't use asset value, exploit availability or third-party CVSS feeds.
• Identity providers: Okta and Entra ID connectors are read-only. Okta RSA keys and DPoP, Entra certificate credentials and national clouds aren't supported, and automatic owner matching is a weak device-name hint only.
• Platform connectors are a foundation only. No vendor connector (Copilot Studio, Agentforce, ServiceNow, Bedrock AgentCore, Vertex, Foundry) ships.
• Investigation guidance is generic per rule, references only what Guard Cloud holds, and isn't in exports.
• Export sends OCSF events to webhooks, Splunk HEC, Elasticsearch/OpenSearch, Datadog Logs, syslog, OTLP, AWS Security Hub and Amazon S3. Response rules also reach Microsoft Sentinel, Jira, ServiceNow, PagerDuty, Slack, Microsoft Teams and email. Datadog was tested against a mock only.
• The administrator audit log, device health events and inventory aren't exported, and older records aren't backfilled.
• Destination signing secrets are stored in the database, and destinations can point at any HTTPS host the server reaches.
• Revocation lists for updates are delivered by an administrator, not by Guard Cloud.

Console

See Console.

• OIDC single sign-on is tested against a fixture provider and, in an opt-in test, Keycloak; SAML only against signed fixtures; SCIM with Entra- and Okta-shaped requests. None has run against a live Okta or Entra ID tenant.
• The Console shows tenant-scoped metadata, not complete prompt or tool-call sessions. Missing evidence is shown as unavailable.
• Hook findings and local quarantine don't automatically become actions across your organization.
• Severity overrides are published through the administrator API, and their reason and author aren't shown in the Console.
• The operator console has local accounts with TOTP only, two fixed operator roles (platform_admin and support), no read-only operator, and isn't in the docker run evaluation image.

Privacy

See the privacy statement. We monitor agents, not developers.

• Human-to-AI sharing and session content are separate opt-ins, both off by default. They apply only where the device has the signed catalog; a device without one keeps everything off.
• Older Guard versions upload human-to-AI sharing findings regardless of the opt-in. Guard Cloud refuses those batches, so upgrade those devices.
• Escalation capture starts and stops on the device clock. Guard Cloud checks capture times against its own window.
• Status and finding metadata are restricted, but identifiers, host names and digests can still encode information. This is not universal DLP.

Device integrity, storage and updates

• Device signing keys are software keys (file, Keychain or Secret Service): exportable, with no hardware protection. Per-device mTLS isn't available.
• The findings log is plaintext JSONL, readable by the sensor's user. Without a Guard Cloud key, that user can rewrite unsynced records; with one, a user who can read the Guard home can forge later records.
• Stopping the sensor isn't detected by the log chain, only by missing sync and status reports.
• Health and tamper reports are testimony, not prevention. A local administrator can stop collection, forge self-reports or remove the package.
• Encrypted delivery is opt-in, and default packages don't enable native reports or uploads.
• Offline store recovery is never automatic, so a damaged store stays write-blocked until an operator acts.
• Control-file write notices are opt-in, local only and metadata only. They don't prove which process wrote a file or that an effective setting changed, and Windows has none.
• Update, rollback and uninstall are qualified on Linux and Windows, not macOS.

Performance

• Performance budgets are proposals, measured under synthetic workloads, not on busy developer machines. Measured overruns remain open.
• On Linux with --watch-mount, every open on a watched file system costs a little more, and the program that confirms an open succeeded adds a cost to every successful open on the system, watched or not. Without the kernel open prefilter, every open on the mount waits for the sensor.
• Load budgets are measured after the sensor has settled. Its first start after an install or upgrade costs more, once. On a quiet Windows laptop, a TCP storm with --network then cost the sensor about 2% of a core and stayed within the throughput budget.