#20596: Funding

AI-assisted: Yes (Codex-assisted) Testing level: Lightly tested (targeted unit/integration tests) ## Summary - Problem: High-risk tool execution paths did not have a shared consent enforcement layer with deterministic denial reasons and audit events; diagnostics for auth/session/context failures were inconsistent. - Why it matters: This creates bypass risk across HTTP/node invoke paths and makes production triage (pairing/token/session issues) slower and ambiguous. - What changed: - Added ConsentGate core module (`src/consent/*`): token/WAL contracts, reason-code registry, deny payload builder, in-memory store/WAL, engine (`issue/evaluate/consume/revoke/status`), and resolver. - Added config schema for `gateway.consentGate` (enabled, gatedTools, observeOnly, storagePath). - Integrated gating into `src/gateway/tools-invoke-http.ts` and `src/gateway/server-methods/nodes.ts`; added host envelope validation for `system.run` in `src/node-host/invoke.ts`. - Added regression tests for consent denials/replay/expiry/context mismatch (`src/consent/engine.test.ts`, `src/gateway/tools-invoke-http.test.ts`). - Added Control UI ConsentGuard PoC tab and docs/runbook/threat-model/grant docs. - What did NOT change (scope boundary): - No external persistent token/WAL backend yet (current store/WAL are in-memory). - No fully separate ConsentGate service mode yet (Mode B not implemented). - No default behavior change unless `gateway.consentGate.enabled` is set. ## Change Type (select all) - [ ] Bug fix - [x] Feature - [ ] Refactor - [x] Docs - [x] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [x] Skills / tool execution - [x] Auth / tokens - [x] Memory / storage - [ ] Integrations - [x] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #TBD - Related #TBD ## User-visible / Behavior Changes - New optional config keys under `gateway.consentGate.*`. - When enabled in enforce mode, gated tool calls without valid consent return structured `consent_denied` payloads with deterministic `reasonCode`. - New Control UI tab: `ConsentGuard PoC` (`/consent`) for interactive simulation and WAL visualization. - Additional docs for operator runbook/threat model and enterprise implementation plan. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`Yes`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`Yes`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: - Risk: Enforcement bugs could deny legitimate gated operations or miss edge paths. - Mitigation: Feature is default-off; observe-only mode supports safe rollout; deterministic reason codes + WAL improve triage; replay/expiry/context mismatch tests added. - Risk: In-memory token store/WAL is non-durable across restart. - Mitigation: Documented as Phase 1 limitation; external HA backend planned in later phase. ## Repro + Verification ### Environment - OS: Windows (PowerShell) - Runtime/container: Node.js v22.12.0 - Model/provider: N/A - Integration/channel (if any): HTTP `/tools/invoke` test harness - Relevant config (redacted): ```json { "gateway": { "consentGate": { "enabled": true, "observeOnly": false, "gatedTools": ["sessions_spawn"] } } } <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds ConsentGate, a consent-gated authorization layer for high-risk tool execution paths. The implementation introduces token-based consent enforcement with single-use tokens, expiry, context binding, and write-ahead logging for audit trails. **Key changes:** - Core consent engine (`src/consent/*`) with token store, WAL, reason codes, and resolution logic - Integration into HTTP tools endpoint (`tools-invoke-http.ts`) and node invoke paths (`nodes.ts`, `node-host/invoke.ts`) - Config schema extension for `gateway.consentGate` with enabled/observeOnly/gatedTools/storagePath - Comprehensive test coverage for token lifecycle, replay protection, expiry, context/session mismatch - Control UI demo tab and extensive documentation (ADR, operator runbook, threat model, grant proposals) **Issues found:** - Misleading WAL event in `evaluateOnly` function: writes `CONSENT_CONSUMED` when it should write a distinct event type since evaluate doesn't consume tokens - Config change handling loses all tokens and WAL history when reinitializing engine - Minor indentation inconsistencies in `tools-invoke-http.ts` <h3>Confidence Score: 4/5</h3> - Safe to merge with minor fixes recommended - Well-architected security feature with comprehensive tests and default-off behavior. Two logical issues found: misleading WAL event type in observe-only mode and token loss on config changes. These are non-critical since the feature is opt-in and primarily affects audit trail accuracy rather than security enforcement. Indentation issues are cosmetic. - `src/consent/engine.ts` (WAL event logic) and `src/consent/resolve.ts` (config change handling) _{Last reviewed commit: ed12dc0} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->