Repository navigation
docs: say deployers need secret operate, share agent grants full administration, and how to read a principal id again - #3693
Conversation
…nistration, and how to read a principal id again
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. What this changesThe IAM guide explains deployment credential permissions, Share Agent’s native administration grant, and how administrators can retrieve a person’s principal ID. Example: An administrator grants Agent deploy access for an Agent with a bound Secret.
Review scores
ProductKind: Docs · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open: it makes useful, source-backed IAM documentation corrections, with no actionable defects found; collaborator authorship and repository policy also require keeping it open. Priority: P3 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherThe IAM guide helps administrators translate account identities and intended Agent access into exact-resource Roles and AccessBindings enforced by the controller. flowchart LR
A[Administrator] --> B[IAM guide]
B --> C[Account inspection API]
B --> D[Roles and AccessBindings]
D --> E[Controller authorization]
E --> F[Agent deployment]
Technical reviewBest possible solution: Land the focused guide clarification while preserving the existing authorization and sharing contracts. Do we have a high-confidence way to reproduce the issue? The main-branch guide omits these explicit explanations, while controller authorization, account routes, and the existing sharing reference establish the documented behavior. Is this the best way to solve the issue? The small additions address the reported guidance gaps in their existing owning guide without changing permissions or promising unsupported account discovery. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 45aaad657728. Provenance checked
SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 25, 2026, 8:27 PM ET / October 26, 2026, 00:27 UTC. |
Problem
A non-admin console walk that followed the IAM guide (dogfood finding D738) hit three gaps in
docs/guides/topics/iam.md:deploywithout Secretoperateon the bound Secrets was refused at deploy time; the guide does not say deploying needs it apart fromupdate.principalIdis shown once, in the account-creation response. The guide gives no way to read it again.Change
GET /api/auth/accounts/$USER_IDreturnsprincipalId, and a signed-in person findsUSER_IDinGET /api/auth/session.operateon each Secret and credential source the Agent binds, also withoutupdate; the console has no form for these grants, and Share Agent grants full native administration, so use the CLI or HTTP API.The product gaps behind these (no console least-privilege grant form; no principal ID lookup on a password-only Installation) are recorded separately, not changed here.
Verification
getAgentSecretPermissions/deployAgentWithAuthorization(deploy authorizes caller Secretoperateon each bound Secret and a Secret authentication source),getAuthAccount(returnsprincipalId, needs external sign-in),getAuthSession(user.id), and the Agent sharing guide.Risks