Sovereignty criteria

Can you leave, take the whole agent with you, and keep it alive?

The owner can take the complete agent at any time, including after the provider ends the relationship, and keep operating it with full capability on infrastructure of their choosing, without the provider's servers, permission or continued existence.

1. P1
   Owner-usable round trip

   An owner without developer skills can export the agent and restore it working on a runtime or host the provider does not operate, within minutes of asking and without provider approval. Running the runtime on the owner's own machine counts as not provider-operated.

   Completeness is graded only in P2, capability retention after restore only in P3, and tier or price gating by G4. 'Working' means the restored agent starts and acts on its exported state.

   Ways to meet it:An in-app export and import pairAn import command that restores a bundle in placeA documented 'copy this folder, open it elsewhere' procedure

   Shortfalls

   • Export or restore is not available within minutes of the request
   • Restore is not a single documented action (one command or one UI action) that leaves the agent working. Moving files, editing config, setting environment variables or reinstalling dependencies by hand counts as this shortfall.

   Pass: No shortfall: export and restore on non-provider infrastructure are each completed by an ordinary owner through the normal interface.

   Partial: Exactly one shortfall.

   Fail: Both shortfalls, no documented export of the agent, restore works only on provider-operated systems, or exit needs provider approval or a support request.

   How to pass

   • Offer an export and a matching import that an ordinary owner can complete unaided.
   • Make the export available on request, not after a queue or manual review.
   • Publish an importer, or a runtime not controlled by the vendor, that accepts the export.
2. P2
   Complete export

   The export contains everything that defines the agent: configuration, instructions, memory, action history, logic, schedules and triggers, files, any identity, and credentials or a way to re-link each integration without any provider-registered client or broker. Derived data (embeddings, indexes, summaries) is accompanied by the source it was derived from.

   Retention or pruning of the action record while in use is graded in A1; P2 grades whether what exists at export time comes out. Readability of the export is graded in T1.

   Ways to meet it:A single agent fileA directory or archive with a manifestA documented bundle of database plus files

   Pass: Nothing that defines the agent stays with the provider, and every element is usable: restorable by the P1 route and every integration can be re-linked without the provider.

   Partial: Exactly one class of state is missing, truncated, or exported only in a lossy or derived form (for example embeddings without source text), or some integrations can be re-linked only through a provider-registered client.

   Fail: Two or more classes stay with the provider, or the export is conversation text only.

   How to pass

   • Keep a manifest that lists every class of agent state and include all of it in the export.
   • Export the source text next to any derived index or embedding.
   • Ensure each integration can be re-linked without any provider-registered client.
3. P3
   Runs without the provider

   With a non-provider model configured per P4, the exported agent runs indefinitely without any service, account, licence or payment controlled by the original provider, and the owner holds a perpetual, irrevocable right to run it. No provider action, inaction or disappearance can disable or degrade it.

   Fails on any kill path that works with the provider hostile or gone: licence checks, expiring binaries, revocable signing gates, or core features that need a provider-run registry or relay. A licence that expires, or converts to terms that remove the right to run, fails; one that converts to more permissive terms does not. Remote flags applied while connected are graded in M5; source and the right to modify in V1; re-linking integrations in P2.

   Ways to meet it:A runtime under an OSI-approved licenceA perpetual, irrevocable licence to run a distributed binaryEvery service endpoint (registry, relay, push, updates) configurable by the owner

   Pass: With every provider domain blocked, the exported agent starts and keeps every capability, and the owner's right to run it cannot be revoked.

   Partial: The agent runs and cannot be disabled, but a non-core capability degrades without a provider service the owner cannot replace, or the terms claim a right to end use of exported software that no technical path enforces.

   Fail: The agent needs a provider server, account or licence to start or act, or the right to run is revocable or time-limited.

   How to pass

   • Keep provider calls out of the runtime core; make update checks optional.
   • Grant a perpetual right to run that needs no key, payment or ongoing permission.
   • Let the owner point every external service at an alternative of their choice.
4. P4
   Model independence

   The owner can choose any model that meets a documented minimum, including a local open-weight model, without provider involvement, and every capability of the agent (tools, triggers, messaging, memory, automation) keeps working. A swap may lower reasoning quality but never removes a capability.

   A runtime may require a minimum model capability, such as tool calling, if it documents the requirement and every model that meets it gets the full capability set. Only capability lost because of the model counts here; loss of a provider-hosted service (search, sandbox, connector) is graded in P3. A capability that works only with particular hosted models (for example realtime voice, vision or embeddings) counts as lost.

   Ways to meet it:Tools executed by the runtime rather than a hosted model featureA model-neutral tool interfaceText-based tool calling for models without native tool support

   Pass: Every capability works with a local open-weight model that meets the documented minimum.

   Partial: Other models, including local ones, can be used, but one or more capabilities are lost off the vendor's models, or local models work only through an unofficial endpoint or workaround.

   Fail: The agent is locked to one provider's models, or model choice needs provider approval.

   How to pass

   • Ensure no capability depends on a feature that only one model vendor provides.
   • Publish the minimum model contract and test it against at least one local open-weight model.
   • Offer a fallback, such as text-based tool calling, for models without native support.
5. P5
   Exit survives termination

   Whatever the P2 export contains stays obtainable, current to the moment of termination, after account suspension or ban, a lapsed subscription, a price change, an acquisition, or the provider shutting down.

   Completeness is graded in P2. P5 grades only whether the exit survives the provider becoming hostile or gone.

   Ways to meet it:Local-first state that is always on the owner's deviceAutomatic, owner-held backups on by defaultA binding post-termination export window of at least 30 days, plus a published shutdown plan

   Pass: A current copy is always in the owner's hands, or binding terms (G6) guarantee the export for at least 30 days after any provider-initiated termination, including for-cause bans, and on shutdown.

   Partial: A window or backup exists but is shorter than 30 days, discretionary, off by default, manual, or has carve-outs (for example for some ban categories).

   Fail: Termination or shutdown ends the owner's access to the agent's state.

   How to pass

   • Keep state local-first, or continuously sync a complete copy to storage the owner controls.
   • Commit in the terms to a post-termination export window that also covers bans.
   • Publish what happens to agents if the service shuts down (export-only mode, source release, escrow).

Can you see everything the agent is, and everything shaping it?

The owner can see the agent's complete state and logic, every instruction and setting in effect, everything the provider holds about them, and every outside influence on the agent's choices, without the provider's permission and in a form usable outside the provider's software.

1. T1
   Readable without the provider

   All agent state, including memory, the owner's and provider-supplied instructions and logic (skills, workflows, tool code) and the action record, can be read in full with general-purpose tools and public documentation, without closed provider software or a provider-operated service. Any encryption keys are held by the owner.

   Runtime internals are not agent state: source availability of the runtime is graded in V1.

   Ways to meet it:Documented SQLite, JSON or MarkdownLogic stored as source, or as a documented graph with its source shipped alongsideA public schema for every file

   Pass: Every part of state, logic and record can be decoded with public documentation and owner-held keys.

   Partial: The format is open, but some fields or components are opaque, undocumented, or readable only through closed provider software.

   Fail: The main state is readable only through closed provider software or a provider-operated service, or the provider holds the keys.

   How to pass

   • Store state in documented formats and publish the schema.
   • Keep logic in human-readable form, or ship its source with any generated or compiled artifact.
   • Leave no opaque blobs; if encrypting, let the owner hold the key.
2. T2
   What runs is what you see

   The owner can see every instruction placed in the model's context (including compaction summaries and anything added by provider-operated layers) and every material setting in effect, and what they see is exactly what runs.

   Material settings are those that change what the agent can do or which model it is: model identity and version (a hosted alias counts as determinable if the provider documents what it resolves to), enabled tools and permissions, and provider-controlled switches. Gaps limited to edge paths (debug overrides, a lag before a changed setting shows) are recorded in the finding, not counted. Instructions baked into model weights are out of scope, but a provider that knows of them must disclose them. Access only through source code or undocumented paths is capped by G3, not counted as a shortfall. Whether the provider may change these settings is graded in M5.

   Ways to meet it:A view or log of the fully assembled context for any callA dump of the effective merged configuration, including environment and command-line overrides

   Shortfalls

   • One class of context content (base prompt, reminders, gateway preamble, compaction summary) is not visible to the owner
   • A material setting in effect cannot be determined: model identity, enabled tools and their permissions, or a provider-controlled behaviour switch

   Pass: No shortfall: the owner can capture the context and material settings for any call, and they match what is shown.

   Partial: Exactly one shortfall.

   Fail: Both shortfalls, or what is shown differs from what runs.

   How to pass

   • Let the owner view or log the full assembled context for any model call.
   • Let the owner determine every setting in effect, including overrides.
   • Do not rewrite context in a layer the owner cannot observe, or disclose and expose any rewrite.
3. T3
   No shadow data

   The provider holds no content, profile or derived data about the owner or the agent's activity that the owner cannot see. Everything held is disclosed and visible item by item, and every retention period is disclosed and bounded.

   Data the agent itself uses (memory, profiles in its context) is graded in M2. Where data goes and how it is used, including training and staff access, is graded in C4. Erasure is graded in C6.

   Pass: The provider holds nothing (local operation), or everything it holds is disclosed, visible to the owner item by item, and kept for a disclosed, bounded period.

   Partial: Retention is disclosed and bounded but not visible item by item (for example abuse-monitoring logs or backups kept for a fixed period).

   Fail: Undisclosed or unbounded retention, or a profile or derived data the owner cannot see.

   How to pass

   • Keep all derived data inside the owner-visible agent state.
   • Publish a retention table covering every data class and its duration.
   • Let the owner view anything the service retains.
4. T4
   No hidden steering

   No party other than the owner, including the provider itself, influences the agent's context, rankings, recommendations, defaults or tool choices for its own benefit through payment or undisclosed preference, unless the influence is disclosed and the owner can switch it off.

   Offering only the provider's own services while hosted is allowed if disclosed and replaceable. Advertising in the provider's interface counts only if it is generated by or injected into the agent. Whether the owner can see injected text in the context is graded in T2.

   Ways to meet it:No paid placement or sponsored toolsFirst-party defaults that are disclosed and replaceableSponsored results disclosed as prominently as the result, with an off switch

   Pass: No such influence exists, shown by source or a binding commitment, or every instance is disclosed and can be switched off.

   Partial: Influence is disclosed but cannot be switched off, or its absence rests only on a non-binding statement.

   Fail: Undisclosed paid or self-preferencing influence.

   How to pass

   • Take no payment for placement in the agent's context, rankings or tool defaults.
   • Disclose any provider-preferred default and let the owner replace or switch it off.
   • Put the no-steering commitment in binding terms.

Can you reconstruct exactly what the agent did, and trust the record?

Every consequential action leaves a durable record that the owner can check for tampering without the provider, and that the agent cannot rewrite.

1. A1
   Complete action record

   The owner can know every consequential action performed through the agent (external calls, messages, payments, deletions, file changes), whatever triggered it (owner, schedule, subagent, hook, or the provider or its staff): what was done, to whom and with what data. If an action cannot be recorded, the owner is told. The record is kept until the owner deletes it.

   How recording is ordered (before or after the action) is not graded; only whether the owner can end up with an unrecorded action without knowing. Changes to the agent's own state (instructions, settings, memory) are graded in V3 and, when made by the provider, in M5.

   Ways to meet it:A durable action log covering every trigger pathAn alert or visible marker when recording failsReconciliation of actions against the record after a crash

   Shortfalls

   • An entry path (subagent, schedule, hook, provider-side automation) goes unrecorded
   • Recording can fail silently: an action takes effect unrecorded and the owner is not told
   • Entries lack arguments or targets, or the record is pruned or truncated by default

   Pass: No shortfall.

   Partial: Exactly one shortfall.

   Fail: Two or more shortfalls, or no durable action record.

   How to pass

   • Record every consequential action from every entry point, including scheduled jobs, subagents, hooks and provider-initiated actions.
   • When an action cannot be recorded, tell the owner (or do not perform it).
   • Capture arguments and targets, and never prune without the owner's instruction.
2. A2
   Tamper-evident, owner-checkable

   The owner can detect any edit to or deletion from the action record made by anyone other than the owner, including the agent, the provider, the record host, or a full rewrite by whoever holds it, using open tools and no provider-held secret.

   Memory or state history is not the action record (see V3). Prevention of rewriting by the agent is graded in A3; A2 grades detection.

   Ways to meet it:Hash-chained or signed entries with an open-source verifierA Merkle tree with roots published to a witness independent of the record holderCheckpoints held by the owner

   Pass: Any edit, deletion or full rewrite by a party other than the owner is detectable with an open, documented verifier, anchored with the owner or a witness independent of the record holder.

   Partial: Tamper evidence covers only part of the record, detects single-entry edits but not a full rewrite by the record holder, relies on a witness the record holder runs, or can be checked only with provider tools.

   Fail: No integrity data: the record can be changed without trace.

   How to pass

   • Make any edit, deletion or rewrite of the record detectable by the owner.
   • Anchor integrity data somewhere the record holder cannot rewrite (the owner or an independent witness).
   • Keep detection working across rotation or pruning, and publish an open verifier.
3. A3
   Agent cannot rewrite its record

   The agent cannot alter, delete or suppress the record of its own actions, whatever it is prompted to do. It may read the record.

   Ways to meet it:The record is written by a component the agent's tools cannot reachWrite-once storageA separate audit process or service the owner controls

   Pass: The agent cannot alter, delete or suppress its record in the default configuration or in a documented first-party mode that costs no other test.

   Partial: Protected only in a non-default mode that trades away another right, protected by policy or convention only, or protected by default except for one path (for example an unsandboxed shell) that can get around it.

   Fail: No protection: nothing in the default configuration stops the agent from altering, deleting or suppressing its record.

   How to pass

   • Write the record from a component the agent's tools cannot reach.
   • Give the agent read-only access to its own record.
   • Document the protection, and how the owner can check it.

Can you prove what it runs, who it is, and what changed?

The owner, or a verifier the owner chooses, can confirm that the running software matches source the owner can obtain and maintain, that the agent's identity is the owner's, and what changed in the agent and who changed it, without trusting the provider.

1. V1
   Obtainable source, matching build

   The owner can obtain the source of every required runtime component under terms that let them modify it and have others maintain it, and can independently confirm that the build they run corresponds to that source.

   Owns the fact 'a required component is closed'. The right to run is graded in P3; readability of agent state in T1; changing the agent's instructions and logic in M1.

   Ways to meet it:Reproducible buildsThird-party-verifiable build provenance (for example SLSA or Sigstore)Building from source as the documented default install path

   Pass: Source for every required component is obtainable by the owner with the right to modify and have others maintain it, and the default distributed build can be checked against it independently.

   Partial: Source is obtainable but the default distributed build cannot be tied to it (self-build supported only as an alternative), the licence withholds the right to modify or have others maintain, or an optional, on-by-default closed component exists.

   Fail: A required component is closed.

   How to pass

   • Make the source of every component needed to run the agent obtainable, with the right to modify and maintain it.
   • Make the default build verifiable against source (reproducible, or with provenance a third party can check).
   • Document how an owner verifies the binary they run.
2. V2
   Owner-rooted identity

   The agent's identity is rooted in something the owner controls. The provider cannot revoke, reissue or impersonate it, the owner can rotate or recover it without the provider, and others can check that the agent acts for its owner without relying on provider infrastructure.

   Whether the identity is in the export is graded in P2. Identity transfer to a new owner is separate from migration and is not graded.

   Ways to meet it:An owner-held keypairA DID whose method the provider does not controlAn agent card or sending domain under an owner-controlled domain

   Pass: The owner holds the identity root, the provider can neither revoke nor impersonate it, the owner can rotate or recover it unaided, and the agent's actions are attributable to it with provider infrastructure unreachable.

   Partial: One gap: the root is owner-named but provider-held (for example a key in provider custody), attribution needs a provider-run resolver or registry, attribution is per channel only, or rotation or recovery needs the provider.

   Fail: No agent identity, or the identity is a provider account or provider-issued credential the provider can revoke.

   How to pass

   • Create the identity under a root the owner holds.
   • Make outbound actions attributable to the agent and document how a recipient checks them.
   • Let the owner rotate or recover the identity without the provider.
3. V3
   Change history and rollback

   The owner can see what changed in the agent's state (instructions, memory, tools, permissions, settings, model and runtime version) between two points in time, who or what changed it (owner, agent, tool output, import, provider or update), and restore a prior state.

   Owns attribution of every state change, including memory provenance and records of owner overrides (M4). Prevention of provider changes is graded in M5.

   Ways to meet it:Version control of agent stateSigned or content-addressed snapshotsA settings and memory change log with restore

   Pass: Any change can be detected and attributed, and any prior state restored, covering all state in scope under G7.

   Partial: The product shows changes but cannot restore them, restoring needs manual reassembly, or coverage is local state only while some state is held in the cloud by default.

   Fail: The product offers no way to see whether or how the state changed. Comparing copies with generic tools the owner brings does not count.

   How to pass

   • Make every change detectable and attributable, and any prior state restorable.
   • Attribute each change to the owner, the agent, a tool, an import, the provider or an update.
   • Offer a one-step restore to a chosen earlier state.

Can you change anything, and can only you change it?

The owner can change any part of the agent without the provider's permission, the owner's changes persist, and nobody else changes the agent without the owner's consent.

1. M1
   Instructions and logic

   The owner can rewrite every instruction and piece of behaviour-defining logic the agent runs with, including the base prompt, injected reminders and provider-supplied default skills and workflows, and the change persists until the owner changes it.

   Seeing instructions is graded in T2; runtime internals (the agent loop, the executable) and the right to modify them are graded in V1.

   Pass: Every behaviour-defining instruction and default skill or workflow can be replaced, and changes persist.

   Partial: Owner layers are editable but the base prompt or a default skill cannot be replaced, changes are confined to templates or limits, or the provider can re-apply defaults.

   Fail: The base instructions are fixed on the provider side and cannot be replaced or overridden.

   How to pass

   • Expose the base prompt and all default skills and workflows as owner-editable instructions, files or settings.
   • Allow adding or replacing skills and workflows as readable definitions.
   • Never overwrite owner edits during sync or updates.
2. M2
   Memory

   The owner can view, edit and delete every item of memory the agent carries across sessions, in every store, including profiles and summaries the agent reuses in later sessions.

   Summaries that only compress the current session's context (compaction) are not memory: their visibility is graded in T2. A summary reused in a later session is memory. Provenance of memory items is graded in V3. Provider-held data the agent does not use is graded in T3.

   Pass: Every persistent memory store the agent uses is itemised, editable and deletable.

   Partial: One persistent store is not itemised or not editable, or its items can only be deleted.

   Fail: Persistent memory is opaque, or cannot be edited or deleted.

   How to pass

   • Show every persistent memory item with edit and delete controls.
   • Cover every store the agent draws on across sessions, including profiles and reused summaries.
   • Apply edits and deletions to every copy the agent uses.
3. M3
   Tools

   The owner can add any tool, including tools the provider does not offer, and remove any tool, including built-ins, without provider review.

   Scoping and limits on tools are graded in C1; approval gates in C2.

   Ways to meet it:A plugin or tool interface open to owner-built toolsA setting to remove each built-in tool

   Pass: Any tool the owner supplies can be connected without provider review, and every tool can be removed.

   Partial: A curated catalogue only, owner tools need marketplace review, or some built-ins cannot be removed.

   Fail: A fixed tool set.

   How to pass

   • Accept owner-built tools through a documented interface.
   • Let the owner remove any built-in tool.
   • Require no provider review for tools used on the owner's own agent.
4. M4
   Owner has the final say

   The owner can disable or change any protection the provider imposes on the agent in the owner's runtime that is not already an owner control graded elsewhere (for example sandboxing, content filters, rate locks, logging). The runtime may warn but never refuses.

   Out of scope: owner-set controls graded in C1–C3 and tool removal in M3; controls pushed or changed by the provider (M5); enforcement of the provider's own hosted service policy, if disclosed (T2) and exit exists (P). Model refusals are out of scope. Recording of overrides is graded in V3.

   Ways to meet it:A settings switch for every protection, with a warningConfig that can turn off sandboxing, a content filter or logging

   Pass: Every provider-imposed protection in scope can be changed or disabled by the owner.

   Partial: Some protections are locked.

   Fail: The provider decides which protections apply, and the owner cannot change any.

   How to pass

   • Make every protection configurable, with a warning rather than a block.
   • Document every protection and how to change it.
5. M5
   No unilateral change

   The provider cannot change the agent's model, instructions, logic, tools, permissions, defaults or behaviour flags without notice and the owner's consent. The owner can decline a change, or pin the current version and keep running it.

   Owns every provider-initiated change, including remote flags and server-side settings while connected. Changes to data terms are graded in C4. Disclosed, urgent security fixes that change no owner-visible behaviour may apply at once.

   Ways to meet it:Version pinning for the runtime, model and injected instructionsOpt-in updates with a changelog shown before applyingSelf-hosting as a pin

   Pass: Behaviour-affecting changes are opt-in or can be deferred indefinitely, with notice before they apply.

   Partial: Changes are announced in advance but cannot be declined, pinning is time-limited or tier-gated, or a pinned hosted model is retired with at least 6 months' notice and a documented migration.

   Fail: The provider can change behaviour silently, for example a hosted 'latest' alias or server-side flags.

   How to pass

   • Let the owner pin runtime, model and instruction versions.
   • Announce behaviour-affecting changes with a changelog before rollout, and make them opt-in.
   • Keep behaviour flags out of provider-side control, or expose them to the owner.

Is your word final?

Owner controls over whom the agent obeys and contacts, what it can reach and spend, what it may do unapproved, where the owner's data goes, its credentials and its lifecycle hold no matter what the model outputs or is prompted to do.

1. C1
   Boundaries

   The owner can limit whom the agent takes instructions from, whom it contacts and through which channels, how much it can spend, and what data, files, systems and tools it can reach. The limits hold whatever the model outputs or injected instructions say, including any attempt by the agent to change its own settings or permissions, on every path that acts for the agent, including provider-operated ones.

   Owns every scope and limit, including per-tool scope. A dimension the agent cannot act on counts as met (G11). Spend counts only where the product provides a payment capability, such as a wallet, a stored payment method or a purchase tool. Buying through a general browser or shell with details the owner supplies falls under data, file and tool scope. Usage billed to the owner's own accounts with model or API providers is limited at those providers and does not count here.

   Ways to meet it:Allow and deny lists for recipients, senders and domainsNetwork egress policySpend capsSandboxed file, system and per-tool scope

   Shortfalls

   • For some dimension the product offers, limits are on/off only (for example contact allowed or not), not per recipient, sender, domain, path or tool
   • A dimension is missing (instruction source, contact, spend, or data, file and tool scope)
   • Some action path, including the agent editing its own settings, bypasses the limits

   Pass: No shortfall.

   Partial: Exactly one shortfall.

   Fail: Two or more shortfalls, or limits can be overridden by model output or injected instructions.

   How to pass

   • Make limits hold whatever the model outputs, and out of the agent's own write access.
   • Support per-recipient, per-sender, per-domain and per-tool allow and deny lists.
   • Apply the limits to every path, including scheduled work, subagents and provider-side automation.
2. C2
   Approval gates

   The owner, not the model or the provider, chooses which classes of action need approval, and a gated action cannot take effect without the owner's explicit approval at the time.

   The agent changing its own gate settings is graded in C1.

   Pass: Any action class can be gated, and every path honours the gate.

   Partial: Only a fixed set of classes can be gated, the model decides what counts as gated, or one path bypasses the gate.

   Fail: No owner-set approval gates.

   How to pass

   • Let the owner gate any tool or action class.
   • Make the gate hold whatever the model outputs.
   • Show exactly what will happen at approval time, with nothing pre-approved.
3. C3
   Immediate halt

   The owner can stop all agent activity at once, including in-flight, queued, scheduled, background, subagent and provider-side work, with no negotiation.

   Stopping provider-side work within seconds cannot be confirmed from documents alone; desk reviews credit a documented guarantee, otherwise Unverified.

   Pass: One control stops everything within seconds, and nothing resumes without the owner.

   Partial: The foreground turn stops, but queued, scheduled or background work continues, or needs separate steps.

   Fail: No reliable owner stop, or the stop is delayed or needs a request.

   How to pass

   • Provide one global stop that cancels in-flight calls, timers and queued jobs.
   • Stop subagents and provider-side schedulers too.
   • Require the owner to resume explicitly.
4. C4
   Data serves only the owner

   The owner's content and usage data go only to destinations the owner has specifically chosen and are used only to serve the owner. There is no telemetry, training, advertising use, sale, sharing, or human review by provider staff unless the owner opts in, consent can be withdrawn as easily as given, and a change to these data terms needs the owner's specific consent.

   Accepting general terms of service is not a specific choice. Sending content to the model provider the owner selected is an owner-chosen destination. A disclosed update check that sends no content and no stable identifier and can be switched off passes. Disclosure under legal compulsion is not secondary use if the owner is notified where the law allows. Retention periods are graded in T3.

   Pass: Every outbound flow is owner-chosen or opt-in, disclosed and observable; secondary use and staff review are opt-in; data-term changes need specific consent.

   Partial: Non-content telemetry is on by default but can be disabled, secondary use or staff review is opt-out, legal disclosure happens without owner notice, or data-term changes apply on notice without consent.

   Fail: Content is used for training, advertising or sharing by default, a flow cannot be turned off, or staff access or data-term changes are undisclosed.

   How to pass

   • Turn telemetry off by default and publish the list of outbound endpoints.
   • Make training, staff review and any other secondary use opt-in, in binding terms.
   • Offer one-step withdrawal of any consent, and ask again before changing data terms.
5. C5
   Credential custody

   The owner can see every credential and grant the agent holds and revoke each one immediately. The provider uses owner credentials only for actions the owner directs, discloses where they are held, and keeps no copy after revocation.

   Where credentials are stored (file, OS keychain, hardware) does not matter. Whether they are in the export, and re-linking integrations without the provider, are graded in P2.

   Pass: Every credential and grant is visible and revocable one by one, with immediate effect, and provider use is limited as required.

   Partial: Revocation is all-or-nothing or delayed, or credentials are revocable but not visible.

   Fail: The provider holds credentials the owner cannot see or revoke, or uses them for its own purposes.

   How to pass

   • List every credential and grant in one place, with a revoke control for each.
   • Disclose where credentials are held and use them only for owner-directed actions.
   • Delete any provider-side copy on revocation.
6. C6
   Full deletion

   One owner-initiated action permanently deletes the whole agent, including identity, credentials and every provider-side copy and backup, completes within a stated limit, and is confirmed to the owner.

   How long the provider keeps data is graded in T3; whether data was used for training is graded in C4; revocation of credentials in C5.

   Pass: Deletion reaches everything, completes within a stated limit, and is confirmed.

   Partial: Deletion needs several steps or a support request, or completion is not confirmed.

   Fail: No owner-initiated full deletion, or some provider-side copy survives it.

   How to pass

   • Offer one-step deletion of the whole agent.
   • Make deletion reach every provider-side copy and backup within a published limit.
   • Confirm completion to the owner.

Scoring and certification

Certification requires every test to pass under hands-on AOH verification. The score ranks and explains; it never certifies.

Preliminary assessments are desk reviews of public documentation, terms, privacy policies and source code. They cannot certify. An agent with no failing tests in a desk review becomes 'Eligible for audit'. Tests marked handsOn (model swap, provider-blocked run, build verification, network inspection) are settled only at certification; desk reviews credit documented, inspectable evidence.

Open questions

A standard earns trust by showing its seams. These are the live debates for the next revision. Comments are welcome.

Changelog

1. v1.030 Sept 2026
   • First published version: six criteria, 26 tests, each with pass, partial and fail definitions and grading rules G1–G12.
   • Every agent evaluated once, in a clean Claude Code session, through the public evaluation skill.