AI agents are taking real actions — deleting files, sending emails, merging code. When something goes wrong, the question is always: did a human actually authorize that, and can you prove it?
Oath is an open protocol for cryptographically signed human intent. Before an agent acts, it checks for an attestation:
If there's no attestation, the action is blocked. The interesting part: the absence of a signature is itself evidence. An agent can't claim it was authorized if there's no cryptographic proof that it was.
Security model: the private key never leaves your machine. The agent only calls verify, never attest. Attest is a human command. As secure as SSH key storage - same threat model, no central authority to compromise.
The repo has a working demo - an agent running 5 actions, 2 attested, 3 blocked — and a protocol spec at v1.0.0 (CC0, public domain). Anyone can implement the protocol in any language.
What's not there yet: multi-device sync and a Python package. Would appreciate feedback on the protocol design, especially the action class format (namespace:action:scope) and whether the signing model covers edge cases I haven't thought of.
Nice protocol design — the "absence of signature is itself evidence" framing is exactly right.
Oath solves the authorization layer: did a human approve this action before it ran. Titan Gate sits one layer up: did the AI-written code that resulted from those actions get cryptographically receipted before it shipped.
The two compose cleanly. Oath attests the human intent. Titan Gate receipts the code change that follows. Both are needed for a complete audit trail in a SOC2 environment.
Our receipt model: every PR gets HMAC-SHA256 signed, Merkle-ledgered, with SOC2 control mappings (CC6/CC7/CC8) embedded in the receipt JSON. The receipt travels with the code. Verify command:
pip install titan-gate
titan verify receipt.json --key 0dd06d207d711486523b21fe027681d05fc13c10ac313d979fc1e7de657d2447
Live receipt from today: 89bd57ed-b7e1-455a-9f63-5d0005d8d27f
On your protocol design — the namespace:action:scope format looks solid. One edge case worth considering: replay attacks where a valid attestation for action A gets reused for a structurally identical action A'. How are you scoping attestations to a specific execution context rather than just action class?
https://github.com/Rehanrana11/titan-gate
Oath is an open protocol for cryptographically signed human intent. Before an agent acts, it checks for an attestation:
oath attest --action "database:delete_records:project_alpha" \
oath verify --action "database:delete_records:project_alpha"# → ATTESTED proof: a1b2c3d4
If there's no attestation, the action is blocked. The interesting part: the absence of a signature is itself evidence. An agent can't claim it was authorized if there's no cryptographic proof that it was.
Security model: the private key never leaves your machine. The agent only calls verify, never attest. Attest is a human command. As secure as SSH key storage - same threat model, no central authority to compromise.
The repo has a working demo - an agent running 5 actions, 2 attested, 3 blocked — and a protocol spec at v1.0.0 (CC0, public domain). Anyone can implement the protocol in any language.
What's not there yet: multi-device sync and a Python package. Would appreciate feedback on the protocol design, especially the action class format (namespace:action:scope) and whether the signing model covers edge cases I haven't thought of.