The Missing Check After Your Database Query

We have tools for checking whether a query is injectable. We have linters, scanners, ORMs, parameterized queries, and database policies. But after the database returns rows, most applications simply trust that the result set matches the operation that asked for it. queryguard starts there. The query may be safe. The result may still be wrong. SQL injection taught us to distrust query construction. Parameterized queries answered the question: Did the user control the query structure? That question is well understood. The tooling is mature. But it is a different question from the one queryguard asks: Did this operation receive only the rows and fields it was allowed to receive? Those two questions are not the same. A perfectly safe parameterized query can still return the wrong row — because a predicate was dropped, a join widened the result, a developer selected a column they shouldn't have, or a query was rewritten without updating its scope contract. queryguard is not a database firewall. It is not a SQL injection scanner. It is not an ORM plugin. It is a contract check for observed result sets. Where it sits The hook position is the core design decision. queryguard sits immediately after cursor execution — before any result shaping, filtering, serialization, or response mapping. cursor = conn . execute ( sql , bindings ) rows = [ dict ( row ) for row in cursor . fetchall ()] evidence = queryguard . run_check ( contract , { " contract_id " : " user_profile_lookup " , " contract_version " : " 0.1.0 " , " params " : { " user_id " : user_id }, " session " : { " tenant_id " : tenant_id }, " result " : rows , }) if evidence [ " verdict " ] != " PASS " : raise QueryguardViolation ( evidence ) return rows Not at the HTTP layer. Not inside the ORM. Not at the API gateway. Immediately after the cursor returns rows — while the result is still raw, before anything shapes or discards it. This is intentional. If rows are shaped before queryguard sees them, queryguard cannot det