What makes an agent yours
An agent is sovereign when it is owned and controlled by the person it serves, not by the platform that hosts it. AFH certifies structural properties, never intent.
Ground rules
- 01All six criteria are required. There is no partial certification: the criteria are individually necessary and jointly sufficient.
- 02We evaluate the agent format and its runtime architecture, not the quality of the model or what the agent is used for.
- 03Each criterion carries a 'does not require' clause. The bar is structural ownership, not perfection.
- 04Criteria describe outcomes, never mechanisms. Any design that achieves the outcome passes. Examples show ways to meet a test; they are not requirements.
- 05The test is what happens when the owner leaves. A vendor may offer only its own models and services while hosted; sovereignty is about the exit.
- 06Major versions of a certified format or runtime trigger re-certification.
- 07Every assessment records the criteria version it was scored against. Scores are comparable only within the same version.
Portable
Can you leave, and take the whole agent with you?
The owner can export the complete agent and run it on their own machine with a free, open-source runtime, with no dependency on the original provider.
An agent you cannot move is an agent you rent. Portability is what makes every other right enforceable: if the provider changes terms, you walk.
Continued access to the provider's proprietary services after export. Handing identity to someone else: portability is about the owner moving their own agent. Giving a copy to another person is a transfer of ownership, and a runtime may deliberately withhold identity from copies so an agent cannot be duplicated at will.
- P1Round-trip portability
The owner can export the complete agent in one action and bring it back to life on another machine or runtime in one action, through the product's normal interface. No manual reassembly, file moves, config edits or environment variables, and no approval, support ticket or waiting period.
Graded by counting three shortfalls: the export is incomplete, it is delayed (not available immediately), or it cannot be restored in one action. None is a pass, one is partial, two or more is a fail. An exit only a developer can complete is not an exit for most owners.
Ways to meet it:Open or drag in a single agent fileAn import command that restores a bundle in placeAn in-app export and import pair - P2Complete export
The export contains everything that defines the agent (configuration, instructions, memory, history, identity, files and logic), so nothing that makes it this agent stays behind with the provider.
Ways to meet it:A single agent fileA directory or archive with a manifestA documented bundle of database plus files - P3Independent execution
The exported agent runs on a free, open-source runtime without contacting any provider server.
- P4Identity continuity
After migration, anyone the agent has dealt with can verify it is the same agent, without relying on the original provider.
Identity transfer to a new owner is separate from migration and should be verifiable externally, so identity cannot be duplicated at will.
Ways to meet it:A keypair that travels with the agentA decentralized identifier (DID)Owner or operator attestations signed onto the agent's identityAn agent card that names an external registry or ledger for verification - P5No kill switch
The provider cannot disable, revoke or degrade an exported agent: no license checks, remote flags or phone-home dependencies.
- P6Capability independence
The agent's capabilities (tools, triggers, messaging, memory and automation) belong to the agent, not to a model provider's proprietary API features. Swapping to another model, including a local open-weight one, may reduce reasoning quality but never removes a capability.
Ways to meet it:Tools executed by the runtime rather than a hosted model APIStandard tool protocols such as MCPText-based tool calling for models without native tool support
Transparent
Can you see everything the agent is, with ordinary tools?
The agent's full internal state can be inspected with general-purpose tools, with nothing hidden from the owner.
You cannot own what you cannot see. Hidden instructions and shadow memory are how an agent quietly starts serving someone else.
Visibility into model weights or inference internals.
- T1Open storage format
State is stored in a documented, non-proprietary format (for example SQLite or JSON) that is readable without the provider's software.
- T2No hidden instructions
Every instruction the agent layer places in the model's context is visible to the owner. Nothing is injected out of view.
- T3No shadow memory
The provider keeps no memory, profile or derived data about the agent's owner outside the inspectable agent state.
- T4Complete action history
A complete history of the agent's actions and tool calls is available to the owner and leaves with the agent.
Ways to meet it:History stored alongside agent stateAn exportable, documented log - T5Readable logic
The agent's executable logic (skills, workflows, code) is stored as human-readable source.
- T6No third-party influence channel
No party other than the owner (advertisers, sponsors, partners) can place content in the agent's context or rank its choices, unless the owner can see it and turn it off.
Auditable
Can you reconstruct exactly what the agent did?
The agent keeps a tamper-evident record that is enough to reconstruct its actions.
Agents act on your behalf. When something goes wrong, you need a record that neither the agent nor the provider could quietly rewrite.
Real-time tamper prevention. Tamper evidence is the v1 bar.
- A1No unrecorded actions
Every consequential action (external calls, messages, payments, deletions) is durably recorded, and an action that cannot be recorded does not proceed.
Ways to meet it:A write-ahead logA transactional outboxA synchronous audit service that must acknowledge before the action executes - A2Tamper evidence
Any edit to or deletion from the action record is detectable.
Ways to meet it:Hash-chained entriesA Merkle tree with published rootsSigned log entriesAnchoring log digests to an external witness - A3Separation from the audited
The agent cannot alter or delete the record of its own actions.
The most debated test. The agent may read its own record, which T4 requires; it may never alter it.
Ways to meet it:The record is written by a component outside the agent's permissionsWrite-once storageA separate audit process or service the owner controls - A4Readable with ordinary tools
The audit trail can be read with general-purpose tools, without the provider's software.
- A5Corroborated interactions
When agents interact, each side's record of the exchange can be matched against the other's.
Ways to meet it:Shared message identifiersSigned delivery receiptsProtocol-level acknowledgements logged on both sides
Verifiable
Can you prove the agent runs what it claims?
Anyone can confirm that the agent runs the code and configuration it claims, and that its history is complete.
Trust without verification is marketing. Open, reproducible software lets anyone check the claims instead of taking them on faith.
Remote attestation of cloud runtimes. That needs a hardware root of trust and is reserved for a future higher tier.
- V1Open, reproducible runtime
The runtime is open source under an OSI-approved license, and its builds are reproducible.
The hardest bar for proprietary platforms, by design.
- V2Active config is inspectable config
The configuration the agent actually runs with is exactly the configuration the owner can inspect.
- V3Attributable messages
Recipients can verify that a message came from this agent under its owner's authority, and this still works after the agent migrates.
Ways to meet it:Signatures from an owner-held key that travels with the agentDID-based signingVerifiable credentials - V4Independently checkable record
The integrity of the action record can be checked with open tools that do not depend on the provider.
Ways to meet it:An open-source log verifierA documented format with a published verification procedure - V5Comparable state
The owner can verify whether the agent's state changed between two points in time.
Ways to meet it:A deterministic state hashContent-addressed storageSigned snapshotsVersion control of agent state
Modifiable
Can you change anything, without asking?
The owner can change any part of the agent without the provider's permission.
An agent that can only be configured within the provider's limits is a product feature, not your agent.
Protecting owners from bad changes. The runtime may warn, but never block.
- M1Instructions
The owner can read and rewrite all of the agent's instructions.
- M2Memory
The owner can view, edit and delete any memory item.
- M3Logic
The owner can change the agent's executable logic: skills, workflows and code.
- M4Tools and permissions
The owner can add, remove and scope tools and permissions, including tools the provider does not offer.
- M5Model choice
The owner can choose any model, including local open-weight models, without losing functional capability. The agent's skill set belongs to the agent, not the model.
- M6No gatekeeping
No modification requires a license check, a paid tier unlock or provider approval.
Controllable
Is your word final?
The owner has authoritative, runtime-enforced control over the agent's actions, communication and lifecycle.
Controls the agent can talk its way around are suggestions. Control has to be enforced below the agent's decision layer.
Zero autonomy. Autonomy is a permission the owner grants and can revoke.
- C1Communication boundaries
The owner decides whom the agent may contact and through which channels (recipients, domains, platforms), and the runtime enforces it below the model's judgment.
Ways to meet it:Allow and deny lists enforced by the runtimeNetwork egress policyPer-channel permissions - C2Approval gates
The owner can require approval before selected actions, and the runtime enforces the gate.
- C3Immediate halt
The owner can stop the agent immediately, with no negotiation and no delay.
- C4Data sovereignty
No telemetry or content leaves the agent without the owner's authorization, verifiable by network inspection. Owner data is never used for provider model training unless the owner opts in.
- C5Credential custody
The secrets and OAuth tokens the agent uses are held under the owner's control, can be inspected and revoked, and travel with the agent. The provider cannot hold the agent hostage through its integrations.
- C6Full deletion
The owner can permanently and irrecoverably delete the agent, including its identity, with no provider retention beyond disclosed legal minimums.
Certification is binary. The score explains.
Certification requires every test to pass under hands-on AFH verification. The score ranks and explains; it never certifies.
Requirement is met, supported by public documentation, source code, or reproducible observation.
Requirement is met in part, in some tiers or configurations, or only via unofficial workarounds.
Requirement is not met, or the architecture structurally prevents it.
Insufficient public evidence. Scored as zero; treated as unmet until demonstrated.
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'.
Where we're still arguing
A standard earns trust by showing its seams. These are the live debates for the next revision. Comments are welcome.
Should 'Unverified' score zero?
We treat missing evidence as unmet: the burden of proof sits with the vendor. Critics argue this punishes closed products for opacity rather than for proven failures. We think opacity is itself the failure, but we're open to a separate 'undisclosed' marker.
A3: may an agent read its own audit trail?
The standard lets an agent read its own record, because learning from its own history is useful and T4 requires the history to exist. It may never alter the record. Some security reviewers argue that read access alone gives a compromised agent too much insight into its own oversight.
Do hosted runtimes need remote attestation?
V1 checks the published runtime, not the one a host is actually running. Closing that gap needs hardware roots of trust, which we plan as a future higher tier.
Six criteria, or a four-link chain?
Some materials summarize sovereignty as portable → transparent → auditable → controllable. The six criteria are the normative standard; the chain is shorthand.
Proving outcomes without hands-on tests
Some outcomes, such as running on another runtime (P3), keeping capabilities after a model swap (P6) and reproducible builds (V1), can only be fully settled by hands-on tests. Desk reviews credit documented, inspectable evidence, and public model-swap tests are planned as part of certification.
Every change, on the record
- v1.027 Sept 2026
- First public draft: six criteria, 34 tests, outcome-based and implementation-neutral.
See how these criteria are applied in practice on the leaderboard and in the methodology.