SQLGuard

Field note 05

Which agent_id authorized this?

That is the pager question after an agent mutates production. Chat transcripts and model names are weak answers. A signed receipt bound to the SQL hash is a strong one.

Agents do not carry liability the way a human engineer does. They rotate keys, change prompts, swap models, and lose session memory. When something goes wrong, “Claude said it was fine” is not an audit trail.

What you want is a stable identifier for the acting agent, a hash of the exact statement that was approved, a policy version, an expiry, and a signature you can verify before execute — and again after the fact.

Identity ≠ permission

OAuth, DB roles, and API keys prove the caller can connect. They do not prove someone decided this particular UPDATE … WHERE … was allowed. Permission is a decision about a statement, not only about a principal.

SQLGuard’s wedge is deliberately narrow: own the answer to “which agent_id authorized this exact write?” Lint, scanning, and access control remain complementary.

How we bind the answer

Mint a DENY or PASS against schema + SQL + agent_id, settle when you need a paid window, burn a cert, then POST /v1/verify before execute. Fail closed if the receipt does not match.

If this is your write path

Walk one statement through the Challenge flow, or talk standing control on Gateway. Limits and honesty live on Trust and Reviews.