feat(#582): auto-approve queries covered by a pre-approving JIT grant#588
Open
babltiga wants to merge 1 commit into
Open
feat(#582): auto-approve queries covered by a pre-approving JIT grant#588babltiga wants to merge 1 commit into
babltiga wants to merge 1 commit into
Conversation
A JIT access request can opt into query pre-approval (pre_approve_queries). While the grant is APPROVED and unexpired, a query it covers (capability + table scope, DatasourcePermissionChecker semantics) is auto-approved after AI analysis instead of routing to human review, with the grant id and its final-stage approver recorded on the query, in the audit log, and on the query detail. Routing policies (incl. AUTO_REJECT and anomaly-driven escalation), HIGH/CRITICAL risk, open anomalies, the AI-failed path, and SQL re-parse failures all suppress the fast-path.
Contributor
Frontend Test Results1 144 tests 1 144 ✅ 3m 0s ⏱️ Results for commit 14d6985. |
Contributor
Coverage Report for Frontend Coverage (frontend)
File CoverageNo changed files found. |
Contributor
Backend Test Results4 676 tests 4 676 ✅ 15m 28s ⏱️ Results for commit 14d6985. |
Contributor
Backend Code Coverage
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #582
What
A JIT access request (AF-378) can now opt into query pre-approval via a new
pre_approve_queriesflag (checkbox on the Request Access form, default off, shown as a highlighted tag to the approving reviewer). While such a grant isAPPROVEDand unexpired, a submitted query it covers — matching capability (SELECT→can_read, DML→can_write, DDL→can_ddl) andallowed_schemas/allowed_tablesscope — is auto-approved (PENDING_AI → APPROVED) instead of routing to human review, with the grant and its approver recorded as the approval provenance.How
QueryReviewStateMachine(tryGrantFastPath), evaluated on the AI-completed and AI-skipped paths after routing-policy evaluation returns no match and before the plan fall-through — soAUTO_REJECT/REQUIRE_APPROVALS/ESCALATEpolicies (incl. anomaly-driven, AF-383) always win.referencedTablesis empty on parse failure, which would pass an allow-list check vacuously).access.api.AccessGrantLookupService(+AccessGrantViewwith approver provenance fromaccess_grant_decision) — a new, cycle-freeworkflow → access.apiModulith edge.DatasourcePermissionChecker(hasCapability/rejectedTables) — the exact matching used by the submission gate.core.api.QueryRequestStateService.approveByAccessGrantstampsquery_requests.approved_by_grant_idin the same locked transaction as the transition.QueryAutoApprovedEventextended with grant fields; audited asQUERY_APPROVEDwith metadata{auto_approved, source: "ACCESS_GRANT", access_grant_id, grant_approver, reason}.GET /queries/{id}gains nullableapproved_by_grant(grant id, approver, approved_at, expires_at); access-request submit body + responses gainpre_approve_queries.V112__access_grant_query_pre_approval.sql(flag column +approved_by_grant_id+ partial index).Acceptance criteria
AUTO_REJECTpolicies win over the fast-path (unit tests; ESCALATE too)e2e/tests/query-grant-pre-approval.spec.ts)Docs & website updated
docs/03-data-model.md(access_grant_request + query_requests columns)docs/04-api-spec.md(access-request body/responses, query detailapproved_by_grant)docs/05-backend.md(new "Grant-covered query auto-approval (Queries under an active approved JIT access grant still require review — auto-approve with grant justification #582)" subsection, routing-engine ordering, decision-rules table)CLAUDE.md(state-machine diagram edge)README.md(JIT feature bullet)website/index.html(JIT use-case benefit line),website/docs/index.html(JIT section paragraph)Verification
mvn verify -Pcoverage— 4667 tests green (incl.ApplicationModulesTest,ApiPackageDependencyTest,MessagesParityTest, new unit + Testcontainers integration tests)test:coverage(1139 tests, thresholds met) / build — greenquery-grant-pre-approval.spec.ts(positive: request → approve → covered query auto-approved and executed with no reviewer action, detail shows grant provenance; negative: a grant without the flag keeps human review). The only failure is the pre-existing flakyquery-scheduling.spec.tstiming race (20s wait vs the job'slockAtLeastFor=PT30Scadence, masked in CI by retries — untouched by this change, flagged for a separate fix).