Treating the database administrator as the attacker moves settlement out of the primary Postgres

An HMAC combines a secret key with a message, and someone without that key cannot edit the message and recompute the code ^[6]. The key sits in one service, and the application that publishes operations never receives key bytes or settlement SQL access; the processor that verifies and settles cannot issue new operation MACs ^[8]. Only the key service can issue a fresh MAC.

Khudiaiev sets out the two boundaries a code on a row cannot cross. An attacker who controls the authoritative balances changes balances directly, and an attacker who controls the service allowed to authenticate new instructions can ask it to authenticate fraudulent instructions ^[9]. "Adding a MAC column cannot repair either boundary," he wrote ^[10]. The authoritative execution state therefore lives on the Audit/Protected instance alongside the evidence, with separate runtime roles for issuance, audit and accounting, and the primary administrator cannot modify that protected state ^[11]. Java computes the debit and the credit, and protected SQL commits them atomically ^[12].

The claim under test is narrow. With administrative control of the primary database alone, the attacker cannot execute a forged, modified, or already settled operation ^[13]. A signature over a row does not cover replay. The integration authenticates exact operation content, retains independent evidence before publication, executes only the checked operation, and recovers from retries without repeating the financial effect ^[14]. For this explicitly centralized trust model, none of those four properties needs distributed consensus.

The demo runs two PostgreSQL instances, and primary is the attacker-controlled one ^[26]. Khudiaiev says the separate instances and credentials demonstrate the intended access boundaries, but that all services still run on one trusted Windows host where the common administrator can reach every process and secret ^[15]. Production separation, he writes, requires independent identities, custody and operational ownership, "not merely extra schemas under the same administrator" ^[16]. His trusted set names six elements against that one hostile database ^[24]. In my view the result transfers only when the person who can log into your primary cannot log into the host running the key service, and when the protected database has a different operational owner.

"I prefer to begin with a less fashionable question: who can change the database, and what would the application do with those changes?" Khudiaiev wrote ^[20]. He is explicit about what the module leaves alone. It does not encrypt database contents, prevent destruction of the database, or guarantee availability ^[18]. Authenticating people and applying business authorization stay with the integrating application, and the integrity module does not establish a human author's entitlement ^[19]. He introduces no new cryptographic primitive and does not claim to replace every ledger database ^[17], and describes the work as independent of his employer ^[23]. "The tests described below exercise that bounded claim; they are not a proof against every possible attack," he wrote ^[21].