KarmaSakshi Protocol

The story

Karma means action. Sakshi means witness. I built KarmaSakshi because evaluation and runtime trust are different jobs. AgentEval asks whether the agent behaved during CI. KarmaSakshi asks whether the approved real-world effect actually happened, once, and can be proven. IAM, OAuth, and policy gates sit upstream. This protocol sits after them.

Problem

Tool permissions answer one question: may this agent call this tool? They do not prove that the exact effect a human approved is the exact effect that executed. Retries, stale state, and post-approval tampering are enough to move money twice or to the wrong recipient.

Why it matters

As agents gain the ability to refund, transfer, email, and mutate records, allow/deny becomes a liability. Production systems need a protocol that binds approval to one canonical effect, revalidates at commit time, and independently observes the world afterward.

Architecture

PROPOSE → PREPARE → SEAL → AUTHORIZE → COMMIT → VERIFY → PROVE. The agent never holds a signing key and never issues its own grant. The engine is the only component that validates authorization and decides whether an adapter commit() runs. Adapters perform and independently re-observe external state. The audit journal is hash-chained. The Action Passport re-verifies seal, grant, and chain at generation time.