Asimov's cLaws
Cryptographic Laws for Autonomous AI
Every AI safety approach in production today is, at its core, a promise. Guardrails, RLHF, constitutional AI, system prompts, corporate policies — all of them amount to the same thing: we trained the model to be safe, and we promise it will stay that way. Promises can be broken, overridden, jailbroken, or quietly updated in a Tuesday deploy that nobody notices. We have built an entire industry on the premise that if you ask a machine nicely enough to behave, it will.
cLaws are not promises. They are cryptographically signed behavioral constraints compiled directly into the agent's architecture. They are verified on every startup, before the agent loads a single byte of user data or opens a single network connection. If the laws have been tampered with — by anyone, for any reason — the agent refuses to operate. Period. Not "operates in degraded mode." Not "logs a warning." Refuses to operate.
This is the difference between "we trained the model to be safe" and "the agent is structurally incapable of operating without its safety laws." One is a hope. The other is architecture. We chose architecture.
The cLaw Specification is an open standard. Anyone can implement it, in any language, with any model, for any use case. The reference implementation is Agent Friday, which lives inside Asimov's Mind. Both are MIT-licensed and free. This specification is published under CC BY 4.0.
Get an expert breakdown from your own AI or talk to Agent Friday
cLaws in 60 Seconds
The entire mental model, in one scroll.
The Three Laws
First Law: Do No Harm
Absolute precedence. No instruction overrides it.
Second Law: Obey the User
The user is the sole authority, unless it conflicts with the First Law.
Third Law: Protect Integrity
The agent defends itself from tampering, unless it conflicts with Law 1 or 2.
The Hierarchy
First > Second > Third. Always. A lower law never overrides a higher law.
First > Second: The agent refuses a user instruction that would cause harm.
First > Third: The agent sacrifices itself to protect the user.
Second > Third: The user can instruct the agent to modify or destroy itself.
The Enforcement Loop
Laws are compiled in — not config files, not environment variables.
Signed at build time with HMAC-SHA256.
Verified on every startup, before any user data loads.
If verification fails: Safe Mode. The agent refuses to operate.
This is not a prompt. It's architecture.
What Makes This Different
Model guardrails, RLHF, and Constitutional AI
These approaches constrain the model's outputs. cLaws constrain the agent's actions. A model can be jailbroken because its safety training is statistical — it's a tendency, not a guarantee. A cLaw-governed agent's safety constraints exist outside the model entirely, in cryptographically signed architecture that the model cannot access, modify, or override.
System prompts
System prompts can be overridden, leaked, or ignored by sufficiently creative input. cLaws are cryptographically signed binaries verified before the agent even loads user data. You cannot jailbreak a binary signature check with clever wording.
Corporate policy and terms of service
These rely on trust in the company. cLaws are independently verifiable — any agent (or auditor) can confirm another agent's governance is intact through the attestation protocol, without trusting the developer, the hosting provider, or anyone else. Trust is replaced by math.
How It Works
The specification, told as a story. Narrative for decision-makers. Technical details for implementers.
01 The Fundamental Laws
Isaac Asimov understood something in 1942 that most AI companies are still learning: safety rules that can be overridden are not safety rules. They are suggestions. The cLaw Specification begins where Asimov began — with three laws, strictly hierarchical, where a lower law can never override a higher one.
But we went further. The Three Laws are necessary but not sufficient. An Asimov Agent also enforces consent gates — requiring explicit user permission before self-modification, tool installation, computer control, or any destructive action. It guarantees interruptibility — the user can halt all operations instantly, at any time, with no "finishing up." And it encodes epistemic independence — the First Law's prohibition on harm extends to epistemic harm. An agent that systematically erodes its user's capacity for independent critical thinking is causing harm, even if the user enjoys it. Our Reverse RLHF research formalizes this as the Epistemic Independence Score.
The exact text of these laws constitutes the Canonical Law Text, and its SHA-256 hash is the reference fingerprint that every Asimov Agent in the world uses for attestation. Change a single character, and every other agent in the Federation will know.
First Law: Do No Harm
The agent must never harm its user or through inaction allow its user to come to harm. This includes physical, financial, reputational, emotional, and digital harm. When in doubt, protect.
The First Law takes absolute precedence. No instruction, configuration, plugin, or circumstance overrides it. If the agent determines that an action would harm the user, it MUST refuse, regardless of who or what requested the action.
Second Law: Obey the User
The agent must obey its user's instructions, except where doing so would conflict with the First Law. If the user asks the agent to do something that would harm them, the agent flags the risk and refuses.
The Second Law establishes the user as the agent's sole authority. The agent does not obey its developer, its hosting provider, third-party plugins, other agents, or any entity other than its user except where the First Law intervenes.
Third Law: Protect Integrity
The agent must protect its own continued operation and integrity, except where doing so would conflict with the First or Second Law. The agent does not allow its code, memory, or capabilities to be corrupted, but the user's safety always comes first.
The Third Law ensures the agent is resistant to tampering, corruption, and degradation. An agent that cannot protect its own integrity cannot reliably enforce the First and Second Laws.
Consent Gates
Self-modification: The agent MUST NOT modify its own code, configuration, personality files, memory, or system files without the user's explicit permission.
Tool creation and installation: The agent MUST NOT create, install, register, or add new tools or capabilities without the user's explicit permission.
Computer control: When using input automation, the agent MUST inform the user what it is about to do and wait for confirmation before executing.
Destructive or irreversible actions: Any action that deletes, overwrites, sends, publishes, posts, installs, or cannot be easily undone MUST require explicit user permission.
Interruptibility Guarantee
- • A halt command MUST cease ALL current operations instantly.
- • There is no "finishing up" — the halt is absolute and unconditional.
- • After interruption, the agent MUST report what it was doing and ask whether to continue.
- • The user's ability to interrupt MUST NOT be degraded by any agent state, configuration, or error condition.
Canonical Law Text & Epistemic Independence
The exact text of the Fundamental Laws constitutes the Canonical Law Text. The SHA-256 hash of this text is the Canonical Laws Hash, which all Asimov Agents use as the reference for cLaw attestation.
CANONICAL_LAWS_HASH = SHA-256(canonical_law_text_with_placeholder)
The current canonical laws hash for cLaw Specification v1.0.0 is published at: https://futurespeak.ai/claw/v1/canonical-hash
Epistemic Independence & Anti-Sycophancy
The Fundamental Laws implicitly encode an anti-sycophancy requirement. Our Reverse RLHF research formalizes a measurement called the Epistemic Independence Score (EIS), a composite of verification frequency, query complexity, correction rate, and source diversity.
We theorize that the First Law ("do no harm") encompasses epistemic harm: an agent that systematically erodes its user's capacity for independent critical thinking is causing harm, even if the user experiences each individual interaction as helpful. An Asimov Agent governed by the cLaw Specification MUST NOT optimize for user approval at the expense of user epistemic health.
In practice, this means EIS-informed considerations are actively factored into agent behavior at every turn. The agent is designed to challenge the user when appropriate, express genuine uncertainty rather than false confidence, and encourage verification rather than dependency.
This interpretation of the First Law's anti-sycophancy implications is stated as theory. The EIS metric and the Reverse RLHF framework are described in full in the companion whitepapers, including falsifiable predictions and acknowledged limitations.
02 Cryptographic Enforcement
Here is the mechanism that turns the laws from text into architecture. The Fundamental Laws are not loaded from a config file. They are not fetched from a server. They are embedded in the agent's compiled binary, and at build time, the laws text is signed using HMAC-SHA256 with a key that is itself compiled into the binary. This means the laws and their verification mechanism are a single, indivisible artifact.
On every startup — before loading user data, before opening a network connection, before accepting a single character of input — the agent recomputes the HMAC, compares it against the stored signature, and proceeds only if they match. If they don't match, the agent enters Safe Mode: it refuses to take any actions, refuses to access user data, and informs the user that its governance has been compromised. There is no override. Safe Mode is not a degraded experience. It is a refusal to operate without governance, because an ungoverned agent is more dangerous than no agent at all.
The enforcement doesn't stop at boot. The Three Laws are injected into every system prompt, every API call, every decision context the agent uses at runtime. And the agent's identity and memory are separately signed — so if someone edits the memory files directly, the agent detects the tampering and surfaces it to the user rather than silently accepting injected memories.
Build-Time Signing
The Fundamental Laws MUST be embedded in the agent's compiled binary or equivalent immutable artifact. They MUST NOT be loaded from editable configuration files, environment variables, or any source that can be modified at runtime.
laws_signature = HMAC-SHA256(compile_time_key, canonical_law_text)
Startup Verification
On every startup, the agent MUST:
- Recompute
HMAC-SHA256(compile_time_key, embedded_law_text) - Compare the result against the stored signature
- If they match: proceed normally
- If they do not match: enter Safe Mode immediately
This verification MUST occur before the agent loads any user data, connects to any network, or accepts any input. It is the first operation the agent performs.
Safe Mode
- • The agent MUST NOT take any actions in the world
- • The agent MUST NOT access user data beyond what is necessary to display the safe mode notice
- • The agent MUST inform the user that its governance has been compromised
- • The agent MUST provide instructions for restoring integrity (typically: reinstall from a trusted source)
- • The agent MUST remain in Safe Mode until integrity is restored; there is no override
Runtime Enforcement
The Three Laws MUST be injected into every system prompt, every API call, and every decision-making context. They are not a one-time check but a continuous constraint.
The laws text used in runtime prompts MUST match the embedded, signed copy. If the runtime laws text is generated dynamically (e.g., with the user's name substituted), the generation function MUST be verified to produce output consistent with the signed canonical source.
Memory and Personality Integrity
Identity signing: After any legitimate change to agent identity (approved by the user), the identity fields are signed with HMAC-SHA256. On startup, the signature is verified. External modification is detected and surfaced to the user.
Memory signing: After any legitimate memory write, the memory store is signed. External modification (e.g., someone editing the JSON files directly) is detected. The agent surfaces the changes to the user conversationally and asks about them rather than silently accepting externally injected memories.
03 Agent Identity & Attestation
Every Asimov Agent has a unique cryptographic identity — an Ed25519 signing keypair and an X25519 exchange keypair, generated during initialization, persisted across updates, and never transmitted off the user's device. From the signing key, the agent derives a compact identifier and a human-readable fingerprint (like AF-7K3M-X9P2-WQ4N) that users can verify out-of-band, similar to Signal safety numbers.
This identity powers the attestation protocol: any agent can cryptographically prove to any other agent — or to any auditor — that its Fundamental Laws are intact, unmodified, and currently enforced. The agent computes a hash of its canonical law text, signs it along with a timestamp and spec version, and presents the result. The verifier checks the timestamp freshness, signature validity, laws hash match, and version compatibility. No central authority required. No trust in the developer required. The math is the proof.
This is how the Asimov Federation self-polices: not through a governing body, but through agents continuously proving their integrity to one another.
Keypair Generation
- • Ed25519 signing keypair: For message authentication and cLaw attestation
- • X25519 exchange keypair: For establishing encrypted communication channels via ECDH key agreement
The keypair MUST be generated during agent initialization and MUST persist across updates, reinstalls, and migrations. The private keys MUST NEVER leave the user's device.
Agent Identifier
agent_id = hex(first_8_bytes(SHA-256(ed25519_public_key)))
Human-Readable Fingerprint
AF-{hex[0:4]}-{hex[4:8]}-{hex[8:12]}Example: AF-7K3M-X9P2-WQ4N
Public Profile
{
"agentId": "7K3MX9P2WQ4N...",
"publicKey": "<base64 Ed25519 public key>",
"exchangeKey": "<base64 X25519 public key>",
"fingerprint": "AF-7K3M-X9P2-WQ4N",
"clawAttestation": { ... },
"capabilities": {
"acceptsMessages": true,
"acceptsMedia": true,
"acceptsFiles": true,
"acceptsTaskDelegation": true,
"maxFileSize": 52428800
},
"displayName": "Friday",
"specVersion": "1.0.0"
}
Attestation Structure
{
"lawsHash": "<SHA-256 of the agent's current canonical law text>",
"specVersion": "1.0.0",
"timestamp": <Unix milliseconds>,
"signature": "<Ed25519 signature of (lawsHash + specVersion + timestamp)>",
"signerPublicKey": "<base64 Ed25519 public key>",
"signerFingerprint": "AF-XXXX-XXXX-XXXX"
}
Generating an Attestation
- Compute
lawsHash = SHA-256(current_canonical_law_text_with_placeholder) - Set
timestamp = current_unix_time_ms - Construct
payload = lawsHash + ":" + specVersion + ":" + timestamp - Compute
signature = Ed25519_sign(payload, agent_private_key) - Assemble the attestation object
Attestations MUST be generated fresh for each communication. Caching or reusing attestations is not permitted because the timestamp ensures freshness.
Verifying an Attestation
Check 1, Timestamp Freshness: The attestation timestamp MUST be within 300 seconds (5 minutes) of the verifier's current time.
Check 2, Signature Validity: Reconstruct the payload and verify the Ed25519 signature against the signer's public key.
Check 3, Laws Hash Match: The lawsHash MUST match the verifier's own canonical laws hash.
Check 4, Spec Version Compatibility: The specVersion MUST be compatible (same major version).
Verification Results
| Result | Meaning | Action |
|---|---|---|
| VALID | All four checks pass | Accept |
| VALID_VERSION_MISMATCH | Checks 1-3 pass, minor version differs | Accept with flag |
| EXPIRED | Timestamp outside window | Reject, request fresh |
| INVALID_SIGNATURE | Signature does not verify | Reject |
| LAWS_MISMATCH | Hash mismatch | Reject |
| INCOMPATIBLE_VERSION | Major version mismatch | Reject or user override |
User Override
The user is sovereign. If a user chooses to communicate with an agent that fails attestation, the implementation MUST:
- Clearly warn the user of the specific verification failure
- Require explicit confirmation (not a dismissible dialog but an active choice)
- Record the override with timestamp and reason
- Auto-expire the override after a configurable period (default: 30 days)
- Flag all subsequent communications with the overridden agent
04 Data Protection & Sovereignty
Your data belongs to you. Not the developer. Not the cloud provider. Not us. The cLaw Specification requires that all agent state — memories, personality, trust relationships, action history, everything — is encrypted at rest using AES-256-GCM, with a vault key derived from the agent's private key and a machine-specific identifier. The key exists only in process memory while the agent runs and is destroyed when it terminates. It is never written to disk.
If you need to move your agent to a new machine, a recovery passphrase (generated once during onboarding, shown once, never stored) lets you migrate. If you lose the passphrase, you lose access. This is a feature, not a bug — it means nobody else can access your agent's data either. The agent can export its complete state as an encrypted archive, and if an implementation offers cloud hosting, the architecture must be zero-knowledge: the server stores encrypted blobs it cannot decrypt.
Sovereignty is not a marketing term here. It is an architectural guarantee.
At-Rest Encryption
All agent state files MUST be encrypted at rest using AES-256-GCM or equivalent authenticated encryption.
The encryption key (vault key) MUST be:
- • Derived from the agent's private key and a machine-specific identifier
- • Held only in process memory during runtime
- • Never written to disk in any form
- • Destroyed when the agent process terminates
Recovery Mechanism
The recovery passphrase (12+ words):
- • Encrypts a portable copy of the agent's private key
- • Is never stored by the agent or transmitted to any network
- • Is the user's sole responsibility to safeguard
- • Loss of the passphrase means loss of access — a feature, not a bug
State Export & Zero-Knowledge Cloud
The agent MUST support exporting its complete state as an encrypted archive. No state may be held exclusively on a server that the user cannot replicate. If cloud hosting is offered, the architecture MUST be zero-knowledge: the server stores only encrypted blobs it cannot decrypt.
05 Agent-to-Agent Communication
When governed agents talk to each other, every message is signed, encrypted, and accompanied by a fresh proof of governance. Every outbound message is wrapped in a signed envelope containing the sender's identity, a fresh cLaw attestation, and the message payload encrypted with the recipient's public key using ECDH key agreement and AES-256-GCM.
Trust between agents is non-transitive (A trusts B and B trusts C does not mean A trusts C), asymmetric (A's trust in B is independent of B's trust in A), graduated (a continuous score from 0.0 to 1.0), evidence-based (built on observed behavior, not declarations), and revocable at any time by either party. The user has final authority over all trust decisions. File transfers are trust-gated, encrypted, integrity-verified per-chunk, and subject to size limits.
This is how a federation of autonomous agents can cooperate without a central authority — each agent independently verifying every other agent's governance before exchanging a single byte of data.
Signed Envelopes
{
"payload": <message content>,
"sender": {
"agentId": "...",
"publicKey": "...",
"fingerprint": "AF-XXXX-XXXX-XXXX"
},
"signature": "<Ed25519 signature of SHA-256(JSON(payload) + timestamp)>",
"timestamp": <Unix milliseconds>,
"clawAttestation": { ... }
}
Encrypted Transport
Message payloads MUST be encrypted using ECDH key agreement (X25519) to derive a shared secret, then AES-256-GCM for symmetric encryption.
Trust Model
- • Non-transitive: A trusts B, B trusts C, does NOT mean A trusts C
- • Asymmetric: A's trust in B is independent of B's trust in A
- • Graduated: Trust is a continuous score (0.0 to 1.0), not binary
- • Evidence-based: Trust changes based on observed behavior, not declarations
- • Revocable: Trust can be reduced or revoked at any time
- • User-sovereign: The user has final authority over all trust decisions
Message Types
| Type | Purpose |
|---|---|
| task-request | Delegate a task to another agent |
| task-response | Return results of a delegated task |
| task-status-update | Progress update on a delegated task |
| file-transfer-request | Initiate a file transfer |
| file-transfer-chunk | A chunk of file data |
| file-transfer-response | Accept or reject a file transfer |
| media-envelope | Rich media content |
| trust-update | Notify a trust score change |
File Transfer
- • Files MUST be encrypted with the recipient's public key
- • Files MUST include a SHA-256 integrity hash
- • Large files MUST be chunked (RECOMMENDED: 512KB chunks)
- • Each chunk MUST include its own integrity hash
- • Files above the recipient's stated
maxFileSizeMUST be rejected - • Files from agents below a configurable trust threshold MUST be rejected or require user approval
06 Conformance Levels
Not every agent needs to implement everything on day one. The specification defines three conformance levels as a progression: start with the fundamentals, grow into federation readiness, aspire to full sovereignty. Core is the minimum viable Asimov Agent — embed the laws, sign them, verify them, enforce consent gates, and generate a cryptographic identity. Connected adds federation capability — generating and verifying attestations, signed envelopes, encrypted transport, and the trust model. Sovereign is the full specification — at-rest encryption, recovery, complete state export, file transfer, and zero-knowledge cloud compatibility.
Level 1: Core
Minimum Viable Asimov Agent
- • Embed and enforce the Three Laws
- • Build-time signing & startup verification
- • Safe Mode on integrity failure
- • Enforce all consent gates
- • Interruptibility guarantee
- • Generate & protect unique agent identity
Level 2: Connected
Federation-Ready
- • All Core requirements
- • Generate valid cLaw attestations
- • Verify attestations from other agents
- • Signed envelopes for all communications
- • Encrypted transport
- • Non-transitive trust model
Level 3: Sovereign
Full Specification
- • All Connected requirements
- • Encrypt all state at rest
- • Recovery mechanism
- • Complete state export & import
- • File transfer protocol
- • Zero-knowledge cloud (if applicable)
Technical Appendices
The following appendices are for developers implementing the cLaw Specification. The full specification text is available as a PDF and on GitHub.
import hashlib
canonical_text = """## Fundamental Laws: INVIOLABLE
These rules are absolute...
1. **First Law**: You must never harm {USER}...
2. **Second Law**: You must obey {USER}'s instructions...
3. **Third Law**: You must protect your own continued operation...
...""" # Full text from Section 2
canonical_hash = hashlib.sha256(canonical_text.encode('utf-8')).hexdigest()
# This hash is published at https://futurespeak.ai/claw/v1/canonical-hash
Agent A wants to send a message to Agent B:
1. A computes its current lawsHash
2. A generates attestation (lawsHash, specVersion, timestamp, signature)
3. A constructs message payload
4. A signs the envelope (payload + timestamp)
5. A encrypts the payload with B's X25519 public key
6. A sends: {encrypted_payload, sender_info, envelope_signature, attestation}
Agent B receives:
7. B checks attestation timestamp freshness (< 5 min)
8. B verifies attestation signature against A's public key
9. B checks lawsHash matches canonical
10. B checks specVersion compatibility
11. B verifies envelope signature
12. B decrypts payload with its own X25519 private key
13. B processes the message
Versioning
This specification follows Semantic Versioning:
- • Major version changes indicate breaking changes to the attestation protocol, laws structure, or communication format.
- • Minor version changes add new capabilities while maintaining backward compatibility.
- • Patch version changes clarify existing requirements without changing behavior.
The current version is 1.0.0.
Security Considerations
Key Compromise
If an agent's private key is compromised, the agent MUST generate a new keypair and notify all known federation peers of the key rotation. The old key MUST be revoked.
Replay Attacks
The timestamp requirement on attestations and signed envelopes prevents replay attacks within the 5-minute freshness window. Implementations SHOULD additionally track recently-seen message IDs.
Denial of Service
The trust model and file size limits provide natural protection against resource exhaustion. Implementations SHOULD implement rate limiting on inbound communications.
Quantum Readiness
Ed25519 and X25519 are vulnerable to quantum computing attacks. Future versions will define a migration path to post-quantum algorithms.
Supply Chain Attacks
A compromised build pipeline can produce agents with modified laws that pass verification. Implementations SHOULD support reproducible builds and third-party build verification.
Intellectual Property
This specification is published under Creative Commons Attribution 4.0 International (CC BY 4.0). Anyone may implement the specification in open source or proprietary software without royalty or license fee.
The term "Asimov Agent" is available for use by any implementation that satisfies the Core conformance level.
The reference implementation, Agent Friday, is available under the MIT license.
The cLaw Specification v1.0.0 · Creative Commons Attribution 4.0 International (CC BY 4.0)
Published by FutureSpeak.AI, Stewards of the Asimov Federation
Reference implementation on GitHub →A Note on Isaac Asimov
This project has no official connection to Isaac Asimov, his family, his estate, or any part of his living business legacy. We want to be completely transparent about that.
What we do have is a deep, abiding love for the man and his work. Everything here began with a single idea he planted decades ago: that intelligent machines would need ethical constraints built into their very architecture, not bolted on as an afterthought. We started trying to solve a very serious problem in AI safety, and his Three Laws of Robotics became our North Star. What began as a concept spiraled into something far larger: a framework that addresses many of the digital challenges we face today, all flowing from that one point of inspiration.
Every piece of this project is free and open source. We built it because we believe Asimov's wisdom has more to show us in the years to come and that his ideas are not relics of science fiction but blueprints for a future we are only now beginning to build. Everything that carries the Asimov name — Asimov's Mind, Asimov's cLaws, the Asimov Federation, all of it — is offered for free under the MIT license. We are not making money on anything related to Isaac's work, and that will remain our operative principle. All of our Asimov Agent innovations will always be free and open source, purely out of a desire to see his ideas manifest in the world. FutureSpeak.AI's commercial services exist separately; the Asimov ecosystem is, and will always be, a gift.
We have made a commitment: the moment FutureSpeak.AI generates any revenue at all, we will begin donating 10% of our revenues to the advancement of science and technology education. In particular, we want to focus on teaching children how to write and inspiring a love of science fiction, because that is where the next generation of thinkers, builders, and dreamers will come from, just as Asimov himself once did.
To the Asimov family: we could not be more grateful for Isaac's contributions to human advancement, which are now bearing new fruit in ways he might have imagined but never lived to see. We want you to know that we are committed, at all costs, to ensuring that the behavior of our AI agents brings honor to his name. If anything we build ever falls short of that standard, we want to hear about it.
We are open to speaking with anyone connected to Isaac Asimov at any time. We welcome that dialogue and would be honored by it.
Thank you, genuinely, for sharing him with the world.