feat: add permission-bound Agent Keys for Google APIs - #1767
Merged
Merged
Conversation
ctkm-aelf
marked this pull request as ready for review
October 4, 2026 23:29
📊 Code coverage
Gate: line coverage must stay at or above the threshold. Ratchet plan (W21): Backend → 55%, CLI → 50%, Frontend → 30% by quarter end. |
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
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.
Summary
Google OAuth grants are too broad to express permissions such as “read files only inside this Drive folder” or “update only these spreadsheet cells.” This backend pilot adds permission-bound Agent Keys that enforce an immutable NyxID policy before forwarding a request with the owner's Google credential.
nyxid-permissionsevaluator, dedicated native REST/MCP execution, and first-party key creation/read/pause/revoke endpoints. Keys retain the opaquenyxid_ag_format and bind one personal connection, credential identity/epoch, execution configuration, expiry, and live policy revision. Ordinary proxy/MCP, credential overrides, key scope updates, and rotation cannot bypass the policy.Scope and rollout
This is an experimental backend API; there is no policy editor UI or dedicated CLI command. One Workspace connection can cover Drive, Gmail, Calendar, Docs, Sheets, and Slides. Independent account/service connections need separate keys. Additional Google REST APIs require configured catalog connections, suitable credentials, and explicit rules; this does not automatically expand Google OAuth consent or catalog access.
Generic policies constrain request inputs and JSON response format. Drive folder ancestry is a separate boundary; generic rules do not automatically implement Gmail label-membership checks or equivalent containment for other services. Streaming, gRPC, multipart/binary generic calls, nodes, platform/master credentials, pools, and organization connections are outside the pilot. Google can move a file between ancestry verification and dispatch. Hooks can withhold a completed write's response but cannot undo the write, and uncertain writes are never automatically replayed.
Upgrade all backend replicas before issuing
permission_boundkeys or generic Google policies; older replicas cannot deserialize the new purpose/resource type. No deployment or live Google trial is included.Docs: Google API permissions, native key lifecycle, Drive POC.
Test Plan
Validated on PR head
c5f854bbafter integrating main at53318994. Full CI run, CodeQL, and release planning passed. The focused native/authentication test counts below were also verified locally on the earlier integration headab95d64f:Checklist