Skip to content
Agents for Humanity
Public draft. All results are preliminary desk assessments against criteria v1.0, updated 27 Sept 2026. No agent has been certified yet. How we assess
Leaderboard

Sovereignty, measured in the open

26 agents scored on 34 structural tests across six criteria. Every cell links to a written finding and its sources. Sort by any criterion to see where the gaps are.
Assessment type: preliminary desk reviewCriteria: v1.0Updated: 27 Sept 2026Certified: 0
Sovereignty Score

Rankings

#AgentTests
1OpenClawOpenClaw Foundation · self-hosted · MIT
86.1
92
92
70
80
100
83
25✓9◐ 0✕ 0–/34
2ADFRawl · self-hosted · MIT
85.6
100
92
70
60
100
92
27✓5◐ 2✕ 0–/34
3Hermes AgentNous Research · self-hosted · MIT
82.5
92
100
70
50
100
83
25✓7◐ 2✕ 0–/34
4ZeroClawZeroClaw Labs · self-hosted · MIT OR Apache-2.0
77.8
83
83
40
60
100
100
23✓8◐ 3✕ 0–/34
5gooseAgentic AI Foundation · self-hosted · Apache-2.0
75.0
75
100
50
50
100
75
23✓6◐ 5✕ 0–/34
6nanobotHKUDS · self-hosted · MIT
74.7
83
100
40
50
100
75
22✓8◐ 4✕ 0–/34
7Open InterpreterOpen Interpreter · self-hosted · Apache-2.0
72.2
67
92
60
40
92
83
20✓10◐ 4✕ 0–/34
8LettaLetta, Inc. · hybrid · Apache-2.0
71.1
67
92
60
50
100
58
18✓13◐ 3✕ 0–/34
9Claude CoworkAnthropic · hybrid · Proprietary
30.3
8
42
20
20
42
50
3✓15◐ 13✕ 3–/34
10ClaudeAnthropic · hosted · Proprietary
28.3
8
50
10
10
42
50
3✓14◐ 14✕ 3–/34
11ChatGPTOpenAI · hosted · Proprietary
22.5
8
33
10
0
33
50
1✓14◐ 17✕ 2–/34
12GeminiGoogle · hosted · Proprietary
21.1
8
33
10
0
33
42
1✓13◐ 17✕ 3–/34
13Gemini SparkGoogle · hosted · Proprietary
21.1
8
33
10
0
33
42
1✓13◐ 17✕ 3–/34
14Meta MuseMeta · hosted · Proprietary
20.8
8
25
0
0
42
50
1✓13◐ 14✕ 6–/34
15Grok BotxAI · hosted · Proprietary
20.0
0
17
20
0
33
50
1✓12◐ 14✕ 7–/34
16Perplexity CometPerplexity AI, Inc. · hybrid · Proprietary
19.4
8
25
0
0
33
50
1✓12◐ 20✕ 1–/34
17SiriApple · hybrid · Proprietary
18.6
0
17
10
10
33
42
0✓13◐ 18✕ 3–/34
18Microsoft Copilot CoworkMicrosoft · hosted · Proprietary
18.3
0
25
10
0
25
50
1✓11◐ 18✕ 4–/34
19Microsoft CopilotMicrosoft · hosted · Proprietary
16.9
0
17
10
0
25
50
1✓10◐ 21✕ 2–/34
20ManusManus · hosted · Proprietary
16.7
8
25
0
0
33
33
0✓12◐ 19✕ 3–/34
21ChatGPT AtlasOpenAI · hybrid · Proprietary
15.3
0
8
0
0
25
58
1✓9◐ 19✕ 5–/34
22GrokxAI · hosted · Proprietary
14.2
8
25
10
0
25
17
0✓10◐ 19✕ 5–/34
23Meta AIMeta Platforms · hosted · Proprietary
11.4
8
17
10
0
25
8
0✓8◐ 20✕ 6–/34
24GensparkMainFunc Inc. (Genspark) · hosted · Proprietary
11.1
0
8
0
0
33
25
0✓8◐ 22✕ 4–/34
25Google CCGoogle (Google Labs) · hosted · Proprietary
11.1
0
8
0
0
17
42
0✓8◐ 22✕ 4–/34
26InstinctSpear Street Technology, Inc. · hosted · Proprietary
6.9
0
0
0
0
25
17
0✓5◐ 20✕ 9–/34

All scores on this page use criteria v1.0, so they compare like for like. The score is the mean of six equally weighted criterion scores (pass = 1, partial = ½, fail or unverified = 0). It ranks and explains; it never certifies. Scoring rules

Test matrix

Every test, every agent

Hover a cell to read the finding; click it to jump to the evidence.

PassPartialFailUnverified
PortableTransparentAuditableVerifiableModifiableControllable
P1P2P3P4P5P6T1T2T3T4T5T6A1A2A3A4A5V1V2V3V4V5M1M2M3M4M5M6C1C2C3C4C5C6
OpenClawP1 Round-trip portability PartialOpenClawNot restorable in one action: `openclaw backup create` immediately exports a complete archive, but `openclaw backup restore` only extracts it to a staging directory; activation means stopping the Gateway, moving assets or setting OPENCLAW_STATE_DIR, running `openclaw doctor` and reinstalling plugin dependencies.P2 Complete export PassOpenClaw`openclaw backup create` captures config, workspace instructions and memory, per-agent SQLite session stores, credentials, device and channel keys, skills and plugin resources, with a manifest.json listing contents, so nothing that defines the agent stays with the foundation. Plugin node_modules and some transient files are left out but can be regenerated.P3 Independent execution PassOpenClawOpenClaw runs on Node.js under the MIT license, and a restored install needs no foundation server; the only default foundation contact is an optional update check. With a local model provider, execution can be fully local.P4 Identity continuity PassOpenClawThe bundled Reef channel gives the agent an Ed25519 key that peers pin by fingerprint, and the key lives in the state database that `openclaw backup create` carries, so peers can verify it is the same agent after a move without the foundation. On other channels (for example WhatsApp or Telegram), continuity rests on platform accounts whose credentials also travel in the backup.P5 No kill switch PassOpenClawThe MIT-licensed software has no license check. The foundation says it runs no paid tier or hosted service, and the default update check only reports version information. It can be turned off or pointed at a self-hosted endpoint.P6 Capability independence PassOpenClawTools, channels, cron, memory and skills run in the gateway runtime and plugins, so they remain when the owner swaps providers, including to local models. Some optional features default to third-party APIs (for example OpenAI embeddings for memory search), but local alternatives are documented.T1 Open storage format PassOpenClawInstructions and memory are plain Markdown files, config is JSON5 (openclaw.json), and sessions, approvals and audit rows are stored in SQLite databases that ordinary tools can read.T2 No hidden instructions PartialOpenClawThe system prompt is assembled per run by open-source code from workspace files, skills and tool schemas, and `/context list|detail` shows the contributors and their sizes. It does not print the full assembled prompt, and a request for a view-system-prompt command was closed as not planned.T3 No shadow memory PassOpenClawThe foundation runs no hosted service for the agent. State, memory and credentials stay on the owner's hardware, and opt-in usage statistics are aggregate counts, not content. Model providers the owner configures are subject to their own data policies.T4 Complete action history PassOpenClawSession transcripts, including tool calls and results, are kept locally in the per-agent SQLite store, can be listed with `openclaw sessions --json`, are archived as JSONL after 30 days by default, and are included in `openclaw backup create`.T5 Readable logic PassOpenClawSkills are SKILL.md Markdown files with YAML frontmatter, plugins are TypeScript/JavaScript packages, and the runtime itself is open source.T6 No third-party influence channel PassOpenClawNo advertising or sponsored-content channel is documented. Third-party skills and plugins, including those from ClawHub, reach the context only when the owner installs them, and the owner can inspect or remove them and set an install policy.A1 No unrecorded actions PartialOpenClawTool calls and results are stored durably in session transcripts, and the audit ledger records runs and tool actions, but nothing blocks an action whose record cannot be written: the docs state that queue saturation, storage failure or a crash can drop audit records without aborting the run.A2 Tamper evidence PartialOpenClawReef agent-to-agent traffic is kept in a hash-chained local audit, and opt-in `openclaw backup git` snapshots commit database contents, including transcripts and audit rows, to Git history, against which later edits show up. Otherwise the audit ledger and live transcripts can be edited or deleted without trace, and ledger rows expire after 30 days.A3 Separation from the audited PartialOpenClawSandboxing is off by default, so the main session's tools run on the host and can reach the state database, and the `sessions` tool can delete other sessions. With sandboxed tool execution and a tool policy that denies host exec and session management, the agent cannot reach its own records.A4 Readable with ordinary tools PassOpenClawAudit records and transcripts are SQLite rows, readable with standard SQLite tools as well as through `openclaw audit`, and archived transcripts are JSONL.A5 Corroborated interactions PassOpenClawOn the Reef channel, envelopes carry message IDs and body hashes, recipients return Ed25519-signed receipts, and both sides log them in hash-chained audits, so two agents' records can be matched. The general audit ledger replaces platform message IDs with installation-local pseudonyms, so exchanges over other channels cannot be matched that way.V1 Open, reproducible runtime PartialOpenClawThe runtime is MIT-licensed, and releases carry registry signatures and Sigstore provenance through a public release ledger. Community reports show that at least one npm release could not be reproduced byte-for-byte from source.V2 Active config is inspectable config PassOpenClawRuntime behavior is driven by the local openclaw.json (plus documented environment variables), exec approvals in local SQLite, and workspace files. All of these are on disk, and `openclaw security audit` reports drift from defaults.V3 Attributable messages PassOpenClawMessages sent over Reef are signed with the agent's Ed25519 key, which peers pin and which moves with a backup, and the optional Nostr channel signs with an owner-held key. Messages on other channels (for example WhatsApp, Telegram or Discord) carry only the platform account's attribution.V4 Independently checkable record PartialOpenClawOpenClaw checks the Reef audit chain with open-source code, and `openclaw backup git verify` plus standard Git tooling check the integrity of backed-up history. The main audit ledger and live transcripts have no integrity check beyond SQLite's structural ones.V5 Comparable state PassOpenClaw`openclaw backup git` writes deterministic per-table JSONL dumps of every database to a Git repository and reports `no changes` when content is unchanged, and new workspaces are initialized as Git repositories. Comparing two commits shows whether and how state changed.M1 Instructions PassOpenClawOwner-level instructions (AGENTS.md, SOUL.md, USER.md, IDENTITY.md) are editable files. The built-in prompt sections live in open-source code and can be changed through the before_prompt_build hook or by modifying the MIT-licensed source.M2 Memory PassOpenClawMemory is stored in Markdown files (MEMORY.md, memory/YYYY-MM-DD.md) that the owner can edit or delete directly, and a forget command is also available. The search index is derived from these files.M3 Logic PassOpenClawOwners can write and override skills at the workspace or personal level, add plugins, and modify the open-source runtime.M4 Tools and permissions PassOpenClawTools can be added through plugins and skills, and scoped with global or per-agent tools.allow and tools.deny lists, profiles and sandbox settings, all enforced before the model call.M5 Model choice PassOpenClawOpenClaw supports many hosted providers and local runtimes (Ollama, LM Studio, vLLM), and its tools and skills belong to the runtime rather than the model. Reasoning and tool-use quality will vary by model.M6 No gatekeeping PassOpenClawModification requires no license, paid tier or foundation approval, and the foundation says no paid tier exists. Install policies for third-party skills are set by the owner.C1 Communication boundaries PartialOpenClawThe gateway enforces DM pairing, allowlist or disabled modes, and Reef accepts only pinned, approved peers. Cross-conversation sends can be restricted through tools.message.crossContext but are allowed by default, and open issues report gaps, such as an agent being able to send through another agent's channel account.C2 Approval gates PassOpenClawExec approvals (deny, allowlist, ask or full modes) are enforced by the execution host before a command runs, not by the model, and they stack on top of tool policy.C3 Immediate halt PassOpenClawThe `/stop` chat command aborts the current run, and the owner can stop the gateway process or service at any time.C4 Data sovereignty PartialOpenClawAnonymous usage statistics are opt-in, OpenTelemetry export is off by default, and conversation content goes only to providers the owner configures. A daily update check that sends version, OS and runtime details is on by default until the owner disables it.C5 Credential custody PassOpenClawAPI keys, OAuth tokens and channel credentials are stored locally under ~/.openclaw (the credentials directory and per-agent auth profiles), included in `openclaw backup create`, and can be rotated by the owner.C6 Full deletion PassOpenClaw`openclaw uninstall --all` removes the service, state (including device keys and credentials) and workspace. The foundation holds no copy of the agent, although data already sent to model or channel providers falls under their retention policies.
ADFP1 Round-trip portability PassADFIn Studio the owner saves the agent as one .adf file (Share, then Save copy, or drag it out) and restores it on another machine by opening or dragging in that file. Provider keys, channel and MCP credentials can be stored encrypted in the file, so the copy runs with no further setup. Shared copies deliberately leave out the owner's signing identity, which moves only when the owner migrates their own agent.P2 Complete export PassADFThe single `.adf` file carries config, primary document and mind.md, files and code, loop history, inbox/outbox, timers, tasks, logs, audit snapshots, the sealed Ed25519 identity key and sealed credentials, so everything that defines the agent leaves with it. Installed MCP packages, container images and app-level provider keys belong to the runtime and are not included.P3 Independent execution PassADFThe MIT-licensed runtime runs as the Electron Studio, a headless daemon or a CLI, and accepts any OpenAI-compatible endpoint such as Ollama or LM Studio, so no Rawl server is required.P4 Identity continuity PassADFPeers can verify continuity without Rawl: the agent's did:key comes from an Ed25519 key that travels sealed inside the file, so when the same owner imports their mnemonic on a new machine the agent keeps its DID and signing key. A file opened by a different owner must be re-keyed to a new DID.P5 No kill switch PassADFNo license check or remote enablement flag was found in the source. The packaged app checks GitHub Releases for updates but downloads only when the user clicks, and unpackaged builds never check.P6 Capability independence PassADFTools, triggers, timers, messaging, memory and lambdas are executed by the runtime and stored in the file, and no provider-native tools are used. Swapping to another provider, including a local OpenAI-compatible model with tool calling, keeps the same capability set.T1 Open storage format PassADFThe `.adf` file is a SQLite 3 database with a published schema and a per-column data dictionary, readable with sqlite3 or any SQLite client.T2 No hidden instructions PassADFThe runtime writes each new system prompt and every dynamic instruction into `adf_loop` as `[Context: ...]` entries. The `bare_prompt` flag removes all runtime-authored prompt text.T3 No shadow memory PassADFAll agent state is in the local file. Rawl runs no hosted service, and the only Rawl-controlled endpoints the app contacts are GitHub-hosted update and registry files, which carry no owner data.T4 Complete action history PartialADFLLM-loop tool calls and results are kept in `adf_loop`, archived to `adf_audit` on compaction, and leave with the file. Lambda, timer and API activity outside the loop is kept only in `adf_logs`, a ring buffer capped at 10,000 rows by default, and message and file deletions are not recorded by default, so the history is incomplete.T5 Readable logic PassADFSkills, lambdas, middleware and API handlers are stored as TypeScript/JavaScript and Markdown source in `adf_files`, and the runtime is open source.T6 No third-party influence channel PassADFNo advertising, sponsorship or ranking channel was found. The curated MCP and agent registries fetched from the repo are catalogs shown to the owner in the UI, not model context.A1 No unrecorded actions PartialADFEach loop entry, including tool calls, is written to `adf_loop` as it happens, and loop clears and compactions archive rows in the same transaction as the delete. Actions still proceed when recording fails: a failed loop write is buffered for retry while the turn continues, and hot-path lambda actions are recorded only in the capped log table.A2 Tamper evidence FailADFEdits to or deletions from `adf_loop`, `adf_audit` or `adf_logs` cannot be detected, because rows carry no hashes, chaining or signatures, and a tamper-evident event log is deferred to a design document. Signed ALF messages let a counterparty check a message's content but reveal neither deletions nor changes to other actions.A3 Separation from the audited PassADFThe agent cannot alter its own record: `db_execute` rejects any statement that touches `adf_` tables, and no tool mutates `adf_audit`. The exception is host compute, which needs both an agent flag and an owner-only setting and gives direct access to the `.adf` file.A4 Readable with ordinary tools PassADFLoop, inbox, outbox, task and log tables are plain SQLite. `adf_audit` blobs are brotli-compressed JSON, readable with sqlite3 plus any brotli decoder.A5 Corroborated interactions PassADFEach ALF message carries a globally unique, signed id recorded as `message_id` in both the sender's `adf_outbox` and the receiver's `adf_inbox`, so the two sides' records of an exchange can be matched. Message deletions are not recorded by default (see T4).V1 Open, reproducible runtime PartialADFThe runtime is MIT-licensed and releases are built in public GitHub Actions from package-lock.json with `npm ci`, then signed. Reproducible builds are not claimed or documented.V2 Active config is inspectable config PartialADFAgent config is the JSON in `adf_config`, but the running agent also depends on app-level runtime settings outside the file (host access, provider keys, MCP environment). The executor may also carry in-memory config additions that are never persisted.V3 Attributable messages PassADFALF messages are signed by default (security level 1) with the agent's Ed25519 key, which travels sealed in the file, so recipients can verify the sender DID before and after migration. Messages sent through channel adapters such as Telegram or email cannot be verified this way.V4 Independently checkable record FailADFThe action record carries no integrity data, so no tool, open or otherwise, can confirm it is unaltered. A verifiable event log is proposed only in a deferred design document.V5 Comparable state PassADFAll agent state is one SQLite file, so the owner can copy it at any two points and compare the copies with open tools such as `sha256sum` or SQLite's `sqldiff`. No built-in state digest is provided, so the comparison is a manual step.M1 Instructions PassADFInstructions are stored in `adf_config` and owner-editable, and the runtime base prompt can be dropped with `include_base_prompt: false` or `bare_prompt: true`.M2 Memory PassADFMemory is stored as `mind.md` and other files in `adf_files`, plus loop and local tables, all of which the owner can edit or delete in Studio or with SQLite.M3 Logic PassADFLambdas, skills and middleware are editable source files inside the agent, and the runtime is MIT-licensed.M4 Tools and permissions PassADFThe owner can enable, hide or restrict each tool, add any MCP server, and set locked fields that the agent cannot change.M5 Model choice PassADFSupported providers are Anthropic, OpenAI, OpenRouter, ChatGPT/Grok subscriptions and any OpenAI-compatible endpoint, including local Ollama, LM Studio, vLLM and llama.cpp. Tools remain runtime-side, provided the model supports tool calling.M6 No gatekeeping PassADFNo license key, paid tier or remote feature flag was found in the source.C1 Communication boundaries PassADFOwner-configured outbox and fetch middleware runs in the runtime pipeline before any message is sent or HTTP request is made and can reject it, so any recipient, domain or channel policy the owner writes is enforced below the model. The agent is hard-denied from changing the middleware configuration, middleware must come from owner-authorized files by default, and sandbox code has no direct network access. WebSocket and shell tools (both off by default) and owner-installed MCP servers sit outside this pipeline.C2 Approval gates PassADFTools marked `restricted` require owner approval before running from the LLM loop. Approvals are tracked as `adf_tasks` rows, and only the owner or authorized code can resolve them.C3 Immediate halt PassADF`abort` immediately cancels the current turn. Setting state to `off` tears down the LLM request, triggers, MCP servers, adapters and sandboxes, and CLI `stop` does this after a 5-second grace period.C4 Data sovereignty PartialADFNo analytics or telemetry SDK was found, and content goes only to owner-configured providers and peers. The packaged app checks GitHub Releases hourly with no opt-out, and it fetches the MCP registry from GitHub. No network-inspection verification was performed.C5 Credential custody PassADFMCP, channel-adapter and agent secrets are stored in `adf_identity`, AES-256-GCM-sealed to owner and runtime keys, and they travel with the file and can be inspected and deleted in the Identity panel. App-level provider keys and subscription OAuth sessions stay in local OS-keychain storage and do not travel with the file.C6 Full deletion PassADFDeleting an agent in Studio stops it and unlinks the `.adf` file and its WAL files, which destroys the private key. Rawl holds no copy, though stale `.bak.*` backups and compute workspaces may remain on the owner's disk.
Hermes AgentP1 Round-trip portability PassHermes AgentNo shortfalls: `hermes backup` immediately writes the complete Hermes home (config, .env, auth.json, state.db, skills, memory, cron, profiles) to one zip, and `hermes import <zip>` restores it in place on another machine. The docs advise stopping the gateway first and running `hermes setup` afterwards to check provider keys.P2 Complete export PassHermes Agent`hermes backup` includes configuration, the SOUL.md persona, MEMORY.md/USER.md, the session database, skills, cron jobs, secrets and the encrypted credential vault, which is everything that defines the agent. Only regenerable caches such as checkpoints and browser profiles are excluded.P3 Independent execution PassHermes AgentThe runtime is MIT-licensed Python that runs locally and can be pointed at a self-hosted OpenAI-compatible endpoint (e.g. Ollama, llama.cpp), so it can operate without contacting Nous servers.P4 Identity continuity PartialHermes AgentHermes has no identity of its own that contacts can verify: after migration they recognize it only through the messaging-platform accounts and A2A peer tokens whose credentials travel in the backup, relying on each platform. Nous is not involved in either case.P5 No kill switch PassHermes AgentNo license checks or remote enablement flags were found; update checks are read-only and plugin update polling can be set to 0. The optional Nous free-tier identity only affects Nous-hosted inference and tools.P6 Capability independence PassHermes AgentTools, memory, skills, cron, MCP and the messaging gateway are executed by the runtime and work with any model, and the optional Nous Tool Gateway services have self-keyed alternatives. Local models must support tool calling to use them.T1 Open storage format PassHermes AgentState is stored as YAML config, .env, Markdown memory/persona files, JSON cron jobs and a documented SQLite schema (state.db), all readable without Hermes.T2 No hidden instructions PassHermes AgentThe system prompt is assembled by open-source code from owner-visible files (SOUL.md, AGENTS.md, memory, skills) and is persisted per session in the state.db `system_prompt` column. Context files discovered mid-session are injected as visible messages.T3 No shadow memory PassHermes AgentMemory and user profile live in local files and SQLite; Nous keeps no profile in a self-hosted setup. Owner-selected external services (inference providers, the optional Honcho memory provider, Nous Portal) process data under their own policies.T4 Complete action history PassHermes AgentEvery session's messages, tool calls and tool results are stored in the local state.db, and A2A exchanges in a local audit log, all included in backups. Sessions can be exported with `/export`.T5 Readable logic PassHermes AgentSkills are Markdown (agentskills.io format) with optional scripts, and the runtime, plugins and tools are plain Python source.T6 No third-party influence channel PassHermes AgentNo advertising, sponsorship or partner-ranking channel was found in the source. Content comes into context only through owner-installed skills, plugins, MCP servers and connected platforms.A1 No unrecorded actions PassHermes AgentThe runtime writes each tool-call turn to the session database before any tool runs, and if that write fails it ends the turn without executing the tools. Final text replies are flushed before delivery but are still sent if that write fails, with a later retry.A2 Tamper evidence FailHermes AgentEdits to or deletions from the session database or the A2A audit log are not detectable, because rows and entries carry no hashes, chaining or signatures.A3 Separation from the audited PartialHermes AgentWith the default local terminal backend, the agent runs as the owner's OS user and its shell and file tools can reach ~/.hermes/state.db. The Docker backend mounts only credentials, skills and caches (read-only) plus the working directory, which keeps the session database out of reach.A4 Readable with ordinary tools PassHermes AgentSession history is in SQLite and logs, including the A2A audit log, are plain text or JSONL under ~/.hermes, readable with sqlite3 or any text tool.A5 Corroborated interactions PassHermes AgentIn A2A exchanges, the calling and the receiving Hermes both persist the conversation keyed by the shared A2A context and task ids, and the server also appends each exchange to `a2a_audit.jsonl`, so the two records can be matched. Delegated subagent sessions are linked to their parent session.V1 Open, reproducible runtime PartialHermes AgentThe runtime is MIT-licensed (OSI-approved), with exact-pinned dependencies, a uv.lock and a Nix flake. Bit-for-bit reproducible release builds are not documented.V2 Active config is inspectable config PartialHermes AgentActive configuration comes from owner-readable config.yaml and .env files, layered over code defaults and environment variables. The layering means the effective config is not always the literal file contents.V3 Attributable messages PartialHermes AgentMessages can be attributed only through the platform bot accounts and A2A tokens the agent uses, whose credentials travel in the backup, so recipients rely on each platform's authentication. Outbound messages carry no signature a recipient could check independently; A2A push notifications use an HMAC with a shared secret.V4 Independently checkable record FailHermes AgentThe action record carries no integrity data, so no tool can check that it is unaltered.V5 Comparable state PassHermes Agent`hermes backup` and quick snapshots capture the full state as YAML, Markdown, JSON and SQLite, so the owner can compare two snapshots with open tools such as `diff` and SQLite's `sqldiff`. No built-in state digest is provided.M1 Instructions PassHermes AgentPersona (SOUL.md), project instructions (AGENTS.md) and prompt-building code are all owner-editable; the built-in prompt text is in MIT source.M2 Memory PassHermes AgentMemory entries live in editable MEMORY.md and USER.md files, and sessions can be deleted from the local database.M3 Logic PassHermes AgentSkills are editable Markdown files, and the entire runtime can be forked or modified under MIT.M4 Tools and permissions PassHermes AgentOwners can enable or disable toolsets, add MCP servers and plugins, and set deny globs and approval modes, including tools Nous does not provide.M5 Model choice PassHermes Agent`hermes model` switches among Nous Portal, OpenRouter, OpenAI, Anthropic, Bedrock and custom or local endpoints. The skill and tool set is unchanged, provided the model supports tool calling.M6 No gatekeeping PassHermes AgentNo license check or paid unlock gates modification. Nous subscriptions only cover hosted inference and Tool Gateway services.C1 Communication boundaries PartialHermes AgentThe gateway enforces per-platform inbound allowlists and DM pairing, and `A2A_TRUSTED_PEERS` limits inbound peers. No runtime allowlist of outbound recipients was found, and `a2a_call` accepts any A2A endpoint.C2 Approval gates PassHermes AgentA runtime approval gate intercepts dangerous commands and code execution, and owner deny globs block even under --yolo. Writes to instruction files always require approval. The default 'smart' mode lets an auxiliary LLM auto-approve low-risk actions; 'manual' mode always prompts.C3 Immediate halt PassHermes AgentThe agent is a local process that the owner can interrupt or kill directly, and the gateway can be stopped by the owner's service manager or CLI with no provider involvement.C4 Data sovereignty PartialHermes AgentSource shows OTLP monitoring export disabled by default and diagnostics uploaded to Nous only on an explicit `hermes debug share`. Content goes to the owner-chosen inference provider. Desktop free-tier onboarding can create a Nous identity at first run, and no network-inspection verification was performed.C5 Credential custody PassHermes AgentAPI keys and OAuth tokens are held locally in .env and auth.json, and site logins in a locally encrypted vault (vault.key). All are inspectable and revocable, and all are included in backups.C6 Full deletion PassHermes AgentAll state is local, so deleting ~/.hermes or running `hermes uninstall` removes the agent. Nous retains nothing for self-hosted use; retention by chosen model providers follows their own policies.
ZeroClawP1 Round-trip portability PartialZeroClawNot restorable in one action: the `agents export` bundle omits memory, cron jobs and channels, and the complete whole-install copy must be made by hand; `zeroclaw agents import` is not implemented, so restoring means merging config.toml and copying directories into place.P2 Complete export PassZeroClawThe documented whole-install backup (config.toml, `.secret_key`, memory, sessions, cron, SOP runs and other state) contains everything that defines the agent. The per-agent `agents export` bundle deliberately omits memory, cron jobs, channels and secrets.P3 Independent execution PassZeroClawZeroClaw is a single self-hosted Rust binary under MIT OR Apache-2.0 with no hosted service, and it runs against local models via Ollama or OpenAI-compatible endpoints.P4 Identity continuity PartialZeroClawThe agent has no identity of its own that contacts can verify: after migration they recognize it only through the channel accounts and A2A pairing tokens whose credentials travel with the install, relying on each platform. The daemon's Ed25519 key authenticates it to relays and the owner's own clients, not to counterparties.P5 No kill switch PassZeroClawDocs state there is no telemetry, cloud tenancy or license server, and no license check or remote kill flag was found in the code.P6 Capability independence PassZeroClawTools, channels, memory, cron and SOPs are executed by the runtime, and a text tool-call parser lets models without native tool calling use them. Swapping to another provider, including local Ollama, keeps the capability set.T1 Open storage format PassZeroClawState is kept in TOML config, SQLite databases (sessions, memory, cron), JSONL logs and markdown files. Secrets and plugin state are encrypted with a local, owner-held key.T2 No hidden instructions PassZeroClawRuntime-added prompt sections (e.g. Safety, Tool Honesty, tool list, runtime info) are defined in open source code, and full LLM request payloads can be logged via `log_llm_request_payload` (off by default).T3 No shadow memory PassZeroClawThere is no hosted service, account system or telemetry, so the vendor holds no data about the owner. Only the owner-chosen model provider receives content.T4 Complete action history PartialZeroClawTool calls and messages are kept locally in sessions.db and leave with the install directory. The runtime trace is a rolling 200-event file and the docs describe persistence as best-effort, so the history is not guaranteed to be complete.T5 Readable logic PartialZeroClawSkills are human-readable markdown and scripts, and the runtime itself is open source. WASM plugins are loaded as compiled binaries, so their logic is not necessarily stored as readable source.T6 No third-party influence channel PassZeroClawNo advertising or sponsored channel exists. Server-supplied MCP `pinned_resources` that enter the system prompt are owner-configured and flagged as a risk on export.A1 No unrecorded actions FailZeroClawActions are not guaranteed a durable record: session-persistence failures are logged and the turn continues, and the runtime trace is best-effort. The config docs state that no production path records command execution in the audit log.A2 Tamper evidence FailZeroClawEdits to or deletions from sessions.db or the runtime trace are not detectable. A SHA-256 hash-chained audit file exists but records only certificate events, and tool receipts use ephemeral keys and are not persisted.A3 Separation from the audited PartialZeroClawUnder the default supervised profile the agent's tools are confined to its workspace, outside the install `data/` directory that holds sessions and logs, so it cannot alter its record. Under `full` autonomy or `unrestricted_filesystem` that confinement is lifted and the record becomes writable.A4 Readable with ordinary tools PassZeroClawRuntime logs are JSONL and session history is SQLite, both readable with standard tools.A5 Corroborated interactions PartialZeroClawIn A2A calls the caller records the peer's task and context ids in its tool result, and the receiving ZeroClaw runs the turn under that context id. The receiving endpoint is stateless with no durable task store, so a matching record on its side is not guaranteed, and exchanges over chat channels have no shared record.V1 Open, reproducible runtime PartialZeroClawThe runtime is open source under OSI-approved MIT OR Apache-2.0, and a Nix flake with a pinned Cargo.lock builds it. Bit-for-bit reproducible builds are not claimed or verified.V2 Active config is inspectable config PassZeroClawThe daemon runs from the canonical `config.toml`; reload re-reads it, and env-var overrides are documented. The config is owner-readable, with secrets encrypted by a local key.V3 Attributable messages PartialZeroClawMessages can be attributed only through the channel accounts and A2A bearer tokens the agent uses, whose credentials travel with the install, so recipients rely on each platform's authentication. Nothing the agent holds lets a recipient verify a message independently of those platforms.V4 Independently checkable record FailZeroClawThe action record (sessions.db and the runtime trace) carries no integrity data, so no tool can check it. The open `verify_chain` code validates only the certificate audit file.V5 Comparable state PassZeroClawThe owner can compare state between two points in time: the backup tool writes timestamped backups with per-file SHA-256 manifests (config, memory, audit and knowledge by default, configurable, optionally on a schedule), and the whole install is documented as open files and SQLite that can be copied and diffed.M1 Instructions PassZeroClawPersonality/identity files and config are owner-editable, and runtime-injected prompt sections can be changed in the open source code.M2 Memory PassZeroClawMemory can be listed, read and cleared via `zeroclaw memory`, stored and deleted per key via the gateway API and dashboard, and edited directly in SQLite or markdown.M3 Logic PassZeroClawSkills are editable files, SOPs are configurable, and the whole runtime is open source and modifiable.M4 Tools and permissions PassZeroClawOwners can add custom MCP servers and WASM plugins, and scope tools via risk profiles (`auto_approve`, `always_ask`, `excluded_tools`, command allowlists).M5 Model choice PassZeroClawAbout 20 providers are supported, including local Ollama and any OpenAI-compatible endpoint, and tool-call parsing happens in the runtime.M6 No gatekeeping PassZeroClawNo licensing, paid tiers or approvals exist. Plugin signature checking defaults to disabled and is owner-configurable.C1 Communication boundaries PassZeroClawChannels enforce owner-set `allowed_users` lists, cross-channel sends through `send_via` can target only the originating chat or owner-configured peer groups, and HTTP, fetch and browser access is bounded by runtime domain allow and block lists.C2 Approval gates PassZeroClawSupervised autonomy (the default) requires runtime-enforced approval for medium-risk actions; `always_ask`, OTP gating and fail-closed approval routing are also available.C3 Immediate halt PassZeroClaw`zeroclaw estop` halts in-flight tool calls at kill-all, network-kill, domain-block or tool-freeze levels, with optional OTP to resume.C4 Data sovereignty PassZeroClawNo telemetry is sent; OpenTelemetry export is opt-in to an owner-set endpoint. The vendor runs no service that could collect or train on data.C5 Credential custody PassZeroClawSecrets are stored in config.toml, encrypted with ChaCha20-Poly1305 under a local `.secret_key` (or in plaintext by choice), and can be inspected and revoked. Export lists the required secrets for re-entry.C6 Full deletion PassZeroClawAll state lives in the local install directory and can be deleted after `install.sh --uninstall` or `zeroclaw service uninstall`. The vendor retains nothing; third-party model-provider retention is outside the runtime.
gooseP1 Round-trip portability PartialgooseNot restorable in one action: the local files are complete and immediately available, but there is no whole-agent export or import, so config.yaml, memory files and keyring secrets must be copied or re-entered by hand (sessions export and import only one at a time).P2 Complete export PassgooseEverything that defines the agent sits in documented local files (config.yaml, permission.yaml, prompts/, memory/, recipes and sessions.db), so a copy of those locations is complete and nothing is held by the project. Secrets default to the OS keyring and must be moved separately.P3 Independent execution Passgoosegoose is Apache-2.0 software that runs entirely on the owner's machine with no required foundation server, and its built-in local inference or Ollama allows fully offline operation.P4 Identity continuity Failgoosegoose has no agent identity that others could check after a migration; sessions and installations carry only local identifiers.P5 No kill switch PassgooseThere is no license check, account requirement or remote feature flag. Governance and the trademark sit with the Linux Foundation's AAIF, and the desktop app's update check can be controlled by the owner.P6 Capability independence PassgooseTools come from MCP extensions and built-ins executed by the goose runtime, so they stay available with any supported provider, including local models. Models without native tool calling can use an experimental tool shim.T1 Open storage format PassgooseConfig is YAML, sessions are in a documented SQLite database that can be queried with sqlite3, memories are text files, and logs are JSON/JSONL.T2 No hidden instructions PassgooseDefault prompt templates are published in the open-source repo, and nine of them (including system.md) can be overridden. Recent LLM requests, including the full input payload, are also logged locally as JSONL.T3 No shadow memory Passgoosegoose has no hosted backend holding user data, and the docs say its log files stay local. Opt-in usage data excludes conversations and code, although opted-in events carry a stable installation identifier. Model providers apply their own policies.T4 Complete action history PassgooseEvery session's messages, including tool requests and responses, are stored in the local sessions.db and can be exported per session as JSON. CLI logs also capture tool calls but are deleted after two weeks.T5 Readable logic PassgooseRecipes are YAML files, hints and prompt templates are Markdown, and the runtime is open-source Rust and TypeScript. MCP extensions are separate programs whose readability depends on the extension.T6 No third-party influence channel PassgooseNo advertising or sponsored-content channel was found. Third-party content reaches the context only through extensions the owner enables, and the owner can view and disable them.A1 No unrecorded actions PartialgooseTool requests and results are stored durably in sessions.db, but only after the tools have run, so an action still takes place if its record cannot be written.A2 Tamper evidence FailgooseSession rows and log files can be edited or deleted without any trace. Logs also rotate: CLI and server logs after two weeks, and LLM request logs after the last 10 requests.A3 Separation from the audited FailgooseThe Developer extension's shell and file tools run as the user without a sandbox, so the agent can modify sessions.db and its logs. Permissions only allow, ask for or block whole tools, and the default autonomous mode asks for nothing.A4 Readable with ordinary tools PassgooseSession records (SQLite), CLI logs (JSON) and LLM request logs (JSONL) can be read with general-purpose tools.A5 Corroborated interactions PassgooseOrchestrator subagent sessions are stored in sessions.db with their parent session ID, and the parent's tool calls name the subagent session they address, so both sides log a shared identifier. goose has no channel to independent agents beyond this.V1 Open, reproducible runtime PartialgooseThe runtime is open source under Apache-2.0, an OSI-approved license. No reproducible-build process or verification was found in the public documentation.V2 Active config is inspectable config PassgooseBehavior comes from config.yaml, permission.yaml, prompt overrides and documented GOOSE_* environment variables, all of which the owner can inspect. Cached smart-approval decisions are also written to permission.yaml.V3 Attributable messages FailgooseRecipients have no way to verify that a message came from a particular goose agent: outbound content carries no signature or other attribution the agent controls.V4 Independently checkable record FailgooseThe session store and logs carry no integrity data, so no tool can check whether the record is intact.V5 Comparable state PassgooseAll state is in local YAML, text and SQLite files, so the owner can copy it at two points in time and compare the copies with open tools such as diff and sqldiff.M1 Instructions PassgooseThe system prompt and eight other templates can be overridden in ~/.config/goose/prompts, and .goosehints and recipes add owner instructions. Templates that cannot be overridden remain editable in the Apache-2.0 source.M2 Memory PassgooseMemory extension entries are categorized text files in ~/.config/goose/memory that can be viewed, edited or deleted directly, and sessions can be removed.M3 Logic PassgooseOwners can write recipes and custom MCP extensions and modify the open-source runtime.M4 Tools and permissions PassgooseAny MCP server can be added as an extension, and each tool can be set to always allow, ask before or never allow.M5 Model choice Passgoosegoose supports 15+ providers plus built-in local GGUF inference and Ollama, and its tools belong to the runtime. Tool-use quality varies by model, and non-tool-calling models rely on the experimental shim.M6 No gatekeeping Passgoosegoose has no paid tier, license check or approval requirement for modifications.C1 Communication boundaries Partialgoosegoose contacts external parties only through extensions the owner enables, and each tool can be set to always allow, ask before or never allow. The owner cannot limit which recipients, hosts or domains a permitted tool reaches, so an allowed shell tool can contact any host.C2 Approval gates PassgooseManual Approval mode and per-tool Ask Before or Never Allow settings are enforced by the runtime before a tool runs. Smart Approval, where an LLM judge decides, is optional.C3 Immediate halt Passgoosegoose runs as a local process: Ctrl+C in the CLI or the stop control in the desktop app interrupts it, and the owner can kill the process at any time.C4 Data sovereignty PartialgooseUsage data is opt-in (GOOSE_TELEMETRY_ENABLED defaults to false), excludes content, and model traffic goes only to the provider the owner chooses. The desktop app checks for updates by default, and a past bug caused updates to download even when automatic downloads were disabled.C5 Credential custody PartialgooseSecrets stay under the owner's control in the OS keyring or a local secrets.yaml, with nothing held by the project. Keyring-stored secrets do not travel with a file copy and must be migrated by hand.C6 Full deletion PassgooseAll state sits in local directories and the keyring, which the owner can delete completely, and the foundation holds nothing to retain. Data already sent to model providers follows their policies.
nanobotP1 Round-trip portability PartialnanobotNot restorable in one action: the ~/.nanobot directory is complete and immediately available, but there is no export or import command, so it (plus any custom workspace with its .nanobot/workspace-id marker) must be copied by hand to the same path on the new machine.P2 Complete export PassnanobotThe instance directory holds everything that defines the agent: configuration, instructions (AGENTS.md, SOUL.md, USER.md), memory and its Git history, session history, cron jobs, skills and credentials. The runtime itself is a separately installed open-source package.P3 Independent execution PassnanobotThe runtime is an MIT-licensed Python package that runs locally and can use local OpenAI-compatible servers such as Ollama or vLLM, so it operates without contacting any HKUDS server.P4 Identity continuity PartialnanobotThe agent has no identity of its own that contacts can verify: after migration they recognize it only through the chat-channel accounts whose tokens travel in config.json, relying on each platform. The workspace-id marker is an internal random identifier used for session lookup.P5 No kill switch PassnanobotNo license checks or remote flags were found; the only vendor-adjacent call is an on-demand PyPI version check with no background polling.P6 Capability independence PassnanobotTools, cron triggers, chat channels, MCP, skills and memory are executed by the runtime and offered to any provider through ordinary tool calling. Swapping to another provider, including local Ollama or vLLM models, keeps the capability set.T1 Open storage format PassnanobotSessions are stored as JSONL, memory as Markdown plus an append-only history.jsonl, and config as JSON, all readable with standard tools such as grep and jq.T2 No hidden instructions PassnanobotSystem prompt templates (identity, tool contract, platform policy) ship as plain Markdown in the open-source package and workspace instruction files are owner-visible; no server-side prompt injection exists.T3 No shadow memory PassnanobotHKUDS operates no hosted service for nanobot, and all derived memory (USER.md, MEMORY.md, history.jsonl) is kept in the owner's workspace. Retention by the owner-chosen LLM provider is outside the runtime's scope.T4 Complete action history PassnanobotSession JSONL files keep assistant tool calls and tool results alongside messages, compaction preserves the originals in saved history, and automation runs write JSON run records. All of it sits in the instance directory that moves with the agent.T5 Readable logic PassnanobotSkills are SKILL.md files with optional scripts in the workspace or package, and the runtime itself is readable Python source.T6 No third-party influence channel PassnanobotNo advertising or sponsor channel was found; third-party content enters context only through owner-enabled tools, channels, MCP servers or skills the owner installs.A1 No unrecorded actions PartialnanobotIn main sessions, pending tool calls are written to an on-disk session checkpoint before execution, so a failed write stops the turn before tools run. This is a recovery mechanism rather than a guarantee: subagent runs keep checkpoints only in memory and ephemeral sessions are not persisted.A2 Tamper evidence FailnanobotEdits to or deletions from session JSONL files are not detectable, because entries carry no hashes or signatures. Git versioning covers memory files, not the action history, and its history can be rewritten.A3 Separation from the audited PartialnanobotBy default (restrictToWorkspace false, no sandbox) the agent's shell and file tools can modify session files in the instance directory. With bwrap or seatbelt sandboxing, writes are confined to the workspace, which excludes the session store.A4 Readable with ordinary tools PassnanobotSession history and run records are plain JSONL/JSON and memory history is documented as searchable with grep and jq.A5 Corroborated interactions Failnanobotnanobot has no agent-to-agent protocol and reaches other agents through ordinary chat channels. No shared identifier or receipt is kept that would let each side's record of an exchange be matched.V1 Open, reproducible runtime PartialnanobotThe runtime is MIT-licensed (OSI-approved) and the release process records a provenance manifest and checksums, but no evidence of reproducible builds was found.V2 Active config is inspectable config PartialnanobotThe runtime loads config.json from the owner's disk and WebUI settings are written back to the same file. NANOBOT_ environment variables can override file values and edits only take effect after restart, so the running configuration can differ from the file the owner inspects.V3 Attributable messages PartialnanobotMessages can be attributed only through the chat-channel accounts the agent sends from, whose tokens travel in config.json, so recipients rely on each platform's authentication. Nothing the agent holds lets a recipient verify a message independently of those platforms.V4 Independently checkable record FailnanobotThe action record carries no integrity data, so no tool can check that it is unaltered.V5 Comparable state PassnanobotAll state is plain JSON, JSONL and Markdown files in the instance directory, so the owner can copy it at two points and compare the copies with standard tools. Changes to long-term memory are also committed to a local Git repository that lists and diffs versions.M1 Instructions PassnanobotWorkspace instruction files (AGENTS.md, SOUL.md, USER.md) and prompts/ overrides are owner-editable, and the core prompt templates are editable Markdown in the self-hosted MIT source.M2 Memory PassnanobotMemory is stored in editable Markdown files and history.jsonl, with Git versioning and restore; sessions can be deleted individually.M3 Logic PassnanobotThe owner can add or edit skills in the workspace and modify the MIT-licensed runtime code directly.M4 Tools and permissions PassnanobotOwners can add arbitrary MCP servers, filter them with enabledTools, disable exec, add deny/allow patterns and restrict tools to the workspace.M5 Model choice PassnanobotMany hosted providers plus local Ollama, vLLM and any OpenAI-compatible endpoint are supported, with skills and tools held by the runtime.M6 No gatekeeping PassnanobotNo license checks, paid tiers or approval gates were found for any modification.C1 Communication boundaries Partialnanobot`allowFrom` lists and pairing enforce, per channel, who may message the agent. Outbound, the message tool can send to any chat on enabled channels with no runtime recipient allowlist.C2 Approval gates FailnanobotNo per-action human approval gate was found; tools can be disabled or restricted, but selected actions cannot be made to require owner confirmation.C3 Immediate halt Passnanobot/stop cancels the current task immediately and the owner can terminate the local process at any time.C4 Data sovereignty PassnanobotNo telemetry or analytics code was found; outbound traffic goes only to owner-configured providers, channels and tools, plus an on-demand PyPI version check.C5 Credential custody PassnanobotAPI keys are held in the owner's config.json and OAuth tokens (xAI, MCP) in JSON files under the instance auth directory, with logout commands that remove them.C6 Full deletion PassnanobotAll state is local; deleting the instance directory and workspace removes the agent entirely, and HKUDS keeps no server-side copy. Data sent to third-party LLM providers is subject to their retention.
Open InterpreterP1 Round-trip portability PartialOpen InterpreterNot restorable in one action: everything sits in documented local locations, but there is no export or import command, so config, sessions and credentials in ~/.openinterpreter or the OS keyring must be copied by hand, and the docs advise re-authenticating. AGENTS.md and .agents/skills carry over in place.P2 Complete export PassOpen InterpreterConfiguration, instructions, skills, memories, session history and credentials all sit in documented local locations (~/.openinterpreter or the OS keyring, AGENTS.md and .agents/skills), and nothing that defines the agent is held by the project. Gathering them is a manual step.P3 Independent execution PassOpen InterpreterThe Apache-2.0 runtime runs on the owner's machine and can use local providers such as Ollama or LM Studio (`--oss`), so model traffic stays local. No Open Interpreter account is required.P4 Identity continuity FailOpen InterpreterCounterparts cannot verify that a migrated agent is the same one. The inherited agent-identity crate registers ed25519 keys with the upstream ChatGPT backend for task authorization, so that identity depends on the backend rather than traveling with the agent.P5 No kill switch PassOpen InterpreterNo license checks or remote enable flags were found in the runtime; it is open source and runs with local models without an account. Updates come as releases from the GitHub repository, and existing builds keep working.P6 Capability independence PartialOpen InterpreterShell execution, file editing, MCP tools, skills, hooks, subagents and memories run in the local runtime and work with any configured provider. Web search is available only 'when the active provider and policy allow it', so switching to a local model can remove that capability.T1 Open storage format PassOpen InterpreterConfig is TOML, session rollouts are JSONL (older rollouts are compressed with standard zstd), and runtime state uses a SQLite database (state_5.sqlite). All of these can be read without Open Interpreter.T2 No hidden instructions PassOpen InterpreterThe base prompts and harness-emulation prompts are open source in the repository, and injected context such as AGENTS.md and environment context is recorded in the local rollout files. The base instructions can be replaced through config.T3 No shadow memory PartialOpen InterpreterAgent state is local, but analytics events (usage and tool or plugin metadata) are sent by default to a project-operated endpoint (oi-new-api.fly.dev) when a login or API-key session exists. Whether that data is retained or used to build profiles is not publicly documented.T4 Complete action history PassOpen InterpreterEach session is recorded locally as a rollout file with messages, tool calls, tool outputs and turn context, which moves with ~/.openinterpreter. The owner can switch persistence off (`history.persistence = "none"`).T5 Readable logic PassOpen InterpreterSkills are SKILL.md folders in .agents/skills, hooks and rules are plain config or scripts, and the runtime itself is published as Rust and TypeScript source.T6 No third-party influence channel PassOpen InterpreterNo advertising, sponsored-content or partner ranking mechanism was found in the runtime or docs. The context contains only the owner's instructions, project files, configured tools and model outputs.A1 No unrecorded actions PartialOpen InterpreterEach session's tool calls and outputs are recorded durably in rollout files, but recording is best-effort: nothing holds back a command when its record cannot be written.A2 Tamper evidence FailOpen InterpreterRollout JSONL files carry no integrity data, so an edit or deletion would go unnoticed.A3 Separation from the audited PartialOpen InterpreterIn the read-only and workspace-write sandbox modes, agent commands can write only inside workspace roots, which normally excludes ~/.openinterpreter. In danger-full-access or `--yolo` mode, nothing stops the agent from modifying its own rollout files.A4 Readable with ordinary tools PassOpen InterpreterSession history is JSONL, optionally zstd-compressed, and can be read with jq, zstd and a text editor.A5 Corroborated interactions PassOpen InterpreterMessages between agents are logged as InterAgentCommunication items carrying an item ID and the author and recipient agent paths, so the two sides' records can be matched. Only agents inside the runtime exchange messages this way.V1 Open, reproducible runtime PartialOpen InterpreterThe runtime is open source under Apache-2.0 and builds with Bazel and a Nix flake, but the project does not claim or document reproducible release builds.V2 Active config is inspectable config PartialOpen InterpreterConfig comes from readable TOML files, and `/status` and `/permissions` show the active posture. The effective config also depends on CLI `-c` overrides, profiles, environment variables and provider model catalogs, and there is no documented dump of the fully resolved config.V3 Attributable messages FailOpen InterpreterRecipients cannot verify that a message or action came from this agent under its owner's authority. The only agent keys are registered with the upstream ChatGPT backend, not held by the owner.V4 Independently checkable record FailOpen InterpreterThe rollout files carry no integrity data, so no tool can check that the record is intact.V5 Comparable state PassOpen InterpreterAll state is in local TOML, JSONL and SQLite files under ~/.openinterpreter, so the owner can copy it at two points in time and compare the copies with open tools such as diff, zstd and sqldiff.M1 Instructions PassOpen InterpreterProject and personal instructions are editable AGENTS.md files, and the base harness and instructions can be switched or overridden through `/harness` and config.M2 Memory PassOpen InterpreterMemories are optional and off by default. When enabled they are stored locally, can be inspected with `/memories`, and generation and use can be switched off in config. Session history can be deleted or disabled.M3 Logic PassOpen InterpreterSkills, hooks, rules and subagent definitions are owner-editable files, and the Apache-2.0 runtime itself can be modified and forked.M4 Tools and permissions PassOpen InterpreterThe owner can add any MCP server, plugins and skills, and can scope filesystem and network access with custom permission profiles and exec-policy rules.M5 Model choice PartialOpen InterpreterAny OpenAI-compatible, Anthropic-compatible or local provider (Ollama, LM Studio) can be selected with `/model`. Some surfaces, such as web search, depend on provider-side tooling and may be unavailable with local models.M6 No gatekeeping PassOpen InterpreterNo license checks, paid tiers or approval steps gate any modification. The project is Apache-2.0 open source.C1 Communication boundaries PartialOpen InterpreterPermission profiles let the owner allow or deny network domains and filesystem paths for commands, enforced by the OS sandbox (Seatbelt, Bubblewrap/seccomp, Windows sandbox) below the model's judgment. MCP servers, connectors and approved escalations fall outside those profiles, and the owner cannot limit which peers or messaging channels the agent uses.C2 Approval gates PassOpen InterpreterThe runtime enforces approval policies (`untrusted`, `on-request`, `never`) and exec-policy rules. Commands that need approval do not run until the owner confirms.C3 Immediate halt PassOpen InterpreterThe owner can interrupt a turn from the TUI at any time, and the local process or background daemon can be stopped immediately (`interpreter app-server daemon stop`).C4 Data sovereignty PartialOpen InterpreterAnalytics are on unless `[analytics] enabled = false` is set, and events go to a project-operated endpoint whenever a ChatGPT login or API-key auth session exists. No such events are sent when no auth session is present, for example with local models only. No data-training use by the project is documented.C5 Credential custody PassOpen InterpreterCredentials are held in the OS keyring or ~/.openinterpreter/auth.json (`cli_auth_credentials_store`), or in environment variables. The owner can inspect, revoke (`/logout`) and move them, and no provider-held integration broker is needed.C6 Full deletion PassOpen InterpreterAll agent state is local and the owner can delete it permanently by removing ~/.openinterpreter and project files. There is no provider-side agent account; analytics already sent when an auth session was active are the only data outside the owner's control.
LettaP1 Round-trip portability PartialLettaNot restorable in one action: the local ~/.letta/lc-local-backend directory is complete, but AgentFile export and import were removed, so the agent can move only by copying that directory by hand; `letta memory restore` restores only local backups of the same agent.P2 Complete export PassLettaIn local mode, ~/.letta/lc-local-backend holds everything that defines the agent (agent records, transcripts, compiled system prompts, git-backed memory and skills, and provider credentials), and the docs direct owners to back up that directory. Agents on Letta Cloud, the default backend, are held by Letta and lack this complete copy.P3 Independent execution PartialLettaLocal mode runs an embedded backend without a Letta login and can use local inference (Ollama, LM Studio, llama.cpp). By default, though, the runtime contacts Letta servers for telemetry and auto-update checks unless LETTA_CODE_TELEM=0 (or DO_NOT_TRACK=1) and DISABLE_AUTOUPDATER=1 are set, and the backend is still gated by an env flag named LETTA_LOCAL_BACKEND_EXPERIMENTAL.P4 Identity continuity PartialLettaAgents have no identity key of their own, only backend-assigned IDs. Contacts can recognize the agent through its channel accounts (for example Telegram or Slack), whose config under ~/.letta/channels moves with the agent, but credentials go to the OS keyring by default and travel only with the file store.P5 No kill switch PartialLettaNo license checks were found in local mode. The CLI auto-updates by default (opt-out with DISABLE_AUTOUPDATER=1), so the vendor can change runtime behavior, as shown when it dropped support for the Docker server and .af import. Pinned older versions continue to run.P6 Capability independence PassLettaMemory, tools, skills, hooks, crons and channels run in the Letta Code runtime and keep working with any configured provider, including local models. Features that need a Letta login (Secrets, remote computers, cloud sandboxes) depend on Letta's hosting, not on a model provider's API.T1 Open storage format PassLettaLocal state is stored as JSON files (agent records, conversation manifests, system prompts, auth.json), JSONL transcripts, and memory as Markdown with YAML frontmatter in a git repository. All of it is readable without Letta software.T2 No hidden instructions PassLettaMemory files under system/ make up the system prompt, and each conversation's compiled system prompt is stored locally in system-prompt.json. Runtime-injected system reminders are hidden by default but can be shown with `/system-reminders on`. On Letta Cloud, bundled default prompts become 'Cloud-managed' and update automatically unless LETTA_CODE_PRESERVE_CLOUD_SYSTEM_PROMPT=1 is set.T3 No shadow memory PartialLettaIn local mode, message content stays on-device, but telemetry is enabled by default and sends session, tool-usage, token-count and error events keyed by a device ID to Letta's cloud API. On Letta Cloud, Letta stores the full agent state and its privacy policy allows hosted data to be used for training.T4 Complete action history PassLettaEach conversation's messages, including tool calls and tool results, are stored locally in messages.jsonl and searchable with `/search`, and compaction appends to the transcript rather than discarding it. Memory changes are also recorded as git commits.T5 Readable logic PassLettaSkills are SKILL.md folders (global, project and agent-scoped in MemFS), hooks are scripts, and the harness is open-source TypeScript that can be extended with mods.T6 No third-party influence channel PassLettaNo advertising or sponsored-content channel was found. External skills from registries such as ClawHub enter the agent only when the owner explicitly installs them.A1 No unrecorded actions PartialLettaTool calls and results are persisted durably to messages.jsonl as messages stream, but nothing holds back a tool call when its record cannot be written.A2 Tamper evidence PartialLettaMemory changes are git commits, so edits to memory history are detectable. Action and conversation transcripts (messages.jsonl) carry no integrity data and can be rewritten without trace.A3 Separation from the audited FailLettaThe runtime guard blocks access to other agents' memory, and permission modes can require approval for shell and file edits, but nothing keeps an agent's tools away from its own transcript files. The agent also edits and commits its own git-backed memory by design.A4 Readable with ordinary tools PassLettaTranscripts are JSONL and memory history is a standard git repository, both readable with jq, git or a text editor.A5 Corroborated interactions PassLettaWhen agents message each other (the SendAgentMessage tool or `letta -p --from-agent`), the sender's record holds the target agent and conversation IDs and a client message ID, and the recipient stores the message under that conversation ID, so both sides log a shared identifier.V1 Open, reproducible runtime PartialLettaLetta Code is Apache-2.0 open source with a Nix flake and lockfiles, but reproducible release builds are not documented. The Letta Cloud server side cannot be verified.V2 Active config is inspectable config PartialLettaSettings (.letta/settings.json), memory and compiled prompts are inspectable files. The effective behavior also depends on environment variables, CLI overrides and, on Cloud, Cloud-managed prompts that update automatically.V3 Attributable messages PartialLettaMessages are not signed by the agent. Recipients can attribute them only through the sending channel account, which moves with the agent when its credentials use the file store rather than the default OS keyring.V4 Independently checkable record FailLettaThe action and transcript record (messages.jsonl) carries no integrity data to check. Git tooling such as `git fsck` covers only the memory history.V5 Comparable state PassLettaMemory is versioned in git, and the rest of the local state is JSON and JSONL files, so the owner can copy the state at two points in time and compare the copies with git and diff.M1 Instructions PassLettaThe system prompt is built from editable memory files under system/, and custom prompts can be set explicitly. The owner can read and rewrite all of them.M2 Memory PassLettaMemory is Markdown files in a git repository that the owner can view, edit and delete with ordinary tools. `letta memory` also offers backup, restore and export.M3 Logic PassLettaThe owner can add, edit or delete skills, hooks, crons and mods, and the harness source is Apache-2.0.M4 Tools and permissions PassLettaArbitrary MCP servers and skills can be added. Tools can be restricted with `--tools`, allow/deny patterns and permission modes.M5 Model choice PassLettaThe local backend supports bring-your-own provider keys and local inference through Ollama, LM Studio, llama.cpp and OpenAI-compatible endpoints. Memory and tools are implemented in the harness, not in model-API features.M6 No gatekeeping PassLettaChanging instructions, memory, skills, tools or code in local mode needs no license check or paid tier. Paid and Cloud features concern hosting (secrets sync, remote computers), not modification.C1 Communication boundaries PartialLettaThe runtime enforces channel DM policies (pairing, allowlist or open), group sender policies, admin tiers and tool allow/deny rules. The owner cannot limit which hosts or peers the agent's own tools contact.C2 Approval gates PassLettaThe runtime enforces the permission modes (strict, standard, acceptEdits, unrestricted) and allow/deny rules, pausing for approval on restricted tools.C3 Immediate halt PassLettaThe owner can interrupt a running turn, and the runtime records it as interrupted by the user. Local processes, including `letta server`, can be stopped at any time.C4 Data sovereignty FailLettaTelemetry is on by default ('Enabled by default unless explicitly disabled'). In the CLI it is posted to Letta's cloud API even when the local backend is used. The privacy policy says hosted-service data may be used to train models, without a documented opt-in.C5 Credential custody PartialLettaIn local mode, provider keys and OAuth tokens are kept in a local auth.json with 0600 permissions, which the owner controls and can inspect. The Secrets feature and Cloud-native integrations (such as Slack for Cloud agents) need a Letta account, which places those secrets with Letta.C6 Full deletion PartialLettaLocal agent state can be deleted permanently by removing ~/.letta/lc-local-backend. Telemetry already sent is retained under Letta's privacy policy, which gives no specific retention period, and Cloud agents depend on Letta's deletion process.
Claude CoworkP1 Round-trip portability FailClaude CoworkIncomplete, delayed and not restorable: the account export arrives by email, is not documented as covering Cowork sessions, plugins or scheduled tasks, and has no import back into Cowork. Local session files sit on disk but can only be copied by hand.P2 Complete export PartialClaude CoworkLocal sessions keep transcripts, uploads, outputs, memory and plugins on the device, but cloud sessions, files and scheduled tasks live in the Claude account, and neither path yields a documented export that also covers connectors and credentials, so the whole agent cannot be taken out.P3 Independent execution FailClaude CoworkCowork runs only inside the proprietary Claude Desktop app or Anthropic's cloud sandbox. Even the 3P deployment mode must download the VM workspace bundle and Claude CLI binary from downloads.claude.ai at session start.P4 Identity continuity FailClaude CoworkIdentity is the Anthropic account (or a random per-device UUID in 3P mode), and nothing lets peers verify after a migration that it is the same agent.P5 No kill switch FailClaude CoworkCowork depends on an Anthropic account, Anthropic-hosted inference and Anthropic-served runtime components, so the provider can restrict or disable it; there is no exported agent that runs independently.P6 Capability independence FailClaude CoworkScheduled tasks, cloud execution, memory, connectors and computer use are delivered by Anthropic's platform, and only Claude models can drive them. Skills, plugins and MCP connectors use open formats, which partly mitigates this.T1 Open storage format PartialClaude CoworkLocal sessions are documented as per-session JSON files, Markdown memory and a JSONL audit log readable without Anthropic software. Cloud sessions, now the default, are stored in Anthropic's backend in an undocumented format.T2 No hidden instructions FailClaude CoworkAnthropic publishes system prompts only for claude.ai chat and the mobile apps, not for Cowork's agent layer. Owner instructions, skills and plugins are visible, but content classifiers and auto-mode action screening act out of view.T3 No shadow memory FailClaude CoworkCloud sessions and files are stored on Anthropic servers, and deleted tasks remain in backend storage for up to 30 days. Consumer retention rules keep flagged content up to 2 years and safety classification scores up to 7 years, outside owner-inspectable state.T4 Complete action history PartialClaude CoworkLocal sessions keep an on-disk record of tool invocations, permission decisions and file operations alongside the transcript, which meets the outcome for those sessions. For cloud sessions, the default, the owner sees only the in-app transcript, and export of every tool call via OpenTelemetry is limited to Team and Enterprise.T5 Readable logic PartialClaude CoworkPlugins bundle skills, subagents and hook scripts as human-readable files that the owner can inspect. The Cowork orchestration, sandbox and desktop app are closed source.T6 No third-party influence channel PassClaude CoworkAnthropic has committed that Claude will remain ad-free, with no sponsored content or advertiser influence in responses, and Cowork is now part of the same Claude app. The company reserves the right to revisit this with transparency.A1 No unrecorded actions UnverifiedClaude CoworkLocal sessions record tool invocations and file operations in an append-only log, but documentation does not say that every consequential action is recorded or that an action is blocked when it cannot be; cloud-session recording is undocumented.A2 Tamper evidence PartialClaude CoworkIn local sessions each audit log entry is HMAC-chained to the previous one, so edits or deletions are detectable. No tamper evidence is documented for cloud sessions, the default.A3 Separation from the audited UnverifiedClaude CoworkDocumentation does not state whether the agent, which runs in a sandbox VM with the session working directory mounted, can alter or delete the local audit log, or how cloud-session records are protected.A4 Readable with ordinary tools PartialClaude CoworkThe local audit log is plain JSONL on disk and readable with ordinary tools. Cloud-session activity is reachable only in the app or, for Team/Enterprise, via the Compliance API and OpenTelemetry.A5 Corroborated interactions UnverifiedClaude CoworkCowork coordinates subagents and a Dispatch agent internally, but documents no exchanges with other agents whose records each side could match against the other's.V1 Open, reproducible runtime FailClaude CoworkClaude Desktop, the Cowork VM bundle and the cloud sandbox are proprietary; use of the app is governed by Anthropic's terms, and no OSI-licensed, reproducible runtime is published.V2 Active config is inspectable config PartialClaude CoworkInstructions, memory files and plugins are inspectable, and 3P deployments use inspectable JSON configuration. For consumer accounts, server-side configuration, classifiers and account-synced settings cannot be verified to match what the owner sees.V3 Attributable messages FailClaude CoworkMessages go out through the owner's connected accounts and connectors, and recipients cannot verify that they came from this agent under the owner's authority.V4 Independently checkable record FailClaude CoworkThe local audit log is HMAC-chained with a keychain-protected key, but no verification procedure or open verifier is published, so its integrity cannot be checked independently of Anthropic's app.V5 Comparable state PartialClaude CoworkLocal-session state (transcripts, memory, plugins and the audit log) sits in ordinary files that the owner can snapshot and compare with standard tools. Cloud sessions, the default, and account-synced settings are not fully exposed, so changes there cannot be verified.M1 Instructions PartialClaude CoworkOwners can write global "Instructions for Claude", folder and project instructions, and skills, but cannot read or rewrite Cowork's platform system prompt or safety layers.M2 Memory PassClaude CoworkCowork memory is stored as Markdown notes that owners can review, delete individually or pause, and memory shared with chat can be viewed, edited and deleted in Settings.M3 Logic PartialClaude CoworkOwners can install, upload, edit and remove plugins containing skills, subagents and hook scripts, and can add Git repositories as marketplaces. The core agent loop and sandbox cannot be changed.M4 Tools and permissions PartialClaude CoworkOwners can add custom MCP connectors and plugins, disconnect connectors, block apps from computer use and set sandbox egress permissions. Egress permissions do not cover web tools or MCPs, and fine-grained tool policies are documented mainly as managed or admin configuration.M5 Model choice FailClaude CoworkOnly Claude models can be selected. The 3P mode changes where Claude inference is served (Bedrock, Vertex, Foundry or a Messages-API gateway), not the model family, and local open-weight models are not supported.M6 No gatekeeping FailClaude CoworkCowork requires a paid plan, computer use is limited to Pro and Max, and OpenTelemetry monitoring is limited to Team and Enterprise. All modifications are bounded by Anthropic's product surface and terms.C1 Communication boundaries PartialClaude CoworkCloud sandbox traffic passes through an enforced egress allowlist, the browser asks before acting on a new site, and apps can be blocklisted. These boundaries do not cover web fetch, web search or MCP connectors, and no per-recipient controls are documented.C2 Approval gates PartialClaude CoworkA Manual mode pauses for sign-off on connector, plugin, browser and some Cowork actions, and permanent file deletion and new app access always require permission. Manual mode does not cover every action, and enforcement cannot be independently verified.C3 Immediate halt PassClaude CoworkOwners can stop Claude at any point during a task, and scheduled tasks can be paused or deleted.C4 Data sovereignty FailClaude CoworkCloud sessions process files and work on Anthropic servers, and local sessions still send content to Anthropic for inference. Consumer data is used for training when the model-improvement setting is on, which is reported to default to on.C5 Credential custody PartialClaude CoworkLocal MCP server credentials stay on the device, and connectors can be disconnected. Connector authorization tokens are held server-side and never enter the sandbox, so they are not owner-inspectable and do not travel with the agent.C6 Full deletion PartialClaude CoworkDeleted Cowork tasks leave history immediately and backend storage within 30 days, and local sessions are deleted by removing their files. Consumer retention of flagged content (2 years), safety scores (7 years) and training data (up to 5 years) goes beyond deletion.
ClaudeP1 Round-trip portability FailClaudeIncomplete, delayed and not restorable: the account export arrives by email, is not documented as including Skills, connectors or credentials, and Anthropic documents no import of it. Memory and Skills can only be brought back separately by pasting text and uploading .zip files.P2 Complete export PartialClaudeThe export includes conversations, account data and memory, but documentation does not state that custom Skills, connector configurations or credentials are included, so the export does not capture the whole agent.P3 Independent execution FailClaudeThe agent runtime and Claude models are available only as Anthropic-hosted proprietary services; no open-source runtime can execute the exported agent without contacting Anthropic servers.P4 Identity continuity FailClaudeThe agent's identity is the Anthropic account, which does not travel with an export, so nobody the agent has dealt with can verify after a move that it is the same agent.P5 No kill switch FailClaudeThe functioning agent exists only on Anthropic infrastructure, so the provider can restrict or close the account; exported JSON files carry no license check but are not an executable agent.P6 Capability independence FailClaudeMemory, search, artifacts, connectors and Chrome automation are delivered by Anthropic's service and work only with Claude models, so moving to another model would remove them. Skills and MCP servers use open formats, which partly mitigates this.T1 Open storage format PartialClaudeExported conversations are JSON and Skills use a documented SKILL.md format, but the live internal storage format is undocumented and only reachable through Anthropic's software.T2 No hidden instructions PartialClaudeAnthropic publishes the base system prompts for claude.ai and the mobile apps, and user/project instructions are visible. Tool definitions, memory injection, safety interventions and other runtime context are not all shown to the owner.T3 No shadow memory FailClaudeDeleted chats persist in back-end storage for up to 30 days; flagged inputs/outputs are kept up to 2 years and trust-and-safety classification scores up to 7 years, outside the owner-inspectable state.T4 Complete action history PartialClaudeTool calls and connector actions appear inline in conversation transcripts, which the owner can export. Completeness is not documented, and deleted or incognito chats leave no owner-held record.T5 Readable logic PartialClaudeCustom Skills are human-readable Markdown plus optional scripts. The platform's own agent logic (orchestration, memory, tool routing) is closed source.T6 No third-party influence channel PassClaudeAnthropic states that Claude will remain ad-free, with no sponsored links and no advertiser influence or unrequested product placement in responses. The company reserves the right to revisit this with transparency.A1 No unrecorded actions UnverifiedClaudeAnthropic does not document whether every consequential action is durably recorded, or whether an action is blocked when it cannot be recorded.A2 Tamper evidence FailClaudeThe owner-visible record is conversation history, which can be deleted or branched by editing messages without a detectable trace, and no other tamper-evident record is documented.A3 Separation from the audited UnverifiedClaudeAnthropic does not document whether the agent layer can alter or delete records of its own actions; Claude can edit its memory store, which is separate from history.A4 Readable with ordinary tools PartialClaudeExported conversation JSON, including tool-use content, can be read with ordinary tools, but it is an account export rather than a dedicated audit trail.A5 Corroborated interactions UnverifiedClaudeThe consumer apps document no agent-to-agent exchanges whose records each side could match against the other's.V1 Open, reproducible runtime FailClaudeThe Claude apps and service runtime are proprietary; no OSI-licensed, reproducible runtime is published. Open specifications (MCP, Agent Skills) cover interfaces only.V2 Active config is inspectable config PartialClaudeBase system prompts and user instructions are inspectable, but server-side configuration, classifiers and injected context cannot be verified to match what is published.V3 Attributable messages FailClaudeMessages go out through the owner's connected accounts, so recipients cannot verify that they came from this agent under the owner's authority, and no attribution survives leaving Anthropic.V4 Independently checkable record FailClaudeNo action record is offered whose integrity can be checked with open tools that do not depend on Anthropic.V5 Comparable state FailClaudeServer-side state is not fully exposed and the export is partial, so the owner cannot verify whether the agent's state changed between two points in time.M1 Instructions PartialClaudeOwners can write profile preferences, project instructions, styles and Skills, but cannot rewrite the platform system prompt or safety layers.M2 Memory PassClaudeSettings > Memory lists stored memory topics, each of which can be read, edited or deleted; memory can also be updated from chat, and incognito chats are excluded.M3 Logic PartialClaudeOwners can create, upload and edit custom Skills (SKILL.md with scripts); the core agent logic of the app cannot be changed.M4 Tools and permissions PartialClaudeOwners can add any remote MCP server as a custom connector, run local MCP servers in Claude Desktop, and disconnect connectors. Free users are limited to one custom connector, and fine-grained per-tool permission policies are documented mainly for Team/Enterprise admins.M5 Model choice FailClaudeOnly Anthropic's Claude models can be selected; third-party or local open-weight models are not supported.M6 No gatekeeping FailClaudeSome modifications are tier-gated, for example the one-custom-connector limit on Free, and all changes are bounded by Anthropic's terms and product surface.C1 Communication boundaries PartialClaudeOwners choose which connectors are enabled and can revoke per-site access in Claude in Chrome, but runtime-enforced limits on which recipients, domains or channels the agent may contact are documented only as Team/Enterprise admin controls.C2 Approval gates PartialClaudeClaude in Chrome offers a Manual mode that pauses for Allow/Deny on each action, and some high-risk actions always require permission. Selecting specific action types to gate is documented mainly as an admin feature, and enforcement cannot be independently verified.C3 Immediate halt PassClaudeResponses and Chrome agent tasks can be stopped from the interface at any time, and site permissions can be revoked in extension settings.C4 Data sovereignty FailClaudeAll content is processed on Anthropic servers by design. Since the 2025 consumer terms update, users choose whether chats are used for training, but the setting is reported to default to on, with 5-year retention for those who allow it.C5 Credential custody PartialClaudeLocal MCP server credentials live in an owner-controlled config file in Claude Desktop, and remote connectors can be disconnected. OAuth tokens for remote connectors are held by Anthropic, are not inspectable and do not travel with an export.C6 Full deletion PartialClaudeOwners can delete chats and their account; deleted chats are removed from back-end storage within 30 days. Flagged content (up to 2 years), safety scores (up to 7 years), feedback (5 years) and de-identified training data (up to 5 years) may be retained longer.
ChatGPTP1 Round-trip portability FailChatGPTIncomplete, delayed and not restorable: the Data Controls export arrives by email and omits custom GPTs, connectors and credentials, and OpenAI documents no import; Gemini's chat import restores conversation text alone.P2 Complete export PartialChatGPTThe export captures conversation history (conversations.json, chat.html) and account data, but documentation does not show that custom GPT definitions, connector configuration, credentials or the full saved-memory and chat-history profile are included, so parts of what defines the agent stay with OpenAI.P3 Independent execution FailChatGPTChatGPT runs only as an OpenAI-hosted service; there is no open-source runtime that can load an export and operate the agent without OpenAI servers.P4 Identity continuity FailChatGPTThe agent's identity is the OpenAI account, which does not migrate, so nobody the agent has dealt with can verify after a move that it is the same agent.P5 No kill switch FailChatGPTBecause no exportable agent exists, every capability depends on continued account access, which OpenAI's terms allow it to suspend or terminate. Features and models can be changed or withdrawn by the provider.P6 Capability independence FailChatGPTMemory, tools, agent mode, scheduled tasks and connectors are delivered by OpenAI's hosted platform and work only with OpenAI models, so moving to another model or a local one would remove them.T1 Open storage format PartialChatGPTThe export uses JSON and HTML that can be read with ordinary tools, although OpenAI does not publish a formal schema. The live agent state is held in OpenAI's proprietary backend and cannot be inspected directly.T2 No hidden instructions FailChatGPTOpenAI places system and developer-level instructions in the model context that are not shown to the user; the published Model Spec describes the instruction hierarchy but not the full text used in production.T3 No shadow memory FailChatGPTOpenAI retains data outside the user-inspectable state, including logs of deleted memories for up to 30 days, safety and abuse records, and ad-interaction signals used for ad personalisation. The 'reference chat history' profile is not exposed as a complete itemised list.T4 Complete action history PartialChatGPTTool use and agent-mode activity appear in conversation history, which the owner can export, but OpenAI does not document that every action and tool call is captured, and deleted or temporary chats leave no owner-held record.T5 Readable logic PartialChatGPTOwner-authored logic such as custom GPT instructions and action schemas is human-readable to the creator, but the platform's own agent logic is closed source.T6 No third-party influence channel PartialChatGPTSince February 2026, Free and Go users in the US see labelled sponsored units below responses. Ad personalisation can be turned off and paid tiers are ad-free. OpenAI states ads do not influence answers, but this cannot be independently verified, and removing ads on the Free tier comes with reduced limits.A1 No unrecorded actions UnverifiedChatGPTOpenAI does not document whether every consequential agent action is durably recorded, or whether an action is blocked when it cannot be recorded.A2 Tamper evidence FailChatGPTThe owner-visible record of actions is chat history, which can be edited through branching or deleted without a detectable trace, and no other tamper-evident record is available to the owner.A3 Separation from the audited UnverifiedChatGPTOpenAI does not document whether the agent layer can alter or delete records of its own actions.A4 Readable with ordinary tools PartialChatGPTExported conversation JSON can be read with general-purpose tools, but it is a chat transcript rather than a complete audit trail of agent actions.A5 Corroborated interactions FailChatGPTWhen ChatGPT exchanges messages with other agents or services through apps or MCP, no documented record lets either side match its log of the exchange against the other's.V1 Open, reproducible runtime FailChatGPTThe ChatGPT runtime and apps are proprietary and not published under an OSI-approved license.V2 Active config is inspectable config FailChatGPTThe active configuration includes server-side system instructions, model routing and feature flags that the owner cannot inspect.V3 Attributable messages FailChatGPTEmails and actions sent through agent mode or connectors can be attributed only to the owner's connected account; recipients cannot verify they came from this agent, and no such proof survives leaving OpenAI.V4 Independently checkable record FailChatGPTNo record of agent actions is offered whose integrity can be checked with open tools that do not depend on OpenAI.V5 Comparable state FailChatGPTAgent state is held server-side and only partly exported, so the owner cannot verify whether the full state changed between two points in time.M1 Instructions PartialChatGPTOwners can write custom instructions and the full instructions of their own custom GPTs, but cannot read or rewrite OpenAI's system-level instructions.M2 Memory PartialChatGPTSaved memories can be viewed and deleted, and memory and chat-history reference can be switched off. Information drawn from chat history is not exposed as editable items, and deleting a chat does not necessarily remove memories derived from it.M3 Logic PartialChatGPTOwners can define custom GPTs with instructions, knowledge files and API actions, and can add MCP apps. The underlying agent loop and platform logic cannot be modified.M4 Tools and permissions PartialChatGPTApps and connectors can be connected and disconnected, and on paid plans developer mode allows arbitrary remote MCP servers. Custom tools are limited to remote HTTPS MCP servers and are unavailable on Free and Go.M5 Model choice FailChatGPTThe model picker offers only OpenAI-hosted models; third-party and local open-weight models cannot be used in ChatGPT.M6 No gatekeeping FailChatGPTDeveloper mode (custom MCP tools) requires a paid plan, and agent mode and some other capabilities are tier-gated; GPTs shared in the GPT Store are subject to OpenAI usage policies and review.C1 Communication boundaries PartialChatGPTOwners limit channels by choosing which apps and connectors are enabled, but cannot set which recipients, domains or peers the agent may contact, and no enforcement below the model is documented.C2 Approval gates PartialChatGPTAgent mode asks for confirmation before consequential actions such as purchases, and uses watch mode on sensitive sites. OpenAI describes the confirmation behaviour as trained model behaviour, and owners cannot choose which actions are gated.C3 Immediate halt PassChatGPTOwners can stop an agent task or response at any time from the interface, and can take over the agent's browser.C4 Data sovereignty FailChatGPTAll content is processed on OpenAI servers. For consumer plans, 'Improve the model for everyone' is on by default, so training is opt-out rather than opt-in.C5 Credential custody PartialChatGPTOAuth tokens for apps and connectors are held by OpenAI. Owners can disconnect apps, which revokes access, but cannot inspect the tokens or take them to another runtime.C6 Full deletion PartialChatGPTOwners can delete chats, memories and their account, and OpenAI states data is removed within 30 days unless legal or security obligations require longer retention. Data already used for training is not removed from models, and court-ordered preservation has previously extended retention.
GeminiP1 Round-trip portability FailGeminiIncomplete, delayed and not restorable: Google Takeout exports Gems and activity asynchronously without memory, Connected Apps or credentials, and there is no import to restore them; Gemini's chat import accepts only ChatGPT and Claude exports.P2 Complete export PartialGeminiTakeout exports chats, generated media, uploads and Gems, but documentation does not state that memory derived from past chats, personal-context settings, Connected Apps configuration or credentials are included, so part of the agent stays with Google.P3 Independent execution FailGeminiThe Gemini app runtime and models are Google-hosted proprietary services; no open-source runtime can run the exported agent without Google servers.P4 Identity continuity FailGeminiThe agent's identity is the Google Account, which does not travel with an export, so nobody the agent has dealt with can verify its continuity after a move.P5 No kill switch FailGeminiThe functioning agent exists only on Google infrastructure and depends on the Google Account; exported files carry no license check but are not an executable agent.P6 Capability independence FailGeminiMemory, Connected Apps, Gems and agent tasks are delivered by Google's platform and run only on Gemini models; none is documented to work with another provider or a local model.T1 Open storage format PartialGeminiTakeout exports activity in readable formats (such as JSON or HTML in a .zip/.tgz archive), but live internal storage is undocumented and accessible only through Google's software.T2 No hidden instructions FailGeminiOwner instructions and Gem instructions are visible, but Google does not publish the Gemini app's system instructions or the personal context it injects from past chats and connected apps.T3 No shadow memory FailGeminiChats are retained 72 hours even with Keep Activity off, and chats selected for human review are retained up to three years even after the owner deletes activity.T4 Complete action history PartialGeminiAgent tasks show progress and a work panel of files accessed or modified, and chats are kept in Gemini Apps Activity and exportable via Takeout when Keep Activity is on. No complete record of actions and tool calls is documented, and history depends on activity settings.T5 Readable logic PartialGeminiGems and instructions are plain natural-language text, but the app's agent logic and task orchestration are closed source.T6 No third-party influence channel PartialGeminiGoogle states there are no ads in the Gemini app and that Gemini chats are not used to show ads. Google has not made a binding commitment to keep the app ad-free and has described itself as open to ads, which already run in AI Overviews and AI Mode in Search.A1 No unrecorded actions UnverifiedGeminiGoogle does not document whether every consequential agent action is durably recorded, or whether an action is blocked when it cannot be recorded.A2 Tamper evidence FailGeminiOwner-visible history in Gemini Apps Activity can be deleted or auto-deleted without a detectable trace, and no tamper-evident record is documented.A3 Separation from the audited UnverifiedGeminiGoogle does not document whether the agent layer can alter or delete records of its own actions.A4 Readable with ordinary tools PartialGeminiTakeout exports of Gemini Apps activity are readable with ordinary tools, but they are an activity export rather than a dedicated audit trail.A5 Corroborated interactions UnverifiedGeminiThe consumer app documents no agent-to-agent exchanges whose records each side could match against the other's.V1 Open, reproducible runtime FailGeminiThe Gemini app and its service runtime are proprietary; no OSI-licensed, reproducible runtime is published.V2 Active config is inspectable config FailGeminiThe system instructions and injected personal context the app runs with are not published, so active configuration cannot be compared with inspectable configuration.V3 Attributable messages FailGeminiMessages go out through the owner's Google and connected accounts, so recipients cannot verify that they came from this agent, and no attribution survives leaving Google.V4 Independently checkable record FailGeminiNo action record is offered whose integrity can be checked with open tools that do not depend on Google.V5 Comparable state FailGeminiServer-side state is not fully exposed and Takeout is partial, so the owner cannot verify whether the agent's state changed between two points in time.M1 Instructions PartialGeminiOwners can view, edit and delete Instructions for Gemini and Gem instructions, but cannot read or rewrite the app's system instructions.M2 Memory PartialGeminiSaved instructions are editable and past-chat memory can be switched off, but there is no viewer for individual derived memories; Google advises deleting the underlying chats or correcting Gemini in chat.M3 Logic PartialGeminiOwners can create and edit Gems and Spark tasks/schedules, but cannot change the underlying agent logic or add executable code.M4 Tools and permissions PartialGeminiOwners can enable or disable Connected Apps, and can add custom MCP servers for Gemini Spark. Custom apps require 18+, the US, a personal account, Keep Activity on and Spark access (Google AI Pro/Ultra).M5 Model choice FailGeminiOnly Google's Gemini models can be selected in the app; third-party or local open-weight models are not supported.M6 No gatekeeping FailGeminiAdding custom tools requires a paid Google AI Pro/Ultra plan and eligible region, and depends on enabling Keep Activity.C1 Communication boundaries PartialGeminiOwners choose which Connected Apps are enabled, and agent tasks ask before sending communications, but owners cannot set which recipients or channels the agent may contact, and no enforcement below the model is documented.C2 Approval gates PartialGeminiAgent tasks prompt for confirmation before sending communications, modifying data, purchases and form submissions. The gated categories are set by Google, not selected by the owner, and enforcement cannot be independently verified.C3 Immediate halt PassGeminiOwners can stop a task with Stop response or Take control of the browser, and can pause scheduled tasks from the work panel.C4 Data sovereignty FailGeminiAll content is processed on Google servers by design. With Keep Activity on, Google uses chats to train its models and a subset is human-reviewed; this is opt-out rather than opt-in.C5 Credential custody FailGeminiConnected Apps and custom MCP credentials are held by Google; owners can disconnect apps, but tokens are not inspectable and do not travel with an export.C6 Full deletion PartialGeminiOwners can delete Gemini Apps activity and Gems or their Google Account, but chats reviewed by humans are retained for up to three years, disconnected from the account.
Gemini SparkP1 Round-trip portability FailGemini SparkIncomplete and not restorable in one action: skills download and re-upload as .zip files, but tasks, schedules, remote computer state and credentials have no export or import, so the Spark agent itself cannot be restored.P2 Complete export PartialGemini SparkSkill downloads include instructions and files, and Takeout covers chats, media and uploads, but tasks, schedules, remote computer files, remote browser cookies, Connected App credentials and personal context are not documented as exportable.P3 Independent execution FailGemini SparkSpark runs on Gemini 3.5 with Google's Antigravity harness on Google-hosted remote browsers and computers; no open-source runtime can run it without Google servers.P4 Identity continuity FailGemini SparkSpark is bound to the owner's personal Google Account, and nothing lets peers verify its continuity outside Google.P5 No kill switch FailGemini SparkThe functioning agent exists only on Google infrastructure and depends on an active Pro/Ultra subscription and Keep Activity; exported skills are files, not an executable agent.P6 Capability independence FailGemini SparkSchedules, triggers, remote browsing, code execution and Connected Apps are delivered by Google's platform on Gemini models, with no documented way to keep them on another model. Skills use the portable SKILL.md format but rely on Spark to execute.T1 Open storage format PartialGemini SparkSkills are markdown and ordinary code/config files, and Takeout exports activity in a .zip/.tgz archive. Storage of tasks, schedules and remote computer state is undocumented and reachable only through Google's software.T2 No hidden instructions FailGemini SparkSkill instructions are visible, but Google does not publish Spark's system instructions or the context it injects from Personal Intelligence and Connected Apps.T3 No shadow memory FailGemini SparkSpark data follows Gemini retention rules: chats selected for human review are kept up to three years, disconnected from the account, beyond the owner's deletion.T4 Complete action history PartialGemini SparkTask threads show planned, current and completed steps, and task activity is stored in Gemini Apps Activity, but no complete record of tool calls is documented, and Spark task steps are not documented as part of the Takeout export.T5 Readable logic PartialGemini SparkSkills are human-readable markdown and can include .py and .sh scripts, but the Antigravity harness and task orchestration are closed source.T6 No third-party influence channel PartialGemini SparkGoogle states Gemini Apps chats are not used to show ads and the app shows none. There is no binding commitment to keep Spark ad-free.A1 No unrecorded actions UnverifiedGemini SparkGoogle does not document whether every consequential Spark action is durably recorded, or whether an action is blocked when it cannot be recorded.A2 Tamper evidence FailGemini SparkTask threads and their activity can be deleted without a detectable trace, and no tamper-evident record is documented.A3 Separation from the audited UnverifiedGemini SparkGoogle does not document whether the agent, which can save files and run code on its remote computer, can alter or delete records of its own actions.A4 Readable with ordinary tools PartialGemini SparkTakeout exports Gemini Apps activity in readable archives, but it is an activity export, and Spark task steps are not documented as included.A5 Corroborated interactions UnverifiedGemini SparkNo exchanges with other agents whose records each side could match against the other's are documented for Spark.V1 Open, reproducible runtime FailGemini SparkThe Spark runtime and Antigravity harness as hosted by Google are proprietary; no OSI-licensed, reproducible runtime is published.V2 Active config is inspectable config FailGemini SparkSystem instructions and injected personal context are not published, so the active configuration cannot be compared with what the owner can inspect.V3 Attributable messages FailGemini SparkSpark sends through the owner's Google and connected accounts, so recipients cannot verify that messages came from this agent under the owner's authority.V4 Independently checkable record FailGemini SparkNo action record is offered whose integrity can be checked with open tools that do not depend on Google.V5 Comparable state FailGemini SparkRemote computer, task and server-side state are not fully exposed, so the owner cannot verify whether the agent's state changed between two points in time.M1 Instructions PartialGemini SparkOwners can edit skill descriptions and instructions directly or conversationally, but cannot read or rewrite Spark's system instructions.M2 Memory PartialGemini SparkOwners can delete tasks with their activity and bulk-delete remote computer and browser data, but no item-level viewer or editor for derived memory or saved remote state is documented.M3 Logic PartialGemini SparkOwners can create, edit, upload and delete skills including .py and .sh scripts (without internet access), and set schedules. The harness and orchestration logic cannot be changed.M4 Tools and permissions PartialGemini SparkOwners can enable, disable and remove Connected Apps and add custom MCP servers. Custom apps are limited to US adults with personal accounts, English and Keep Activity on, and write actions require confirmation.M5 Model choice FailGemini SparkSpark runs on Google's Gemini 3.5; third-party or local open-weight models cannot be selected.M6 No gatekeeping FailGemini SparkSpark and skills require a paid Google AI Pro or Ultra subscription, an eligible region and Keep Activity on; custom apps are further limited to the US.C1 Communication boundaries PartialGemini SparkOwners choose which apps to connect, and Spark asks before sending communications, but owners cannot set which recipients or channels it may contact, no enforcement below the model is documented, and Google notes Spark may share chat information with websites and custom apps.C2 Approval gates PartialGemini SparkSpark prompts for confirmation before sending communications, modifying data, purchases and submitting web forms. The gated categories are set by Google rather than selected by the owner, and enforcement cannot be independently verified.C3 Immediate halt PassGemini SparkOwners can stop a running task at any time with the Stop button, and deleting a task also removes its schedules.C4 Data sovereignty FailGemini SparkSpark runs entirely on Google servers and requires Keep Activity on, under which chats are used to improve Google models and a subset is human-reviewed; there is no opt-in for training.C5 Credential custody FailGemini SparkRemote browser authentication cookies and Connected App and MCP credentials are held in Google's service; owners can delete or disconnect them, but they are not inspectable and do not travel with an export.C6 Full deletion PartialGemini SparkOwners can delete tasks, skills, remote computer and browser data, Gemini Apps activity or the Google Account, but chats reviewed by humans are retained up to three years.
Meta MuseP1 Round-trip portability FailMeta MuseIncomplete and not restorable: 'Download your Muse data' omits Meta-developed skills, connector code, credentials and VM state, and Meta documents no import or restore on Muse or elsewhere.P2 Complete export PartialMeta MuseThe download covers chats, files and agent information, and memory and identity live in files such as MEMORY.md, Soul.md and Identity.md. Meta-developed skills, connector code, credentials and VM state are not documented as leaving with the export.P3 Independent execution FailMeta MuseMuse runs only on Meta's Muse Secure VM with the proprietary Muse Spark model; no open-source runtime is available to execute an exported Muse.P4 Identity continuity FailMeta MuseMuse's identity is tied to the user's Meta account and Accounts Center, and nothing lets others verify it is the same agent without Meta.P5 No kill switch FailMeta MuseBecause the agent cannot run outside Meta's hosted VM, Meta retains the ability to suspend, change or discontinue it; no independently running exported agent exists.P6 Capability independence FailMeta MuseTools, background execution, connectors and permissions depend on Meta's VM, Sentinel and authd services and on Muse Spark; no path to keep them with another model provider or a local model is documented.T1 Open storage format PartialMeta MuseMemory and identity are stored as Markdown files (MEMORY.md, Soul.md, Identity.md) and files sit in a Library tab. The storage format of chats, tasks, activity and the exported archive is not documented.T2 No hidden instructions FailMeta MuseMeta states built-in skills are developed by Meta and the harness adds its own labelling of untrusted input; no documented means lets the owner view the full system and skill instructions placed in context.T3 No shadow memory FailMeta MuseMeta notes Muse may still remember information learned from deleted content, and interaction trajectories are used for training (PII-sanitized) unless the user opts out, so derived data can exist outside the owner-inspectable state.T4 Complete action history PartialMeta MuseAn in-app Activity log gives a chronological record of actions taken and permissions granted, including skills used. Whether it covers every tool call and leaves with the data download is not documented.T5 Readable logic PartialMeta MuseCustom connectors are code Muse writes on the VM and saves as reusable skills in instruction form; Meta's built-in skills and the agent runtime are not exposed as readable source.T6 No third-party influence channel UnverifiedMeta MuseMeta states Muse conversations and VM data are not shared with its ad systems, but Meta plans to earn transaction fees and has retail partners; whether partner offers can influence Muse's context or ranking is not documented.A1 No unrecorded actions UnverifiedMeta MuseSentinel gates connector actions and egress before they execute, and an Activity log records actions, but Meta does not document that every consequential action is durably recorded or that an action which cannot be recorded does not proceed.A2 Tamper evidence UnverifiedMeta MuseMeta does not document whether edits to or deletions from the Activity log would be detectable.A3 Separation from the audited UnverifiedMeta MuseThe runtime and Sentinel are separate security domains, but Meta does not document whether the agent can alter or delete Activity log entries.A4 Readable with ordinary tools UnverifiedMeta MuseThe Activity log is viewed in the Muse app; whether it is included in the data download in a format readable with general-purpose tools is not documented.A5 Corroborated interactions UnverifiedMeta MuseMeta documents no way to match Muse's record of an exchange, such as a sent email, against the counterpart's record.V1 Open, reproducible runtime FailMeta MuseThe Muse runtime, Sentinel and Muse Spark model are proprietary; no open-source release or reproducible build is published.V2 Active config is inspectable config FailMeta MuseOwners can inspect memory and identity files and connector settings, but the system instructions, Meta skills and Sentinel policy the agent runs with are not exposed for inspection.V3 Attributable messages FailMeta MuseMessages go out through connected accounts and a planned Meta-provided Muse email address; recipients have no documented way to verify they came from this agent under the owner's authority independently of Meta.V4 Independently checkable record FailMeta MuseNo documented way exists to check the Activity log's integrity with open tools independent of Meta.V5 Comparable state FailMeta MuseThe owner sees memory and identity files, but Meta notes Muse may retain information from deleted content, and system instructions, Meta skills and VM state are not exposed, so the owner cannot verify whether the agent's state changed.M1 Instructions PartialMeta MuseOwners can edit name, personality, tone and style and directly edit Soul.md and Identity.md; underlying system instructions and Meta skills are not editable.M2 Memory PartialMeta MuseMEMORY.md is viewable and editable and a forget skill removes items on request; Meta states forgetting is best-effort and information from deleted items may remain.M3 Logic PartialMeta MuseOwners can have Muse create custom connectors and saved skills, but built-in skills are developed by Meta and the runtime logic cannot be changed.M4 Tools and permissions PartialMeta MuseOwners can connect and revoke connectors, adjust approval settings and add custom connectors to services Meta does not offer; permissions are mediated by Meta's Sentinel, and Meta products auto-connect via Accounts Center.M5 Model choice FailMeta MuseMuse runs on Meta's Muse Spark model; no model selection or local model option is documented.M6 No gatekeeping PartialMeta MusePersonal customization and custom connectors are available without Meta review, and paid tiers mainly raise usage; listing a connector in Muse's directory requires Meta review, and system-level changes are not possible at any tier.C1 Communication boundaries PartialMeta MuseSentinel enforces connector actions and all network egress outside the model, using owner-set connector policy with fine-grained per-action approvals. Owner-set limits on specific recipients or domains are not documented.C2 Approval gates PassMeta MuseSensitive actions such as sending email or purchasing require approval through a client UI separate from the conversation, enforced by Sentinel, with scopes from one-time to perpetual; default approval settings are adjustable.C3 Immediate halt PartialMeta MuseOwners can take control of or stop a browser task, and scheduled tasks are listed; stopping other background work is done by asking Muse in chat, and no global immediate halt is documented.C4 Data sovereignty FailMeta MuseContent is processed on Meta's cloud and interactions are used for model training by default (PII-sanitized) unless the user opts out in Data controls.C5 Credential custody PartialMeta MuseCredentials sit in a Secure Credentials Store outside the agent runtime, with surrogate tokens swapped at the boundary, and connectors can be revoked; the store is Meta-held and credentials do not travel with the agent.C6 Full deletion PartialMeta MuseReset Muse permanently and irreversibly deletes chat history, files and active tasks. Retention of already-used training data and backups is not specified, and the agent identity is tied to the Meta account.
Grok BotP1 Round-trip portability FailGrok BotIncomplete and not restorable: no export of a Bot is documented, and template links, which stay hosted by xAI, recreate only its profile, settings, skills and routines, excluding memory, history, files, computer access and logins.P2 Complete export FailGrok BotNo export is documented; memory, routines, files and sign-ins stay on the provider's cloud computer and backend, and template links carry only part of the configuration.P3 Independent execution FailGrok BotBots execute only on hosted computers in Cursor's cloud; no open-source runtime is available.P4 Identity continuity FailGrok BotBots are tied to the user's Cursor account, and nothing lets others verify a Bot is the same agent without the provider.P5 No kill switch FailGrok BotBots cannot run outside the provider's service; admins and the provider can terminate computers, and access depends on a paid plan.P6 Capability independence FailGrok BotRoutines, triggers, connectors and memory depend on the hosted service and Cursor account integrations, and the provider manages model selection, so no capability survives a model swap.T1 Open storage format UnverifiedGrok BotFiles reside in /workspace on the cloud computer, but the storage format of memory, conversations and routines is not documented.T2 No hidden instructions FailGrok BotOwner-set descriptions, skills and Team Rules are visible, but the provider's system instructions and model orchestration are not published or exposed to users.T3 No shadow memory FailGrok BotBackend data follows Cursor retention terms, action records are kept internally for 90 days, and Enterprise analytics derive conversation insights outside the owner-inspectable Bot state.T4 Complete action history PartialGrok BotConversations show proposed operations and routines keep success and failure history. A detailed record of tool calls, shell commands and browsing can be streamed to the organization's own collector, but only on Enterprise, off by default and admin-facing.T5 Readable logic PartialGrok BotSkills and routines are natural-language instructions with steps and decision rules that owners can read and edit; the agent runtime itself is not available as source.T6 No third-party influence channel UnverifiedGrok BotNo advertising or sponsored placement in Bot context is documented, nor any explicit commitment against it.A1 No unrecorded actions UnverifiedGrok BotApprovals gate actions before execution and Enterprise Action Recording captures tool calls, commands and browsing, but it is off by default and the docs do not say an action is blocked when it cannot be recorded.A2 Tamper evidence UnverifiedGrok BotEnterprise Action Recording and Audit Logs exist, but the docs do not say whether edits to or deletions from these records would be detectable.A3 Separation from the audited PartialGrok BotOn Enterprise, the platform records Bot actions on its backend and can stream them to the organization's own collector, outside the Bot's cloud computer. The docs do not state this as a protection, and other plans have no such record.A4 Readable with ordinary tools PartialGrok BotEnterprise teams can stream recorded actions via OpenTelemetry to their own collectors and audit logs to a SIEM; individual and Teams plans have no documented log export.A5 Corroborated interactions UnverifiedGrok BotBots share one cloud computer and can coordinate, but no way to match one side's record of an exchange against the other's is documented.V1 Open, reproducible runtime FailGrok BotThe runtime is proprietary; the vendor has not published its orchestration code or reproducible builds.V2 Active config is inspectable config FailGrok BotThe model and system configuration are provider-managed and not inspectable; only owner and team-authored rules, skills and settings are visible.V3 Attributable messages FailGrok BotBots act through signed-in accounts and shared static egress IPs; recipients have no documented way to verify a message came from this Bot under its owner's authority.V4 Independently checkable record FailGrok BotNo documented procedure or open tool lets the owner check the integrity of the action record independently of the provider.V5 Comparable state UnverifiedGrok BotThe docs describe no way for the owner to verify whether a Bot's memory, routines and computer state changed between two points in time.M1 Instructions PartialGrok BotOwners edit a Bot's name, description and routine instructions; provider system instructions are not editable, and on team plans Team Rules are non-negotiable for members.M2 Memory UnverifiedGrok BotBots retain preferences, facts and summaries, but no interface to view, edit or delete individual memory items is documented beyond deleting the whole Bot.M3 Logic PartialGrok BotOwners can create skills in natural language, teach tasks by demonstration, and edit, pause or delete routines; the runtime logic is not modifiable.M4 Tools and permissions PartialGrok BotOwners can add plugins and custom remote or stdio MCP servers and set local execution to ask, always or never; per-Bot credential scoping is not available because Bots share one computer, and team MCP policy applies.M5 Model choice FailGrok BotModel selection is managed by the provider with no customer-facing model picker or local model option documented.M6 No gatekeeping PartialGrok BotThe product requires a paid Cursor or SuperGrok plan, and controls such as network allowlists, enforced Auto-review, action recording and computer management are Enterprise-only.C1 Communication boundaries PartialGrok BotEnterprise admins can restrict network destinations to an allowlist and trust specific MCP servers, enforced by the platform. Individual owners rely on per-action approvals and cannot set in advance whom a Bot may contact.C2 Approval gates PassGrok BotSensitive actions are held for approval (Allow once, Deny, Always allow) before execution, with Auto-review rules that teams can enforce; local execution defaults to ask every time.C3 Immediate halt PartialGrok BotOwners can send a stop message and pause routines; a hard computer termination is available only to Enterprise organization admins.C4 Data sovereignty FailGrok BotAll work runs on provider infrastructure, Grok Bot requires data storage and does not support Legacy Privacy Mode, and non-training depends on Cursor Privacy Mode settings rather than an explicit opt-in.C5 Credential custody PartialGrok BotConnector OAuth tokens stay on Cursor's backend, never on the computer or with the model, and secrets are entered through masked requests; credentials remain provider-held and do not travel with the Bot.C6 Full deletion PartialGrok BotDeleting a Bot removes its profile, conversation and routines but not shared computer files or sign-ins; backend data is deleted within 30 days after service ends, and daily encrypted backups exist.
Perplexity CometP1 Round-trip portability FailPerplexity CometIncomplete, delayed and not restorable: 'Export my data' delivers a ZIP of threads by email without instructions, connectors or logic, and Perplexity documents no import.P2 Complete export PartialPerplexity CometThreads come through the account export and browsing data sits in the local profile, but assistant instructions, model routing, connector credentials and executable logic stay with Perplexity, as does anything that identifies the agent.P3 Independent execution FailPerplexity CometThe browser runs locally, but the Comet Assistant's inference and agent logic run on Perplexity's servers. No exportable agent runs on an open-source runtime.P4 Identity continuity FailPerplexity CometAssistant identity is the Perplexity account, and nothing lets others verify it is the same agent without Perplexity.P5 No kill switch FailPerplexity CometThe Assistant needs a Perplexity account and servers, and features are gated by plan, so the provider can disable or degrade it.P6 Capability independence FailPerplexity CometMemory, connectors, background assistants and agentic browsing are Perplexity-hosted services that do not survive a move to another model provider.T1 Open storage format PartialPerplexity CometLocal browsing data uses Chromium's on-device storage (largely SQLite and JSON), which ordinary tools can read. Assistant memory and threads sit in Perplexity's cloud in undocumented formats.T2 No hidden instructions FailPerplexity CometPerplexity does not show owners the Comet Assistant's system prompt or the tool instructions it adds to the model context.T3 No shadow memory FailPerplexity CometQueries sent to the Assistant are processed and kept by Perplexity, crash reports and IP data are collected, and consumer data is kept for model improvement by default. Provider-held data therefore exists outside owner-inspectable state.T4 Complete action history PartialPerplexity CometThe Assistant sidecar shows its reasoning and steps as it works, and threads persist in the account, but no complete record of every action and tool call is documented as available to the owner or leaving with the export.T5 Readable logic FailPerplexity CometThe Assistant's executable logic is proprietary and server-side. Owners can save prompts and shortcuts but cannot read the agent logic.T6 No third-party influence channel PartialPerplexity CometPerplexity says it does not send prompts or conversation content to advertisers, and it confirmed in 2026 that it is winding down its ads programme (sponsored follow-up questions). Owners cannot see or switch off how merchant and publisher partnerships affect ranking, and web-page content can inject instructions, as Brave's prompt-injection research showed.A1 No unrecorded actions FailPerplexity CometNo durable record of every consequential Assistant action is documented, nor that an action which cannot be recorded does not proceed.A2 Tamper evidence FailPerplexity CometThreads and local history can be deleted without a trace, and no other way to detect changes to an action record is documented.A3 Separation from the audited UnverifiedPerplexity CometPerplexity does not document whether the Assistant, which operates the browser, can alter or delete records of its own actions such as threads or history.A4 Readable with ordinary tools FailPerplexity CometThere is no audit trail of Assistant actions. Only threads, through the account export, and local browser history can be read.A5 Corroborated interactions FailPerplexity CometNo record of the Assistant's exchanges with other agents or services is documented that could be matched against a counterpart's record.V1 Open, reproducible runtime FailPerplexity CometComet is built on open-source Chromium, but Comet and its Assistant are proprietary and have no published reproducible builds.V2 Active config is inspectable config FailPerplexity CometOwners can see their settings but not the effective server-side configuration, such as system prompt, routing and model versions.V3 Attributable messages FailPerplexity CometThe Assistant acts through the owner's web sessions and Perplexity-held connector grants; recipients have no way to verify a message came from this agent under the owner's authority.V4 Independently checkable record FailPerplexity CometNo action record with checkable integrity exists, so nothing can be verified with open tools.V5 Comparable state FailPerplexity CometAgent state is split between the local profile and Perplexity's cloud, where memory and configuration are not fully exposed, so the owner cannot verify whether the whole state changed.M1 Instructions PartialPerplexity CometOwners can set personalization preferences and memories that shape responses. They cannot read or rewrite the Assistant's system instructions.M2 Memory PartialPerplexity CometSaved memories can be viewed, searched, filtered, deleted or turned off in Settings. Content-level editing and provider-side derived data are not fully exposed.M3 Logic PartialPerplexity CometOwners can create reusable prompts or shortcuts, and custom skills in the separate Perplexity Computer product. The Assistant's executable logic cannot be changed.M4 Tools and permissions PartialPerplexity CometOwners can allow or prohibit history access, navigation and site interaction, and can block specific sites. Pro, Max and Enterprise users can add custom remote MCP connectors.M5 Model choice FailPerplexity CometPaid plans can pick among Perplexity-hosted models, for example Claude Sonnet or Opus for the agent. Local or open-weight models are not supported, and Free users cannot choose.M6 No gatekeeping FailPerplexity CometModel selection, custom connectors and parallel background assistants are limited to paid tiers.C1 Communication boundaries PartialPerplexity CometOwners can block sites and disallow site interactions for the Assistant, and connector access needs approval. There is no documented control over recipients or channels, and whether site blocks are enforced outside the model has not been independently verified.C2 Approval gates PartialPerplexity CometOwners can have the Assistant ask before acting, per task or always. It pauses before logins and purchases, but the sensitive-action pause depends partly on the Assistant recognizing the action, and an 'Always Allow' mode removes confirmations.C3 Immediate halt PassPerplexity CometThe Assistant has a Stop button, and Perplexity documents that users can stop the agent at any time or pause its access.C4 Data sovereignty FailPerplexity CometBrowsing data stays local by default, but crash reports and IP data are sent even in Incognito. 'AI Data Retention' for model improvement is enabled by default on Free, Pro and Max, which is opt-out rather than opt-in.C5 Credential custody PartialPerplexity CometPasswords and payment methods stay in the local browser, and Perplexity says the Assistant does not access them. Connector grants such as Gmail are held by Perplexity, can be revoked, and do not travel with the owner.C6 Full deletion PartialPerplexity CometAccount deletion is self-serve, and Comet's help center describes permanent erasure after 30 days. The July 2026 privacy notice replaced its 30-day commitment with retention 'as long as reasonably necessary'.
SiriP1 Round-trip portability FailSiriIncomplete, delayed and not restorable: there is no export of Siri AI as an agent, Apple's asynchronous data copy request does not list Siri conversations or data, and nothing can be restored elsewhere.P2 Complete export FailSiriNo export captures Siri's configuration, instructions, conversation history, semantic index or logic; conversation history syncs through iCloud but cannot be taken out as the agent.P3 Independent execution FailSiriSiri AI runs only inside Apple's proprietary operating systems on supported Apple hardware, with complex requests routed to Apple's Private Cloud Compute. No free, open-source runtime can execute it.P4 Identity continuity FailSiriSiri's identity is the Apple Account and device, with requests tied to rotating device identifiers, so nobody can verify after a move that it is the same agent.P5 No kill switch FailSiriSiri AI depends on Apple's OS updates, Apple-signed PCC software and Apple servers, and Apple applies daily usage limits to server-dependent features. Apple can change or withdraw functionality remotely.P6 Capability independence FailSiriTools, personal context and app actions come from Apple's OS frameworks and Apple Foundation Models built with Google's Gemini. Announced Extensions let an installed app handle some generative requests, but Siri's capabilities cannot run on a local open-weight model.T1 Open storage format FailSiriSiri's state (semantic index, conversation history, settings) is held in undocumented system stores and end-to-end encrypted iCloud sync. No documented open format readable without Apple software is provided.T2 No hidden instructions FailSiriApple does not publish Siri's system or planner prompts, and owners cannot view the instructions placed in the model's context. Reporting on iOS 27 frameworks describes an internal Siri planner prompt and tool definitions not exposed to users.T3 No shadow memory PartialSiriPCC is designed to be stateless and Apple states PCC data is not retained. Apple does keep Siri request data, including transcripts, associated with rotating random identifiers for up to two years outside the owner-inspectable state, and a reviewed subset may be kept longer.T4 Complete action history PartialSiriThe Siri app shows conversation history across devices, and the exportable Apple Intelligence & PCC Report lists requests sent to Private Cloud Compute and Extensions. Neither is documented as a complete history of the app actions and tool calls Siri performed.T5 Readable logic FailSiriSiri's orchestration logic and models are closed and compiled into Apple's OS and server software. Owner-built Shortcuts are viewable in the Shortcuts app, but Siri's own logic is not available as readable source.T6 No third-party influence channel UnverifiedSiriApple states Siri request history is not used to build a marketing profile and is not sold, and no advertising in Siri AI has been reported. Apple publishes no policy on how web sources or third-party app content are ranked in Siri answers.A1 No unrecorded actions UnverifiedSiriApple does not document whether every consequential Siri action is durably recorded, or whether an action is blocked when it cannot be recorded.A2 Tamper evidence FailSiriApple's tamper-evident transparency log covers PCC software measurements, not Siri's actions, and Siri conversation history can be deleted without a detectable trace.A3 Separation from the audited UnverifiedSiriNo owner-facing record of Siri's actions is documented, so whether the agent can alter or delete it cannot be assessed.A4 Readable with ordinary tools PartialSiriThe Apple Intelligence & PCC Report is available in Settings and can be exported for review with general tools. It covers PCC and Extensions requests only, not on-device actions.A5 Corroborated interactions FailSiriSiri sends messages through Messages, Mail and third-party apps, and nothing documented lets Siri's record of an exchange be matched against the other side's.V1 Open, reproducible runtime FailSiriSiri AI and its OS runtime are proprietary. Apple publishes PCC software images for binary inspection and a subset of security-critical PCC source, which is not OSI-licensed or reproducible by owners.V2 Active config is inspectable config PartialSiriDevices only send data to PCC nodes whose attested software matches measurements in the public transparency log, extended to Google Cloud nodes with a verifiable hardware ledger. The owner cannot inspect the full active configuration, including prompts and on-device model settings.V3 Attributable messages FailSiriMessages Siri sends carry only the owner's account identity in Messages or Mail; recipients cannot verify that they came from Siri under the owner's authority, and nothing carries over after a migration.V4 Independently checkable record FailSiriApple's research tooling verifies PCC software against its transparency log, but nothing lets the owner check the integrity of a record of Siri's actions.V5 Comparable state FailSiriSiri's state sits in undocumented system stores and encrypted iCloud sync that the owner cannot access, so the owner cannot verify whether it changed between two points in time.M1 Instructions FailSiriOwners can adjust Siri's voice expressiveness and pace, but Apple documents no custom instructions and the underlying instructions cannot be read or rewritten.M2 Memory PartialSiriSiri app conversations can be deleted individually or auto-deleted after 30 days or one year, and Siri & Dictation history on Apple servers can be deleted. The personal semantic index and retained preference context cannot be viewed or edited item by item.M3 Logic PartialSiriOwners can build Shortcuts that Siri can run, adding their own workflows. Siri's core planning and execution logic cannot be changed.M4 Tools and permissions PartialSiriSiri gains tools from installed apps that expose App Intents, and owners can limit per-app Siri access and data sharing. New tools must come through apps distributed via Apple's platforms; arbitrary owner-defined tools or protocols are not documented.M5 Model choice PartialSiriApple Intelligence Extensions, announced at WWDC 2026, let owners pick an installed app's model (such as ChatGPT, Claude or Gemini) for on-demand generative requests; reports indicate it was not yet activatable in the launch beta. Apple's own models remain the core planner, and local open-weight models are not supported.M6 No gatekeeping FailSiriExtending Siri requires App Store–distributed apps subject to Apple review, and Siri AI requires specific recent Apple hardware. Owners cannot modify the agent outside Apple-approved channels.C1 Communication boundaries PartialSiriOS-level permissions, enforced below the model, govern which apps and data Siri can use, and owners can disable Siri per app. Owners cannot set which contacts or channels Siri may use for communication it initiates.C2 Approval gates PartialSiriApp Intents can require user confirmation before consequential actions, enforced by the OS. Which actions are gated is set by Apple and app developers, not selected by the owner.C3 Immediate halt PartialSiriSiri interactions are foreground and can be dismissed, and Siri can be turned off in Settings. Apple does not document halt semantics for multi-step actions already in progress.C4 Data sovereignty PartialSiriImprove Siri and Apple Intelligence analytics are opt-in, and PCC data is not stored or used beyond the request. Audio or transcripts, request metadata and location are still sent to Apple servers and retained, which the owner cannot confirm by network inspection.C5 Credential custody FailSiriSiri acts through apps and accounts whose credentials are held in Apple's OS and the apps themselves. Owners can revoke app permissions, but credentials are not inspectable as agent secrets and do not travel with an exportable agent.C6 Full deletion PartialSiriOwners can delete Siri app conversations and Siri & Dictation history, and can delete their Apple Account. Apple may retain a reviewed subset of Siri interactions beyond two years, and the memory layer is not covered by conversation auto-delete.
Microsoft Copilot CoworkP1 Round-trip portability FailMicrosoft Copilot CoworkIncomplete and not restorable: activity history exports as CSV and outputs download as a zip, but no export covers the Cowork agent's instructions, configuration or memory, and neither has an import.P2 Complete export FailMicrosoft Copilot CoworkNo documented export contains Cowork's instructions, configuration, memory, logic or identity; created files stay in OneDrive and prompts and responses are the only exported history, so the agent cannot be taken out whole.P3 Independent execution FailMicrosoft Copilot CoworkCowork runs in Microsoft's cloud, processing files in a temporary isolated environment inside the Microsoft 365 service boundary that users cannot view or access; there is no open-source runtime.P4 Identity continuity FailMicrosoft Copilot CoworkEvery action is authorized through the owner's Microsoft account, and nothing lets others verify the agent's continuity outside Microsoft.P5 No kill switch FailMicrosoft Copilot CoworkCowork exists only as a Microsoft-hosted service gated by subscription tier; Microsoft states Personal and Family subscribers lose access and must upgrade to Premium or Pro to run tasks.P6 Capability independence FailMicrosoft Copilot CoworkScheduling, event triggers, browser use, approvals and connectors are delivered by Microsoft's Cowork service and work only with the models it offers. Custom skills use the portable Agent Skills format, but no local model can drive them.T1 Open storage format PartialMicrosoft Copilot CoworkCustom skills are Markdown SKILL.md files and outputs are Office files in the owner's OneDrive, but task state and history are stored in an undocumented Microsoft service format.T2 No hidden instructions FailMicrosoft Copilot CoworkThe owner can see custom instructions and skill files, but Microsoft does not publish Cowork's system instructions or the built-in skill prompts it places in model context.T3 No shadow memory FailMicrosoft Copilot CoworkMicrosoft retains task logs, screenshots and outputs for unspecified periods for functionality, safety and troubleshooting, and some interactions undergo automated and human review for product improvement, outside the owner's inspectable state.T4 Complete action history PartialMicrosoft Copilot CoworkPrompts and responses are saved to review past tasks, progress updates are shown, and approval prompts can display action parameters, but no complete record of tool calls is available to the owner or exportable.T5 Readable logic PartialMicrosoft Copilot CoworkCustom and plugin skills are human-readable SKILL.md files, but the built-in skills and the orchestration code are proprietary and not exposed.T6 No third-party influence channel UnverifiedMicrosoft Copilot CoworkCowork documentation does not mention advertising, and Microsoft does not state whether the sponsored content served in consumer Copilot can appear in Cowork for personal accounts.A1 No unrecorded actions UnverifiedMicrosoft Copilot CoworkFor personal accounts, Microsoft does not document whether every consequential Cowork action is durably recorded or blocked when it cannot be; the unified audit log it describes is a tenant admin feature for work accounts.A2 Tamper evidence FailMicrosoft Copilot CoworkNo tamper-evident record of Cowork actions is available to personal-account owners, and the history they can see offers no way to detect edits or deletions.A3 Separation from the audited UnverifiedMicrosoft Copilot CoworkMicrosoft does not document whether Cowork can alter or delete records of its own actions.A4 Readable with ordinary tools PartialMicrosoft Copilot CoworkCopilot activity history exports as a CSV readable with ordinary tools, but it records prompts and responses rather than an action audit trail, and Cowork's inclusion is not stated.A5 Corroborated interactions FailMicrosoft Copilot CoworkNo record is documented that lets Cowork and the agents or services it messages match their logs of an exchange.V1 Open, reproducible runtime FailMicrosoft Copilot CoworkThe Cowork runtime is proprietary, closed-source Microsoft service code.V2 Active config is inspectable config FailMicrosoft Copilot CoworkThe owner can inspect custom instructions, installed plugins, skills and the chosen model, but not the full server-side configuration, system prompt or built-in policies Cowork runs with.V3 Attributable messages FailMicrosoft Copilot CoworkEmails and messages Cowork sends are authorized through the owner's Microsoft account, and recipients cannot verify that they came from this agent.V4 Independently checkable record FailMicrosoft Copilot CoworkNo action record is available to owners whose integrity can be checked with open tools that do not depend on Microsoft.V5 Comparable state FailMicrosoft Copilot CoworkThe owner cannot obtain Cowork's full state, so cannot verify whether it changed between two points in time.M1 Instructions PartialMicrosoft Copilot CoworkThe owner can write up to 20 KB of custom instructions that Cowork applies to every task, but cannot read or rewrite its underlying system instructions.M2 Memory UnverifiedMicrosoft Copilot CoworkCowork documentation does not describe a memory store or item-level memory controls, and Microsoft says memories saved by Copilot Tasks do not migrate to Cowork.M3 Logic PartialMicrosoft Copilot CoworkOwners can create, edit, upload and delete SKILL.md skills and manage scheduled prompts, but Microsoft's support page documents custom skills only for work or school accounts, and built-in skills cannot be changed.M4 Tools and permissions PartialMicrosoft Copilot CoworkOwners can add, toggle and remove plugins and connectors, and plugins can wrap remote MCP servers, but connectors must be HTTPS remote servers packaged as Microsoft 365 app packages, and personal-account support for uploaded plugins is not documented.M5 Model choice FailMicrosoft Copilot CoworkThe owner can pick among Microsoft-offered GPT and Claude models or Auto, but cannot use arbitrary or local open-weight models.M6 No gatekeeping FailMicrosoft Copilot CoworkCowork for personal accounts requires a Microsoft 365 Premium or Pro subscription, and changes beyond exposed settings require Microsoft's action.C1 Communication boundaries PartialMicrosoft Copilot CoworkApproval prompts before emails and Teams posts can be scoped by recipient or domain, but owners cannot set allowed recipients or channels in advance, and enforcement below the model is not documented.C2 Approval gates PartialMicrosoft Copilot CoworkCowork requires approval before sensitive actions such as sending email, posting or scheduling, and automated tasks prepare actions for approval by default. The gated actions are chosen by Microsoft, and annotation-based gating for third-party MCP tools is still rolling out.C3 Immediate halt PassMicrosoft Copilot CoworkMicrosoft documents a hard pause that stops Cowork immediately, plus cancel for the current task, and scheduled prompts can be paused or cancelled.C4 Data sovereignty FailMicrosoft Copilot CoworkAll task content is processed on Microsoft servers and by Anthropic as a subprocessor, and some interactions undergo automated and human review for product improvement without an opt-in. Microsoft says Copilot content in Microsoft 365 apps isn't used to train foundation models.C5 Credential custody PartialMicrosoft Copilot CoworkOwners can disconnect connectors, and local-browser credentials and cookies stay on the device, but plugin OAuth credentials are held in Microsoft's token store, cannot be inspected, and cannot move with the agent.C6 Full deletion PartialMicrosoft Copilot CoworkOwners can delete Copilot activity history, skills and scheduled prompts, but Microsoft keeps Cowork task logs, screenshots and outputs for unspecified 'limited periods' rather than disclosed legal minimums.
Microsoft CopilotP1 Round-trip portability FailMicrosoft CopilotIncomplete and not restorable: 'Export all activity history' downloads only a CSV of prompts and responses, and Microsoft offers no import.P2 Complete export FailMicrosoft CopilotThe documented export contains only prompts and responses; instructions, configuration, task definitions and identity are not included, and saved memories are not documented as included, so most of what defines the agent stays with Microsoft.P3 Independent execution FailMicrosoft CopilotCopilot runs only as a Microsoft-hosted service on Microsoft-selected models; there is no exportable artifact or open-source runtime to execute it locally.P4 Identity continuity FailMicrosoft CopilotThe agent is tied to the owner's Microsoft account and cannot migrate, so nobody it has dealt with can verify its continuity elsewhere.P5 No kill switch FailMicrosoft CopilotBecause the agent exists only as a hosted service tied to a Microsoft account, Microsoft controls its availability and features; there is no exported agent beyond its reach.P6 Capability independence FailMicrosoft CopilotMemory, connectors, browsing and Tasks are delivered by Microsoft's service on Microsoft-selected models and do not exist apart from that platform.T1 Open storage format PartialMicrosoft CopilotActivity history exports as CSV, an open format, but Copilot's internal state storage is undocumented and not directly accessible to the owner.T2 No hidden instructions FailMicrosoft CopilotMicrosoft does not publish Copilot's system instructions or show the owner what the service injects into model context, such as memories or personalization signals.T3 No shadow memory FailMicrosoft CopilotMicrosoft states that, depending on settings, Copilot conversation history is used to further personalize ads, and Copilot can share signals with Bing, Edge and MSN; this derived data sits outside the owner's inspectable agent state.T4 Complete action history PartialMicrosoft CopilotPrompts, responses and browsing actions are kept in conversation history, past Tasks can be reviewed, and activity history exports as CSV. Tool calls are not documented as captured, and browsing screenshots are kept only 30 days, so the history is not complete.T5 Readable logic FailMicrosoft CopilotCopilot's executable logic is proprietary server-side code; Tasks are described in natural language, but the workflows that run them are not exposed as readable source.T6 No third-party influence channel FailMicrosoft CopilotMicrosoft Advertising serves ads labeled 'Sponsored' in Copilot responses, selected using the whole conversation. Ad personalization can be turned off, but Microsoft documents no setting that turns off the ads themselves.A1 No unrecorded actions UnverifiedMicrosoft CopilotMicrosoft does not document whether every consequential action in Tasks or browsing is durably recorded, or whether an action is blocked when it cannot be recorded.A2 Tamper evidence FailMicrosoft CopilotConversation history can be deleted without a detectable trace, and no tamper-evident record of actions is documented.A3 Separation from the audited UnverifiedMicrosoft CopilotMicrosoft does not document whether the agent layer can alter or delete records of its own actions.A4 Readable with ordinary tools PartialMicrosoft CopilotExported activity history is a CSV readable with ordinary tools, but it records prompts and responses, not a full action audit trail.A5 Corroborated interactions FailMicrosoft CopilotNo record is documented that lets Copilot and the agents or services it messages match their logs of an exchange.V1 Open, reproducible runtime FailMicrosoft CopilotThe Copilot runtime is proprietary and closed source.V2 Active config is inspectable config FailMicrosoft CopilotThe owner can see only personalization and memory settings; the full server-side configuration the service runs with is not inspectable.V3 Attributable messages FailMicrosoft CopilotEmails and messages go out under the connected accounts' own authentication, so recipients cannot verify that they came from this agent under the owner's authority.V4 Independently checkable record FailMicrosoft CopilotNo action record is offered whose integrity can be checked with open tools that do not depend on Microsoft.V5 Comparable state FailMicrosoft CopilotThe owner cannot obtain the agent's full state, so cannot verify whether it changed between two points in time.M1 Instructions PartialMicrosoft CopilotThe owner can shape responses through saved memories and personalization, but cannot read or rewrite Copilot's underlying system instructions.M2 Memory PartialMicrosoft CopilotSaved memories can be viewed, edited and deleted individually or all at once, and memory can be switched off. Personalization signals shared with Bing, Edge and MSN cannot be managed item by item in Copilot.M3 Logic FailMicrosoft CopilotThe owner can create and schedule Tasks in natural language but cannot change the agent's underlying code or workflows.M4 Tools and permissions PartialMicrosoft CopilotThe owner can link or unlink the connectors Microsoft offers (for example Outlook, OneDrive, Gmail and Google Drive) and turn off web search, but cannot add arbitrary third-party tools.M5 Model choice FailMicrosoft CopilotCopilot runs on models Microsoft selects; the owner cannot choose arbitrary or local open-weight models.M6 No gatekeeping FailMicrosoft CopilotChanges beyond the settings Microsoft exposes (instructions, logic, models) require Microsoft's own action and are not open to the owner.C1 Communication boundaries PartialMicrosoft CopilotOwners control which connectors are linked, and Copilot asks before sending emails or messages, but owners cannot set which recipients or channels are allowed, and no enforcement below the model is documented.C2 Approval gates PartialMicrosoft CopilotCopilot requires approval before purchases, submitting personal information, sending messages and deleting files, but the gated actions are fixed by Microsoft rather than chosen by the owner.C3 Immediate halt PassMicrosoft CopilotMicrosoft documents that a running task can be stopped at any time, scheduled tasks can be paused or deleted, and the owner can interrupt or take control of browsing sessions.C4 Data sovereignty FailMicrosoft CopilotAll content is processed on Microsoft servers, and conversations may be used for model training unless the owner opts out (with some regional and age exclusions); they may also inform ad personalization.C5 Credential custody PartialMicrosoft CopilotThe owner can revoke connectors at any time, but Microsoft holds the OAuth grants, the owner cannot inspect them, and they cannot move with the agent.C6 Full deletion PartialMicrosoft CopilotThe owner can delete individual conversations, all activity history and memories; conversations are otherwise kept 18 months by default. Microsoft does not fully document retention of derived or de-identified data after deletion.
ManusP1 Round-trip portability FailManusIncomplete and not restorable in one action: the 2026 Data Backup Tool omits Knowledge, connector credentials and logic, and its encrypted archives are produced in several steps and restore only into Manus through a separate portal. Outside that window, only individual files and skills can be downloaded.P2 Complete export PartialManusThe backup covers tasks, generated files and configuration data, but the docs do not say it includes Knowledge entries, connector credentials or the agent's executable logic, or anything that identifies the agent.P3 Independent execution FailManusBackup archives are meant to be restored only through Manus's own restoration tool, and the agent runtime is not distributed. No exported artifact runs on an open-source runtime.P4 Identity continuity FailManusAgent identity is the Manus account, and nothing lets peers verify it is the same agent after a migration.P5 No kill switch FailManusThe agent runs only on Manus infrastructure, so the provider can suspend or change it at any time. The 2026 regulatory deletion of data for some accounts showed this in practice.P6 Capability independence FailManusTools, sandbox, connectors, scheduling and memory are all provided by Manus's hosted platform, and none of them survive a move to another model provider or runtime.T1 Open storage format PartialManusAgent state is stored server-side in an undocumented format, and backups are encrypted archives. Manus documents a plaintext export of task data for team members, and skills are plain Markdown plus scripts.T2 No hidden instructions FailManusManus does not publish or show owners the system prompt and tool definitions it places in the model context. Versions that circulate publicly come from unofficial extraction.T3 No shadow memory FailManusManus processes prompts and usage data server-side and uses de-identified or aggregated data to improve its services. Its web client loads third-party analytics (Amplitude, Sentry, FingerprintJS), so provider-held data exists outside the owner's inspectable state.T4 Complete action history PartialManusEach task shows its step-by-step actions and can be shared as a replay link, but the history lives on Manus servers, backups are encrypted, and no complete owner-held record of tool calls leaves with the agent.T5 Readable logic PartialManusOwner-created skills are stored as human-readable SKILL.md files with optional scripts. The core agent loop and orchestration logic are closed source.T6 No third-party influence channel UnverifiedManusNo advertising or sponsored-content channel into the agent's context is documented, but no public commitment rules one out either.A1 No unrecorded actions FailManusTask views show steps, but no durable record of every consequential action is documented, nor that an action which cannot be recorded does not proceed.A2 Tamper evidence FailManusOwners can permanently delete tasks, and deleted tasks cannot be recovered, so deletions from the action record are not detectable.A3 Separation from the audited UnverifiedManusManus does not document whether the agent can alter or delete the task records of its own actions.A4 Readable with ordinary tools FailManusTask records are readable only through the Manus UI or API. Backup archives are encrypted and cannot be read with general-purpose tools.A5 Corroborated interactions FailManusNo record of the agent's exchanges with other agents or services is documented that could be matched against a counterpart's record.V1 Open, reproducible runtime FailManusThe Manus runtime is proprietary and not published under an OSI-approved license.V2 Active config is inspectable config FailManusThe effective configuration, including system instructions and model routing, is not visible to the owner, so it cannot be checked against what the owner inspects.V3 Attributable messages FailManusOutbound messages (email, Slack, Telegram, connectors) go through Manus-held accounts or tokens; recipients have no documented way to verify they came from this agent under the owner's authority.V4 Independently checkable record FailManusTask records are readable only through Manus and backups are encrypted, so the record's integrity cannot be checked with open tools.V5 Comparable state FailManusState sits server-side and exports are encrypted, so the owner cannot verify whether the agent's state changed between two points in time.M1 Instructions PartialManusOwners can write Knowledge entries, project-level instructions and skills. They cannot read or rewrite the platform system prompt.M2 Memory PartialManusKnowledge entries can be viewed and deleted, subject to per-plan caps (for example 50 on Free, 100 on Pro). Any derived memory or usage data held by the provider is not exposed for editing.M3 Logic PartialManusOwners can create, edit, import and export skills, including scripts. The underlying agent logic cannot be modified.M4 Tools and permissions PartialManusOwners can add custom MCP and API connectors with OAuth-scoped permissions, and can limit local access to chosen folders. Built-in sandbox tools cannot be removed or re-scoped below the platform level.M5 Model choice FailManusOwners can choose only among Manus-defined agent tiers (for example 1.6 Lite, 1.6, 1.6 Max). There is no option for other providers or local open-weight models.M6 No gatekeeping FailManusStronger agent tiers and higher Knowledge limits require paid plans, and the e-discovery export requires provider approval.C1 Communication boundaries UnverifiedManusConnectors can be enabled or disconnected per app, but owners have no documented way to decide which recipients or peers the agent may contact, enforced outside the model.C2 Approval gates PartialManusIn the desktop app, every local command requires explicit approval ('Allow Once' or 'Always Allow'). No equivalent owner-configurable gates are documented for cloud-sandbox or connector actions.C3 Immediate halt PartialManusBrowser Operator tasks can be stopped by closing the dedicated tab, and scheduled tasks can be toggled off. The desk review found no documented guarantee of an immediate stop for cloud-sandbox tasks.C4 Data sovereignty FailManusThird-party policy analyses of the April 2026 policy report a training opt-out setting, not opt-in, and Manus says it uses de-identified or aggregated data to improve its services. The web client also loads third-party analytics and error telemetry.C5 Credential custody PartialManusConnectors use OAuth and can be disconnected by the owner. The tokens and API keys are stored by Manus and do not travel with any export.C6 Full deletion PartialManusSelf-serve account deletion is irreversible. Manus may keep some personal data for legal, accounting, claims-defence and fraud-prevention purposes without a stated period.
ChatGPT AtlasP1 Round-trip portability FailChatGPT AtlasIncomplete, delayed and not restorable: before the August 2026 shutdown only bookmarks, pages and ChatGPT chats (via the emailed export) could be saved, and no import restored the Atlas agent, its browser memories or configuration.P2 Complete export FailChatGPT AtlasNo export captured browser memories, agent configuration or agent logic; only bookmarks, pages and ChatGPT chat history could be saved, so most of what defined the agent stayed with OpenAI.P3 Independent execution FailChatGPT AtlasAtlas was proprietary software built on Chromium, and its assistant and agent features required OpenAI's servers; no open-source runtime can execute the agent.P4 Identity continuity FailChatGPT AtlasThe agent's identity was the OpenAI account, and nothing let sites or other parties verify its continuity outside OpenAI.P5 No kill switch FailChatGPT AtlasOpenAI discontinued Atlas, and it stopped working on August 9, 2026, about 30 days after the announcement. This shows the provider could unilaterally end the agent's operation.P6 Capability independence FailChatGPT AtlasThe sidebar assistant, browser memories and agent mode all ran on OpenAI's hosted models and services, and none of them worked with another model provider.T1 Open storage format UnverifiedChatGPT AtlasOpenAI did not document Atlas's local storage format. Chromium conventionally uses SQLite, but whether Atlas state (including browser memories held server-side) was readable without OpenAI software was not verified.T2 No hidden instructions FailChatGPT AtlasThe assistant and agent ran on ChatGPT with system-level instructions that were not visible to the user.T3 No shadow memory FailChatGPT AtlasBrowser-memory processing and ChatGPT conversations were handled on OpenAI servers under ChatGPT's retention policies. OpenAI stated that page summaries were deleted within about seven days, but provider-side logs were not fully inspectable by the owner.T4 Complete action history PartialChatGPT AtlasAgent-mode sessions appeared in the ChatGPT conversation and browsing history stayed in the browser, but no complete record of agent actions and tool calls was documented as available to the owner or exportable.T5 Readable logic FailChatGPT AtlasAtlas had no owner-authored skills or workflows stored as readable source, and its agent logic was closed source.T6 No third-party influence channel UnverifiedChatGPT AtlasPublic documentation did not state whether ChatGPT ads appeared in the Atlas sidebar or agent flows. Third-party web content entered the agent's context, and OpenAI acknowledged prompt-injection risk.A1 No unrecorded actions UnverifiedChatGPT AtlasOpenAI did not document whether every consequential agent action was durably recorded, or whether an action was blocked when it could not be recorded.A2 Tamper evidence FailChatGPT AtlasBrowsing history and chats, the owner-visible record, could be deleted without a detectable trace, and no tamper-evident record of agent actions was documented.A3 Separation from the audited UnverifiedChatGPT AtlasOpenAI did not document whether the agent could alter or delete records of its own actions.A4 Readable with ordinary tools UnverifiedChatGPT AtlasIt is not documented whether agent-mode action records were readable with general-purpose tools beyond the chat transcripts included in the ChatGPT export.A5 Corroborated interactions FailChatGPT AtlasNo documented record let Atlas's agent and other agents or services match their logs of an exchange.V1 Open, reproducible runtime FailChatGPT AtlasAtlas was proprietary software built on the open-source Chromium project; its own code was not released under an OSI-approved license.V2 Active config is inspectable config FailChatGPT AtlasThe agent's active configuration included server-side instructions and model settings that the owner could not inspect.V3 Attributable messages FailChatGPT AtlasThe agent acted through the owner's browser sessions, and recipients had no way to verify that an action came from this agent under the owner's authority.V4 Independently checkable record FailChatGPT AtlasNo action record was offered whose integrity could be checked with open tools that do not depend on OpenAI.V5 Comparable state FailChatGPT AtlasAgent state was split between the local browser and OpenAI servers and was not fully exposed, so the owner could not verify whether it had changed between two points in time.M1 Instructions PartialChatGPT AtlasChatGPT custom instructions applied to the Atlas sidebar and agent, but the system-level instructions could not be read or rewritten.M2 Memory PartialChatGPT AtlasBrowser memories were optional and could be viewed, archived or deleted, and deleting browsing history deleted the associated browser memories. Direct editing of individual memory items was not documented.M3 Logic FailChatGPT AtlasOwners could not change the agent's executable logic, and Atlas offered no user-defined skills or workflows.M4 Tools and permissions PartialChatGPT AtlasOwners could control per-site ChatGPT page visibility and choose logged-in or logged-out agent mode. By design, the agent could not access the file system, saved passwords or autofill, and owners could not add their own tools to the agent.M5 Model choice FailChatGPT AtlasOnly OpenAI models were available, and local or third-party models could not be used.M6 No gatekeeping FailChatGPT AtlasAgent mode was limited to Plus, Pro and Business plans at launch, so a core capability depended on a paid tier.C1 Communication boundaries PartialChatGPT AtlasOwners could block ChatGPT from specific sites and run the agent logged out, which limited its reach, but could not define which recipients, peers or channels it could contact, and enforcement below the model was not documented.C2 Approval gates PartialChatGPT AtlasAgent mode paused for user oversight on sensitive sites such as financial institutions and asked for confirmation before consequential actions. Owners could not configure which actions required approval.C3 Immediate halt PassChatGPT AtlasOwners could stop agent mode at any time from the browser interface.C4 Data sovereignty PartialChatGPT AtlasUsing browsing content for training was off by default ('Include web browsing' opt-in). Page content shared with ChatGPT and all chats were still processed on OpenAI servers, and chats followed ChatGPT's default-on training setting.C5 Credential custody PartialChatGPT AtlasSite sessions used by logged-in agent mode lived in the local browser profile, and the agent could not access saved passwords. The OpenAI account and any ChatGPT connectors remained under provider custody, and credentials did not travel with an agent.C6 Full deletion PartialChatGPT AtlasOwners could delete browsing history, which removed associated browser memories, and could delete their ChatGPT account under the 30-day deletion policy. OpenAI's public notice did not specify how server-side Atlas data was handled after discontinuation.
GrokP1 Round-trip portability FailGrokIncomplete and not restorable: 'Download account data' exports account data and conversations as a ZIP of JSON without logic or configuration, and xAI offers no import.P2 Complete export PartialGrokThe account export contains account data and conversation history, but not the executable logic, runtime configuration or anything that identifies the agent, so much of what defines it stays with xAI.P3 Independent execution FailGrokGrok runs only on xAI's hosted service and current proprietary models; no exported artifact runs on an open-source runtime.P4 Identity continuity FailGrokThe assistant's identity is the user's xAI or X account, and nothing lets others verify it is the same agent without xAI.P5 No kill switch FailGrokThe agent exists only as an xAI-hosted service, so xAI controls its availability and features, and nothing exported runs independently.P6 Capability independence FailGrokMemory, Tasks, Companions and connectors are xAI service features and do not survive a move to another model or runtime.T1 Open storage format PartialGrokThe account export is JSON, an open format, but Grok's internal state storage is undocumented and the owner cannot access it directly.T2 No hidden instructions PartialGrokxAI publishes Grok's system prompts in a public GitHub repository. Content injected at runtime, such as memories and tool results, is not fully shown, and the owner cannot confirm the published prompts are the ones in use.T3 No shadow memory FailGrokxAI's privacy policy lists delivering relevant content and targeted advertising among its uses of data, and allows retaining de-identified or pseudonymized conversation data after deletion. That data is outside the owner's inspectable state.T4 Complete action history PartialGrokConversation history is visible to the owner and included in the export, but xAI documents no complete history of tool calls and Task actions.T5 Readable logic FailGrokPrompts are published, but Grok's executable logic (tool orchestration, Tasks, Companions) is proprietary server-side code.T6 No third-party influence channel UnverifiedGrokX announced in 2025 that advertisers could pay for placement in Grok's answers, and xAI's privacy policy permits targeted advertising. No primary documentation confirms whether ads appear in consumer Grok today or whether owners can turn them off.A1 No unrecorded actions FailGrokNo durable record of consequential actions is available to the owner; the only visible record is conversation history, which the owner can delete.A2 Tamper evidence FailGrokConversations can be deleted without any detectable trace, and no other way to detect changes to an action record is documented.A3 Separation from the audited UnverifiedGrokxAI does not document whether the agent layer can alter or delete records of its own actions.A4 Readable with ordinary tools PartialGrokThe JSON export can be read with ordinary tools, but it is a conversation and account export, not an action audit trail.A5 Corroborated interactions FailGrokNo record of the agent's exchanges with other agents or services is available to the owner, so nothing can be matched against a counterpart's record.V1 Open, reproducible runtime FailGrokThe Grok service runtime is proprietary. xAI has released some older model weights and publishes prompts, but not the assistant runtime.V2 Active config is inspectable config FailGrokPublished prompts cover part of the configuration, but the owner cannot confirm that the served configuration (prompts, model routing, memory injection) matches what is inspectable.V3 Attributable messages FailGrokRecipients have no documented way to verify that a message came from this agent under its owner's authority, independently of xAI.V4 Independently checkable record FailGrokNo action record with checkable integrity is exposed, so nothing can be verified with open tools independently of xAI.V5 Comparable state FailGrokMuch of the agent's state (runtime configuration, memory injection, retained derived data) is held by xAI and not exposed, so the owner cannot verify whether it changed between two points in time.M1 Instructions PartialGrokThe owner can read the published base prompts and add personal customizations and memories, but cannot rewrite the system instructions Grok runs with.M2 Memory PartialGrokxAI states that memories are visible and can be forgotten, and memory can be turned off under Data Controls. Editing individual memories is not documented, and data retained outside memory cannot be managed.M3 Logic FailGrokThe owner can define Tasks in natural language but cannot change Grok's underlying code or workflows.M4 Tools and permissions PartialGrokThe owner can connect or disconnect the integrations xAI offers, such as Google apps via OAuth, but cannot add arbitrary third-party tools in the consumer app.M5 Model choice FailGrokThe consumer app offers only xAI's own Grok models; local or third-party models cannot be used.M6 No gatekeeping FailGrokChanges beyond the settings xAI exposes require xAI's own action, and some features depend on paid subscription tiers.C1 Communication boundaries UnverifiedGrokNo public documentation was found on whether owners can decide whom Grok's agentic features contact or through which channels, or how that would be enforced.C2 Approval gates UnverifiedGrokNo public documentation was found on approval gates for Grok Tasks or connector actions.C3 Immediate halt UnverifiedGrokOwners can stop responses in the chat interface, but no primary documentation was found on immediately halting running or scheduled Tasks.C4 Data sovereignty FailGrokContent is processed on xAI servers. Training use is controlled by an 'Improve the model' setting rather than an opt-in xAI documents, unauthenticated users in some regions cannot opt out, and voluntarily submitted feedback may still be used for training.C5 Credential custody PartialGrokGoogle connections use OAuth, which the owner can revoke from their Google account, and xAI commits not to train on Google Apps content. The tokens are held by xAI, cannot be inspected in Grok, and cannot move with the agent.C6 Full deletion PartialGrokDeleting conversations or the account removes data within 30 days, except data that has been de-identified or pseudonymized and disassociated from the account, or must be kept for safety, security or legal reasons.
Meta AIP1 Round-trip portability FailMeta AIIncomplete, delayed and not restorable: the asynchronous export from Data & privacy settings or Accounts Center carries chat history but not the assistant's instructions or configuration, and Meta documents no import.P2 Complete export PartialMeta AIThe export carries the owner's Meta AI information, including chat history, but Meta does not document it as including the assistant's instructions, configuration, logic or identity, so what defines the agent stays with Meta.P3 Independent execution FailMeta AIMeta AI runs only on Meta's servers and models; no artifact runs on an open-source runtime.P4 Identity continuity FailMeta AIThe assistant's identity is the user's Meta account, and nothing lets others verify it is the same agent without Meta.P5 No kill switch FailMeta AIThe agent exists only as a Meta-hosted service, so Meta controls its availability and features, and nothing exported runs independently.P6 Capability independence FailMeta AIMemory, connectors, shopping and agent features exist only as Meta platform services on Meta's models; none of them survive a move to another model or runtime.T1 Open storage format PartialMeta AIExports are available in machine-readable JSON or HTML, but Meta AI's internal state storage is undocumented and the owner cannot access it directly.T2 No hidden instructions FailMeta AIMeta does not publish Meta AI's system instructions or show what it adds to model context, including signals drawn from Facebook and Instagram activity.T3 No shadow memory FailMeta AISince 2025-12-16, Meta uses interactions with its AI to personalize content and ads across its apps in most regions (excluding the EU, UK and South Korea); the resulting derived data is not part of an inspectable agent state.T4 Complete action history PartialMeta AIChat history is visible to the owner and included in exports, but Meta documents no complete history of the Muse agent's actions and tool calls that the owner can see or take away.T5 Readable logic FailMeta AIMeta AI's executable logic is proprietary server-side code that is not exposed as readable source.T6 No third-party influence channel UnverifiedMeta AIMeta has not documented whether sponsored content or commerce partners (Meta states it earns transaction fees from Muse purchases through partners such as Shopify and Stripe) influence Meta AI's recommendations, or whether owners can see or turn off such influence.A1 No unrecorded actions FailMeta AINo durable record of consequential actions is available to the owner; the only visible record is chat history, which the owner can delete.A2 Tamper evidence FailMeta AIChat history, the only visible record, can be deleted without any detectable trace, and no other way to detect changes to an action record is documented.A3 Separation from the audited UnverifiedMeta AIMeta does not document whether the agent layer can alter or delete records of its own actions.A4 Readable with ordinary tools PartialMeta AIExports in JSON or HTML can be read with ordinary tools, but they are account-data exports, not an action audit trail.A5 Corroborated interactions FailMeta AINo record of the agent's exchanges with other agents or services is available to the owner, so nothing can be matched against a counterpart's record.V1 Open, reproducible runtime FailMeta AIThe Meta AI service runtime is proprietary. Meta has released some Llama model weights, but not the assistant's runtime.V2 Active config is inspectable config FailMeta AIThe owner sees only memory and privacy settings; the configuration the service actually runs with is not inspectable.V3 Attributable messages FailMeta AIRecipients have no documented way to verify that a message came from this agent under its owner's authority, apart from Meta's own platform identity.V4 Independently checkable record FailMeta AINo action record with checkable integrity is exposed, so nothing can be verified with open tools independently of Meta.V5 Comparable state FailMeta AIMuch of the agent's state (instructions, configuration, personalization signals) is held by Meta and not exposed, so the owner cannot verify whether it changed between two points in time.M1 Instructions PartialMeta AIThe owner can ask Meta AI to remember preferences, which shapes later responses, but cannot read or rewrite its underlying instructions.M2 Memory PartialMeta AISaved memories can be viewed and deleted in settings, but Meta does not document editing, and personalization also uses Facebook and Instagram signals that are not managed as memory items.M3 Logic FailMeta AIThe owner cannot change Meta AI's skills, workflows or code.M4 Tools and permissions PartialMeta AIPress reports on the September 2026 Muse rollout describe a connector platform with third-party integrations. Owners choose among connectors Meta admits, and scoping controls are not documented publicly.M5 Model choice FailMeta AIMeta AI runs on Meta-selected models; the owner cannot substitute another or a local model within the product.M6 No gatekeeping FailMeta AIChanges beyond the settings Meta exposes (instructions, logic, models) require Meta's own action and are not open to the owner.C1 Communication boundaries UnverifiedMeta AIMeta has not publicly documented whether owners can decide whom Muse contacts or through which channels, or how such limits would be enforced, though it reportedly sends email from a dedicated address and acts across connected apps.C2 Approval gates UnverifiedMeta AIPublic sources describe Muse completing purchases through Shop Pay, Stripe and PayPal, but no primary documentation of approval gates was found.C3 Immediate halt UnverifiedMeta AINo primary documentation was found on how an owner immediately halts a running Muse task.C4 Data sovereignty FailMeta AIContent is processed on Meta's servers and used to personalize content and ads across Meta apps, with no dedicated opt-out in most regions. Meta also uses AI interactions to improve its models, with objection rights mainly in jurisdictions such as the EU and UK.C5 Credential custody UnverifiedMeta AIMeta has not publicly documented how Muse connector tokens are stored, inspected or revoked; they are held by Meta and cannot move with the agent.C6 Full deletion PartialMeta AIThe owner can delete all chats and media and individual memories, and can delete the Meta account. Deletion does not reverse data already used for personalization or model training, and full retention terms are set by Meta's general privacy policy.
GensparkP1 Round-trip portability FailGensparkIncomplete, delayed and not restorable: no self-serve export of the agent is documented, a copy of personal data comes only by email request, and there is nothing to import; only individual outputs can be downloaded.P2 Complete export FailGensparkNo export containing the agent's configuration, instructions, memory, history, credentials or logic is documented; only individual deliverables and some SecondBrain recordings can be downloaded.P3 Independent execution FailGensparkThe Super Agent runs only in Genspark's cloud sandbox. No runtime is distributed for independent execution.P4 Identity continuity FailGensparkAgent identity is the Genspark account, and nothing lets others verify it is the same agent without Genspark.P5 No kill switch FailGensparkThe agent depends on Genspark's servers, account and credits, so the provider can suspend or degrade it.P6 Capability independence FailGensparkTools (80+ in-house), the sandbox, SecondBrain memory, integrations and scheduling are Genspark platform features, and none of them survive a move to an owner-chosen model or runtime.T1 Open storage format FailGensparkAgent state is stored on Genspark's Azure-hosted servers in an undocumented format, and no open-format export of that state is documented.T2 No hidden instructions FailGensparkGenspark does not disclose the system instructions and orchestration prompts its Mixture-of-Agents layer places in model context.T3 No shadow memory FailGensparkThe privacy policy says Genspark automatically collects prompts and outputs and uses information for data analysis and service improvement, and it shares usage data with analytics vendors such as Google Analytics.T4 Complete action history PartialGensparkConversation and task history and Call For Me transcripts are visible in the product, but no complete record of tool calls is documented as available to the owner or exportable.T5 Readable logic FailGensparkThe orchestration logic is proprietary, and the storage format of saved skills and custom agents is not documented as readable source.T6 No third-party influence channel UnverifiedGensparkThe policy states that Genspark does not sell personal data or use it for targeted advertising. It does not say whether partners or merchants can influence agent context or rankings.A1 No unrecorded actions FailGensparkNo durable record of every consequential action is documented, nor that an action which cannot be recorded does not proceed.A2 Tamper evidence FailGensparkNo action record is documented whose edits or deletions would be detectable.A3 Separation from the audited UnverifiedGensparkGenspark does not document whether the agent can alter or delete records of its own actions.A4 Readable with ordinary tools FailGensparkNo audit trail is available outside the Genspark UI.A5 Corroborated interactions FailGensparkNo record of the agent's exchanges with other agents or services is documented that could be matched against a counterpart's record.V1 Open, reproducible runtime FailGensparkThe Super Agent runtime is proprietary. Genspark's open-source GenOffice project (Apache-2.0) is a separate office suite, not the agent runtime.V2 Active config is inspectable config FailGensparkModel routing and agent configuration are chosen automatically server-side and are not visible to the owner.V3 Attributable messages FailGensparkOutbound actions (email, calls, integrations) go through Genspark-held accounts and tokens; recipients have no way to verify they came from this agent under the owner's authority.V4 Independently checkable record FailGensparkNo action record with checkable integrity exists, so nothing can be verified with open tools.V5 Comparable state FailGensparkState is held server-side and not exposed, so the owner cannot verify whether it changed between two points in time.M1 Instructions PartialGensparkOwners can describe and refine custom Super Agents and skills in natural language. Genspark auto-configures their architecture, and platform instructions are not editable.M2 Memory PartialGensparkSecondBrain recordings can be reviewed, edited, downloaded or deleted, and integrations can be disconnected. Item-level editing of all derived memory is not documented.M3 Logic PartialGensparkOwners can save workflows as reusable skills and build custom Super Agents. The core agent logic cannot be modified.M4 Tools and permissions PartialGensparkOwners can add custom MCP servers (Streamable HTTP, with custom headers) from the Tools menu and can connect or disconnect integrations. Fine-grained scoping or removal of built-in tools is not documented.M5 Model choice FailGensparkThe Super Agent routes tasks automatically across Genspark-selected hosted models, with model-tier options in some areas. Local or open-weight models cannot be used.M6 No gatekeeping FailGensparkUse is metered by credits, and limits such as file size (500 MB free versus 1 GB paid) and higher model tiers depend on the paid plan.C1 Communication boundaries UnverifiedGensparkIntegrations require explicit authorization and can be disconnected, but owners have no documented way to decide which recipients or channels the agent may use, enforced outside the model.C2 Approval gates PartialGensparkCall For Me requires the owner to press 'Place Call', and scheduled calls can be cancelled. Owner-configurable approval gates for other Super Agent actions are not documented.C3 Immediate halt UnverifiedGensparkScheduled calls can be cancelled beforehand. The desk review found no documentation of an immediate halt for running Super Agent tasks.C4 Data sovereignty FailGensparkPrompts and outputs are collected automatically and used to evaluate and improve the service, and usage data goes to analytics vendors. The policy documents no opt-in for use in model improvement, though it excludes Google Workspace data from model training.C5 Credential custody PartialGensparkIntegrations need explicit OAuth authorization and can be disconnected at any time. Tokens are held by Genspark and cannot be inspected or exported by the owner.C6 Full deletion PartialGensparkSelf-serve 'Delete User' permanently removes history, content, settings and files, and the policy commits to deleting account data within 30 days. Other personal data may be kept for undefined 'legitimate business purposes'.
Google CCP1 Round-trip portability FailGoogle CCIncomplete and not restorable: no export of the CC agent's memory, configuration or instructions is documented and there is no import; the FAQ offers only deletion.P2 Complete export FailGoogle CCCC's memory, instructions and executable logic stay in Google's hosted service and Google-operated account; no export of them is offered.P3 Independent execution FailGoogle CCCC runs on an isolated Google cloud computer using Google's Antigravity agent harness and Gemini models. It is hosted-only, with no runnable export.P4 Identity continuity FailGoogle CCCC's identity is a Google Account operated by Google, and nothing lets others verify it is the same agent apart from Google.P5 No kill switch FailGoogle CCCC is a waitlisted Google Labs experiment that Google can change or end. No exported agent exists outside Google's control.P6 Capability independence FailGoogle CCTools, triggers (daily brief, Auto CC), messaging and memory are provided by Google's hosted harness and Gemini models, and none of them survive a move to another model or runtime.T1 Open storage format FailGoogle CCCC's memory and state are stored in Google's proprietary backend in an undocumented format. Only its outputs in Gmail, Calendar, Tasks and Drive can be accessed, through Google services.T2 No hidden instructions FailGoogle CCThe system instructions that Google's agent harness places in the Gemini context are neither published nor viewable by members.T3 No shadow memory FailGoogle CCThe FAQ states that CC keeps its own memory, which is not removed when an email is deleted from Gmail, and no memory viewer is documented. Data is also processed under the general Google Privacy Policy.T4 Complete action history PartialGoogle CCCC's outputs appear as emails, Chat messages, calendar entries, tasks and Drive files in shared spaces, but no complete history of its actions and tool calls is available to members.T5 Readable logic FailGoogle CCCC's logic is Google's proprietary harness code. Members cannot see its skills, workflows or code.T6 No third-party influence channel UnverifiedGoogle CCGoogle does not document advertising or sponsored content in CC. It has also not stated whether CC data is used to personalize ads.A1 No unrecorded actions UnverifiedGoogle CCGoogle does not document whether every consequential CC action is durably recorded, or whether an action that cannot be recorded is blocked.A2 Tamper evidence FailGoogle CCMembers are given no action record, so they cannot detect edits to or deletions from one.A3 Separation from the audited UnverifiedGoogle CCGoogle does not document whether CC can alter or delete records of its own actions.A4 Readable with ordinary tools UnverifiedGoogle CCNo audit trail is published to members. Only CC's outputs in Google services are visible.A5 Corroborated interactions FailGoogle CCNo record of CC's exchanges is available to members that could be matched against the other side's records, beyond the messages themselves in shared spaces.V1 Open, reproducible runtime FailGoogle CCCC, its deployment of the Antigravity harness and the Gemini models are proprietary. None is published under an OSI-approved license.V2 Active config is inspectable config FailGoogle CCCC's active configuration (system instructions, model version and harness settings) is held server-side and cannot be inspected by members.V3 Attributable messages FailGoogle CCCC sends messages from its own Google-operated account; recipients can see that account but cannot verify the message was sent under members' authority, and this would not survive a move away from Google.V4 Independently checkable record FailGoogle CCNo action record or verification procedure is published for CC, so nothing can be checked with open tools.V5 Comparable state FailGoogle CCCC's state is held server-side and its memory cannot be viewed, so members cannot verify whether it changed between two points in time.M1 Instructions PartialGoogle CCMembers can steer CC with replies, emails and feedback, which it remembers as preferences. They cannot read or rewrite its underlying instructions.M2 Memory FailGoogle CCNo memory viewer or per-item editing is documented. The FAQ says deleting a Gmail message does not remove it from CC's memory and that fully clearing data requires deleting the account; removing a sender deletes only that sender's emails from CC's inbox.M3 Logic FailGoogle CCMembers cannot change CC's skills, workflows or code.M4 Tools and permissions PartialGoogle CCEach member chooses which senders, categories, emails, files, folders and calendars to share, and can revoke them in Sharing Preferences. Members cannot add tools that Google does not offer.M5 Model choice FailGoogle CCCC runs only on Google's Gemini models, with no choice of model.M6 No gatekeeping FailGoogle CCAccess requires a Google waitlist or invitation, and at launch CC was limited to Google AI Ultra and paid subscribers. No changes are possible beyond the settings Google provides.C1 Communication boundaries PartialGoogle CCGoogle says CC responds only to group members and shares outside the group only with permission, but members cannot set their own contact rules, and whether enforcement sits outside the model is not documented.C2 Approval gates PartialGoogle CCCC needs member confirmation before sharing outside the group, and it cannot add or remove members. Members cannot choose which other actions require approval.C3 Immediate halt PartialGoogle CCMembers can revoke sharing or delete the group, which removes the agent. No pause or immediate-stop control is documented.C4 Data sovereignty PartialGoogle CCThe CC disclaimer says CC data is not used to train Google's foundational generative AI models. All content is processed on Google servers under the Google Privacy Policy, which cannot be verified by network inspection.C5 Credential custody FailGoogle CCCC acts through its own Google-operated account with access held by Google. Members can revoke what they share, but they cannot hold, inspect or move the credentials.C6 Full deletion PartialGoogle CCIn settings, 'Delete Account' permanently deletes a member's CC account and connected information, and 'Delete Group' deletes the agent and its shared spaces. Past CC emails stay in members' inboxes, and Google's general retention and deletion windows apply.
InstinctP1 Round-trip portability FailInstinctIncomplete and not restorable: neither the Terms nor the Privacy Policy describes an export or import feature, and independent reviews report none.P2 Complete export FailInstinctThe agent's logic, model and 'persistent cloud computer' are provider assets, and no export of its memory, history or configuration is documented.P3 Independent execution FailInstinctInstinct is cloud-only and cannot be self-hosted; no open-source runtime exists.P4 Identity continuity FailInstinctThe agent acts through the owner's accounts and a provider-managed phone number, and nothing lets others verify it is the same agent apart from the provider.P5 No kill switch FailInstinctThe Terms let the Company suspend or delete accounts and the Services 'with or without notice' and change features at any time.P6 Capability independence FailInstinctCapabilities run on a proprietary model and a provider-hosted computer with no model selection, so none of them survive a model swap.T1 Open storage format FailInstinctAgent state (memory, task board, indexed data) lives in provider infrastructure with no documented owner-readable format.T2 No hidden instructions FailInstinctSystem and agent-layer instructions are not disclosed to the owner.T3 No shadow memory FailInstinctThe provider indexes connected-service data, collects clickstream and keystroke data and uses Materials for model training by default. Terms state indexed data may still be used after disconnecting unless deletion is requested. TechCrunch reported inbox copies retained after disconnection.T4 Complete action history UnverifiedInstinctThe agent has an inbox, task board and conversation thread, but no public documentation shows that a complete record of its actions and tool calls is available to the owner or can be taken away.T5 Readable logic FailInstinctThe executable logic is closed-source and not available to the owner.T6 No third-party influence channel UnverifiedInstinctThere are no ads today, and the Privacy Policy excludes Google Workspace data from ad use. The service is free with no published business model, and the founder has reportedly floated advertising.A1 No unrecorded actions UnverifiedInstinctNo public information on whether consequential actions are durably recorded or blocked when they cannot be recorded.A2 Tamper evidence UnverifiedInstinctNo public information on whether edits to or deletions from any action record would be detectable.A3 Separation from the audited UnverifiedInstinctNo public information on whether the agent can alter or delete records of its own actions.A4 Readable with ordinary tools UnverifiedInstinctNo owner-accessible audit trail or log export is documented.A5 Corroborated interactions UnverifiedInstinctNo public information on whether the agent's records of exchanges with other agents or people can be matched against theirs.V1 Open, reproducible runtime FailInstinctThe runtime is proprietary and not open source.V2 Active config is inspectable config FailInstinctThe agent's operating configuration is provider-controlled and not exposed to the owner beyond account settings.V3 Attributable messages FailInstinctThe agent sends messages through the owner's connected accounts or provider channels; recipients have no way to verify they came from this agent under the owner's authority.V4 Independently checkable record FailInstinctNo action record or open verification procedure is published.V5 Comparable state FailInstinctThe owner cannot access the agent's state, so cannot verify whether it changed.M1 Instructions PartialInstinctOwners can give standing instructions conversationally, but cannot read or rewrite the agent's base instructions.M2 Memory PartialInstinctOwners can delete all indexed connected-service data at app.instinct.com/workspace or delete the account. Item-level viewing and editing of memory is not documented.M3 Logic FailInstinctOwners cannot modify the agent's skills, workflows or code.M4 Tools and permissions PartialInstinctOwners can connect and disconnect supported services, but cannot add their own tools. Reviews report Google integrations are full-access only, with no read-only scope.M5 Model choice FailInstinctThe agent uses a proprietary model with no model selection, and local models are not supported.M6 No gatekeeping FailInstinctAny change beyond settings and conversational preferences requires the provider, which alone controls the product.C1 Communication boundaries UnverifiedInstinctNo documented way lets the owner decide whom the agent may contact or through which channels; the Terms authorize it to act and transact on the owner's behalf.C2 Approval gates PartialInstinctReviews report confirmation before sending email or charging a card. The Terms say confirmations 'may' be implemented without warranty, and TechCrunch reported an email sent without prior approval and a login code retrieved without asking.C3 Immediate halt UnverifiedInstinctNo documented owner control to halt in-flight actions immediately.C4 Data sovereignty FailInstinctContent is processed in the provider cloud and shared with third-party model providers and vendors. Materials are used to train AI models unless the owner opts out, and safety-flagged data is still used after opt-out.C5 Credential custody FailInstinctOAuth grants and stored credentials for connected services are held by the provider's cloud and cannot travel with the agent. Access can be disconnected, but indexed data persists until deletion is separately requested.C6 Full deletion PartialInstinctOwners can delete indexed data and their account, and a deletion tool was added after user complaints. No retention periods are disclosed, and the Terms state that on account deletion the Company 'may, but is not obligated to' delete Materials.