Skip to content

Administration IA phase 1: re-shelve the SaaS side into get-started / concepts / guides / reference - #21056

Open
jkodroff wants to merge 4 commits into
masterfrom
jkodroff/restructure-admin-ia
Open

Administration IA phase 1: re-shelve the SaaS side into get-started / concepts / guides / reference#21056
jkodroff wants to merge 4 commits into
masterfrom
jkodroff/restructure-admin-ia

Conversation

@jkodroff

Copy link
Copy Markdown
Member

Phase 1 of the Administration IA restructure (#21051). Moves the 46 SaaS-side pages onto the four standard shelves so the section is organized by document type rather than topic, matching iac/, esc/, deployments/, and idp/.

Pure git mv + alias. Zero prose edits — every moved page keeps its full existing alias chain and gains its old URL on top. The only body changes are link retargets.

Fixes #21052.

Structure

administration/
├── get-started/     ← onboarding-guide/ (5 pages), retitled "Get Started"
├── concepts/        ← the org and access model (13 pages) + new landing page
│   └── rbac/        ← the RBAC model (6 pages)
├── guides/          ← SAML, SCIM, OIDC, log export, CMK, least privilege (24 pages) + new landing pages
├── reference/       ← the four RBAC scope tables + new landing pages
└── self-hosting/    ← untouched (phase 2, #21053), menu weight 40 → 50

Decisions worth a look

Billing managers landed in concepts/, not guides/. The issue mapped it to guides; the page defines what the Billing Manager role is, so it sits beside organizations, accounts, and agent accounts.

The two redirect stubs are deleted, not retargeted. The issue called for keeping organizations-teams/teams.md and access-identity/stack-permissions.md in place with a new redirect_to. That would have kept their directories alive, and Hugo renders a section list page at /docs/administration/organizations-teams/ — the exact URL we need to alias onto concepts/. Hugo skips an alias whose target path already has a page, so the container redirect would have been silently dropped. Folding each stub's aliases onto its real page vacates all three directories cleanly and gives readers one hop instead of two.

⚠️ One regression: /docs/administration/access-identity/stack-permissions/ now lands at the top of the permission-sets page rather than #stack-permission-sets. A Hugo alias can't carry a fragment. Easy to revert to a redirect_to stub if we'd rather keep the anchor.

Get-started naming settled. The page's title and menu label disagreed ("Setting Up Pulumi for Your Organization" vs. "Onboarding Guide"). Now title: Get Started / h1: Get started with Pulumi Cloud. The broader question of whether the section should be named "Administration" is deliberately out of scope — /docs/pulumi-cloud/ is currently an alias on administration/_index.md, so a section rename needs untangling first.

Three ESC pages lost their secondary administration: menu entry. esc/concepts/approvals.md, esc/concepts/customer-managed-keys.md, and esc/administration/audit-logs.md were parented to administration-security-compliance, which this PR deletes. They stay in the esc menu.

layouts/shortcodes/identities.html had to move. It carried a relref to /docs/administration/access-identity/saml/, and refLinksErrorLevel: ERROR makes that a hard build failure rather than a 404.

Also updated

/docs/administration/ section cards, data/glossary.toml, data/pulumi_pricing.yaml, layouts/index.llms.txt, the 7 S3 redirect targets in scripts/redirects/, and ~115 files of inbound links across content/docs, content/tutorials, content/what-is, and content/releases. content/blog/ is deliberately untouched — aliases cover it, per AGENTS.md.

Added a pointer from the new reference/ landing page to the Pulumi Cloud REST API.

Verification

  • make lint — 0 errors
  • make build — clean
  • scripts/alias-verification/verify-aliases.py — 45/45 renames correct, 0 missing, 0 suspicious. The 6 deleted URLs were confirmed aliased by hand (the extractor writes deletes to a separate file the verifier doesn't read).
  • Rendered sidebar checked against a local build: get-started → concepts → guides → reference → self-hosting, correct nesting, no orphans, no menu leakage.
  • Old URLs spot-checked in public/, including deep legacy chains (/docs/intro/pulumi-cloud/scopes/stacks/, /docs/pulumi-cloud/access-management/saml/okta/).

Not fixed here

content/docs/deployments/guides/oidc/*.md reference /docs/administration/access-identity/oidc/provider/*. These turned out not to be rot — they're live aliases owned by those very pages, so nothing was broken and nothing needed changing.

🤖 Generated with Claude Code

https://claude.ai/code/session_012VLSi7rdf7rrDaHm9rNd8c

jkodroff and others added 2 commits August 21, 2026 15:30
Move the 46 SaaS-side Administration pages onto the standard docs shelves —
get-started / concepts / guides / reference — so the section is organized by
document type rather than topic, matching iac/, esc/, deployments/, and idp/.

Pure git mv + alias. No prose edits: every moved page keeps its full existing
alias chain and gains its old URL on top.

- get-started/    <- onboarding-guide/ (5 pages), retitled "Get Started"
- concepts/       <- the org and access model (12 pages) + new landing page
- guides/         <- SAML, SCIM, OIDC, audit-log export, CMK, least privilege,
                     billing managers (25 pages) + new landing pages
- reference/      <- the four RBAC scope tables + new landing pages

The three retired container landing pages and the two redirect stubs are
deleted with their aliases folded onto the real pages, so all three
directories vacate cleanly. Leaving a stub behind would have kept its
directory alive, and Hugo skips an alias whose target path already has a
page — silently dropping the container redirect.

Also updates every inbound link outside content/blog/ (which aliases cover),
including data/glossary.toml, data/pulumi_pricing.yaml, layouts/index.llms.txt,
the S3 redirect targets, and the relref in layouts/shortcodes/identities.html
that would otherwise fail the build.

Part of #21051. Fixes #21052.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012VLSi7rdf7rrDaHm9rNd8c
Billing Manager is a role in the access model, not a procedure — the page
defines what the role is and what it can see, so it belongs beside
organizations, accounts, and agent accounts rather than under guides/.
That empties the guides/ "Organization management" group.

Also adds a pointer from the reference landing page to the Pulumi Cloud
REST API, which is where the programmatic half of administration lives.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012VLSi7rdf7rrDaHm9rNd8c
@jkodroff
jkodroff marked this pull request as ready for review August 21, 2026 19:47
@jkodroff
jkodroff requested a review from CamSoper August 21, 2026 19:47
@github-actions github-actions Bot added review:triaging Claude Triage is currently classifying the PR domain:docs PR touches technical docs review:in-progress Claude review is currently running and removed review:triaging Claude Triage is currently classifying the PR labels Aug 21, 2026

@unblocked unblocked Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found.

About Unblocked

Unblocked has been set up to automatically review your team's pull requests to identify genuine bugs and issues.

📖 Documentation — Learn more in our docs.

💬 Ask questions — Mention @unblocked to request a review or summary, or ask follow-up questions.

👍 Give feedback — React to comments with 👍 or 👎 to help us improve.

⚙️ Customize — Adjust settings in your preferences.

Comment on lines +50 to +53
- [Stacks](stacks)
- [Environments](environments)
- [Cloud accounts](insights-accounts)
- [Organization settings](org-settings)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These relative links resolve from the rendered URL /docs/administration/concepts/rbac/scopes/ to paths like /docs/administration/concepts/rbac/scopes/stacks, but the scope detail pages were moved to /docs/administration/reference/rbac-scopes/. This will result in 404 errors for users.

The reference/rbac-scopes/_index.md landing page uses the correct absolute paths — these should match:

Suggested change
- [Stacks](stacks)
- [Environments](environments)
- [Cloud accounts](insights-accounts)
- [Organization settings](org-settings)
- [Stacks](/docs/administration/reference/rbac-scopes/stacks/)
- [Environments](/docs/administration/reference/rbac-scopes/environments/)
- [Cloud accounts](/docs/administration/reference/rbac-scopes/insights-accounts/)
- [Organization settings](/docs/administration/reference/rbac-scopes/org-settings/)

@pulumi-bot

pulumi-bot commented Aug 21, 2026

Copy link
Copy Markdown
Collaborator

Your site preview for commit 9ab16ba is ready! 🎉

http://www-testing-pulumi-docs-origin-pr-21056-9ab16bad.s3-website.us-west-2.amazonaws.com

Changed pages:

@pulumi-bot

pulumi-bot commented Aug 21, 2026

Copy link
Copy Markdown
Collaborator

Lighthouse Performance Report

Commit: 9ab16ba | Metric definitions

Page Device Score FCP LCP TBT CLS SI
Homepage Mobile 🔴 37 6.4s 14.6s 1027ms 0.000 6.4s
Homepage Desktop 🟡 85 1.1s 2.2s 132ms 0.024 1.1s
Install Pulumi Mobile 🟡 58 5.5s 13.8s 196ms 0.053 5.5s
Install Pulumi Desktop 🟡 86 1.0s 2.3s 0ms 0.022 1.0s
AWS Get Started Mobile 🟡 58 5.3s 12.8s 57ms 0.116 5.3s
AWS Get Started Desktop 🟡 87 1.0s 2.1s 0ms 0.071 1.0s

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Optional style suggestions from the pre-merge review — apply or dismiss; none of them block.


Generated by Claude Code

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Pre-merge Review — Last updated 2026-08-21T21:57:12Z

Tip

Summary: This is a pure information-architecture change: the Pulumi Cloud administration docs are re-shelved from access-identity/ / organizations-teams/ / security-compliance/ / onboarding-guide/ into a Diátaxis-shaped get-started/ / concepts/ / guides/ / reference/ tree, with four new section landing pages and site-wide link rewrites across 143 files. Almost nothing is new prose — the wrongness that would block a reader here is a broken link or a stale path, so that is where the review concentrated. The structural news is good: Hugo builds clean (0 errors, 0 link-integrity breaks), all 52 new URLs render, and every one of the 51 removed URLs is covered by an aliases: entry on its successor page. The two genuine breaks the first pass found — the relative "Available scopes" links and the #default-roles anchor, both in content/docs/administration/concepts/rbac/scopes.md — are fixed and re-verified at 9ab16ba, along with a third of the same class that @jkodroff found by auditing for it (roles.mdaccess-tokens/#organization-access-tokens, which the first pass missed). Nothing is outstanding. The remaining ⚠️ item is inherited text this PR only link-rewrote; the rest of that bucket was adjudicated by the author and moved to ✅. Please read the 📋 Triaged section before reacting to the counts — the automated link check resolved paths against master rather than this branch, so it reported ~48 of the paths this PR creates as missing. Those were re-checked against the PR head tree and are all fine. One follow-up outside this diff: content/blog/short-lived-access-tokens/index.md still links at the old access-identity/access-tokens/ path and uses the dead #organization-access-tokens fragment — the alias will carry the path, but the fragment won't resolve. Historical blog content, so out of scope here.

Review confidence:

Dimension Level Notes
mechanics HIGH Hugo build + sitemap diff: 0 errors, 0 link-integrity breaks, 52 added / 51 removed URLs all alias-covered. Every fix in 9ab16ba re-resolved against the head tree.
facts MEDIUM Path/anchor claims re-resolved against the PR head tree by hand. Product-behavior and UI-navigation claims carried over unchanged from the source pages were not independently re-verified — the author has accepted those as-is.
coherence HIGH The four new landing pages, the nav weights, and the concepts↔guides cross-references line up.
cross-sibling consistency HIGH 7 of 7 siblings read; one meta_desc/body mismatch found (guides/_index.md), fixed in 9ab16ba.
Investigation log
  • Cross-sibling reads: 7 of 7 siblings
  • External claim verification: 358 of 490 claims verified (14 unverifiable, 51 contradicted, 4 framing-drift) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 454 Pass 1, 20 Pass 2 (verified 11, contradicted 1, unverifiable 8), 16 Pass 3 (verified 12, contradicted 2, unverifiable 2).
  • Cited-claim spot-checks: 20 of 20 cited claims fetched and compared
  • Frontmatter sweep: ran on body + meta_desc
  • Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
  • Code execution: not run (no static/programs/ change)
  • Code-examples checks: not run (no fenced code blocks in content files)
  • Editorial-balance pass: not run (not under content/blog/)
🚨 Outstanding ⚠️ Low-confidence 💡 Pre-existing ✅ Resolved
0 1 6 15

🔍 Verification trail

490 claims extracted · 358 verified · 14 unverifiable · 51 contradicted · 4 framing-drift · 10 detector findings
  • L22-23 in content/docs/administration/_index.md "The 'Get Started' link on the Pululmi administration docs landing page points to /docs/administration/get-started/." → ✅ verified (evidence: In content/docs/administration/_index.md front matter, link_buttons.primary has label: Get Started and link: /docs/administration/get-started/, matching the claim exactly.; source: repo:content/docs/administration/_index.md)
  • L30-32 in content/docs/administration/_index.md "The Pulumi administration 'Get Started' guidance covers setting up Pulumi for an organization with guidance on editions, security, team structure, and…" → ✅ verified (framing: Source says "subscriptions" where claim says "editions" — the onboarding guide's subpages (e.g., choose-edition) do cover editions specifically, so this is a…; evidence: (escalated from pass1 after exhausting its 12-turn cap) The Pulumi Administration index page's "Get Started" link is described as: "Set up Pulumi for your organization with guidance on subscriptions, security, team structure, and…; source: https://www.pulumi.com/docs/administration/)
  • L32 in content/docs/administration/_index.md "The Get Started guide covers setting up Pulumi for your organization with guidance on editions, security, team structure, and migration." → 🤝 matches (evidence: The claim paraphrases the sibling card description in the same file: "Get Started ... Set up Pulumi for your organization with guidance on editions, security, team structure, and migration." (content/docs/administration/_index.md). The…; source: repo:content/docs/administration/_index.md and repo:content/docs/administration/get-started/_index.md)
  • L35-37 in content/docs/administration/_index.md "The Pulumi administration 'Concepts' section covers organizations, accounts, billing managers, access tokens, role-based access control, audit logs, and…" → ✅ verified (evidence: The Concepts index page (/docs/administration/concepts/) lists exactly these topics: Organizations, Accounts, Billing managers, Access tokens, RBAC, Audit logs, and Customer managed keys, matching the claim's description verbatim (also…; source: repo:content/docs/administration/concepts/_index.md)
  • L37 in content/docs/administration/_index.md "The Concepts page covers organizations, accounts, billing managers, access tokens, role-based access control, audit logs, and customer managed keys." → ✅ verified (evidence: content/docs/administration/concepts/_index.md lists exactly these subtopics: Organizations, Accounts, Billing managers, Access tokens, Role-based access control (RBAC), Audit logs, and Customer managed keys — matching the claim's…; source: repo:content/docs/administration/concepts/_index.md)
  • L39-42 in content/docs/administration/_index.md "The Pulumi administration 'Guides' section covers configuring SAML SSO, SCIM provisioning, OIDC issuers, audit log export, customer managed keys, and least…" → ✅ verified (evidence: The Guides card in content/docs/administration/_index.md links to /docs/administration/guides/ and its description reads verbatim: "Configure SAML SSO, SCIM provisioning, OIDC issuers, audit log export, customer managed keys, and least…; source: repo:content/docs/administration/_index.md)
  • L42 in content/docs/administration/_index.md "The Guides page covers configuring SAML SSO, SCIM provisioning, OIDC issuers, audit log export, customer managed keys, and least privilege." → ✅ verified (evidence: The Guides index page (content/docs/administration/guides/_index.md) lists exactly these topics as guide pages: SAML SSO, SCIM, OIDC issuers, Export audit logs, Customer managed keys, and Least privilege — matching the claim verbatim.; source: repo:content/docs/administration/guides/_index.md)
  • L44-47 in content/docs/administration/_index.md "The Pulumi administration 'Reference' section includes lookup tables, including the complete catalog of RBAC scopes." → ✅ verified (evidence: The linked page /docs/administration/reference/ states: "Enumerations you consult rather than read end to end. - RBAC scopes — the complete catalog of permission scopes, grouped by the…; source: repo:content/docs/administration/reference/_index.md)
  • L47 in content/docs/administration/_index.md "The Reference page includes lookup tables, including the complete catalog of RBAC scopes." → ✅ verified (evidence: The Reference index page (content/docs/administration/reference/_index.md) states its meta description as "Lookup material for administering Pulumi Cloud — the complete catalog of RBAC scopes and the Pulumi Cloud REST API" and links to…; source: repo:content/docs/administration/reference/_index.md and repo:content/docs/administration/reference/rbac-scopes/_index.md)
  • L49-52 in content/docs/administration/_index.md "The Pulumi administration docs 'Self-Hosting' card links to /docs/administration/self-hosting/." → ✅ verified (evidence: Lines 49-52 of content/docs/administration/_index.md show: heading: Self-Hosting, link: /docs/administration/self-hosting/, confirming the card links exactly as claimed.; source: repo:content/docs/administration/_index.md)
  • L49-52 in content/docs/administration/_index.md "The Self-Hosting page describes deploying Pulumi Cloud in your own infrastructure with the Business Critical edition." → ✅ verified (evidence: The linked self-hosting page (content/docs/administration/self-hosting/_index.md) states: "Self-hosting is only available with Pulumi Business Critical." and describes deploying "Pulumi Cloud in your own infrastructure with full…; source: repo:content/docs/administration/self-hosting/_index.md)
  • L5 in content/docs/administration/concepts/_index.md "The Pulumi Cloud organization and access model includes organizations, accounts, billing managers, access tokens, RBAC, audit logs, and customer-managed keys." (also L23) → ➖ not-a-claim (evidence: The line is the page's own meta description summarizing the concepts index, which links to child pages for Organizations, Accounts, Billing managers, Access tokens, RBAC, Audit logs, and Customer managed keys — all present in the same…; source: repo:content/docs/administration/concepts/_index.md)
  • L12-13 in content/docs/administration/concepts/_index.md "The page at /docs/administration/concepts/ is aliased from the former URL /docs/administration/organizations-teams/." → ✅ verified (evidence: The page's frontmatter explicitly lists aliases:\n - /docs/administration/organizations-teams/, confirming the redirect from the former URL.; source: repo:content/docs/administration/concepts/_index.md)
  • L16 in content/docs/administration/concepts/_index.md "How Pulumi Cloud models your organization and who can do what inside it. Read these to understand the system; see Guides for…" → ✅ verified (evidence: content/docs/administration/guides/_index.md exists, titled "Guides", and states "Procedures for setting up and running a Pulumi Cloud organization... For the model these guides configure, see Concepts"…; source: repo:content/docs/administration/guides/_index.md)
  • L20 in content/docs/administration/concepts/_index.md "Organizations are the top-level container that owns a Pulumi Cloud user's stacks, environments, and settings." → ➖ not-a-claim (evidence: This line is the PR author's own summary blurb for a link to /docs/administration/concepts/organizations/ within the new Concepts index page — it describes the target page's content in the author's own words rather than asserting an…; source: repo:content/docs/administration/concepts/_index.md (L20))
  • L21-22 in content/docs/administration/concepts/_index.md "Agent accounts are accounts for AI agents and automation acting on an organization's behalf in Pulumi Cloud." → ✅ verified (framing: Source describes agent accounts as "ephemeral Pulumi Cloud accounts provisioned automatically for agents" enabling agent action without signup; claim's…; evidence: Multiple existing Pulumi docs pages describe agent accounts identically: "Agent accounts ... ephemeral Pulumi Cloud accounts provisioned automatically for agents" and "agents can use free, ephemeral Pulumi Cloud accounts... This lets an…; source: gh search code --owner pulumi repo:pulumi/docs "agent-accounts" (content/docs/ai/cli-for-agents/index.md, content/blog/the-agentic-infrastructure-era/index.md))
  • L23 in content/docs/administration/concepts/_index.md "Access tokens (personal, team, and organization) are used for authenticating the CLI, CI/CD, and the REST API in Pulumi Cloud." → ✅ verified (evidence: The linked access-tokens.md page states "Use access tokens to sign into the Pulumi Cloud via the CLI or automate your usage of the Pulumi Cloud using the REST API," lists personal, organization, and team tokens as the three types, and…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L27 in content/docs/administration/concepts/_index.md "Pulumi Cloud's role-based access control (RBAC) system is composed of entities, scopes, permission sets, roles, and teams, with permissions accumulating…" → ✅ verified (evidence: The linked page /docs/administration/concepts/rbac/ states "Pulumi Cloud's RBAC system is built on these core concepts: Scopes, Permission sets, Entities and organization-level access, Roles, Teams" and includes a "How permissions…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L31 in content/docs/administration/concepts/_index.md "Audit logs in Pulumi Cloud record user and system activity within an organization." → ✅ verified (evidence: The same _index.md file describes the linked Audit logs page as "the record of user and system activity in your organization," matching the claim that audit logs record user and system activity within an organization.; source: repo:content/docs/administration/concepts/_index.md)
  • L32 in content/docs/administration/concepts/_index.md "Customer managed keys in Pulumi Cloud allow a customer to use their own encryption keys to protect data at rest." → 🌀 framing-drift (framing: overclaim — source qualifies "Currently... only used to encrypt data in Pulumi ESC, and only AWS KMS is supported" while claim asserts general "protect data…; evidence: The customer-managed-keys page confirms CMKs let customers "use your own encryption keys to protect sensitive data in Pulumi Cloud," but explicitly scopes this: "Currently, Customer Managed Keys are only used to encrypt data in Pulumi…; source: content/docs/administration/concepts/customer-managed-keys.md)
  • L9-10 in content/docs/administration/concepts/access-tokens.md "In the docs navigation menu, the 'Access tokens' page has parent 'administration-concepts' and weight 4 (later changed to weight 5)." → ✅ verified (evidence: The file's front matter currently shows parent: administration-concepts and weight: 5 under the administration menu, matching the claim's final stated state.; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L34 in content/docs/administration/concepts/access-tokens.md "Organization and team access tokens are machine tokens not connected to a user account, and therefore should only be used in scenarios like CI/CD pipelines…" → ✅ verified (evidence: The claim is a near-verbatim restatement of the doc's own security best-practices bullet: "Organization and team access tokens are machine tokens that are not connected to a user account, and therefore should only be used in scenarios…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L35 in content/docs/administration/concepts/access-tokens.md "Expired access tokens cannot be refreshed or reactivated." → ✅ verified (evidence: The same doc independently and consistently describes no refresh/reactivation path: expired or non-compliant tokens must be "recreated with a compliant expiry" (org/team tokens) or the member "must create a new token with a compliant…; source: repo:content/docs/administration/concepts/access-tokens.md (lines 138, 142))
  • L35 in content/docs/administration/concepts/access-tokens.md "Organization administrators can make token expiries mandatory with an access token expiry policy, documented at #access-token-expiry-policy." → ✅ verified (evidence: The same file defines the linked section: "## Access token expiry policy / Organization administrators can enforce a maximum expiry on the access tokens used against their organization. When a policy is set, personal, organization, and…; source: repo:content/docs/administration/concepts/access-tokens.md (lines 35, 108-110))
  • L35 in content/docs/administration/concepts/access-tokens.md "Access tokens can optionally be assigned an expiration period of up to two years, at which point the token will no longer be valid for any Pulumi operation." → ✅ verified (evidence: The Pulumi docs page on access tokens states verbatim: "Tokens can optionally be assigned an expiration period of up to two years, at which point the token will no longer be valid for any Pulumi operation."; source: https://www.pulumi.com/docs/administration/access-identity/access-tokens/)
  • L36 in content/docs/administration/concepts/access-tokens.md "To prevent a long-lived token from accumulating Stack Admin on every stack it creates, automation can transfer stack ownership to a break-glass user or team…" → 🤝 matches (evidence: A sibling docs page (content/docs/administration/security-compliance/least-privilege/_index.md) independently describes the identical mitigation pattern: "Keep that under control by making the hand-off part of the run: once the stack…; source: gh search code --owner pulumi "creator-grants" "Stack Admin" (pulumi/docs:content/docs/administration/security-compliance/least-privilege/_index.md))
  • L36 in content/docs/administration/concepts/access-tokens.md "The RBAC documentation, now located at /docs/administration/concepts/rbac/, describes how org-wide settings and role scopes interact." → 🤝 matches (evidence: The RBAC page exists at content/docs/administration/concepts/rbac/_index.md (URL /docs/administration/concepts/rbac/) and covers exactly this: "Organization-wide role settings establish the baseline permissions that every member receives…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L36 in content/docs/administration/concepts/access-tokens.md "The Stack Admin creator grant from a token-created stack is held by the machine identity the token authenticates as, not by the person who created the token…" → ✅ verified (evidence: The linked rbac/#creator-grants section states: "a stack created with an organization or team token carries the same automatic grant, held by the machine identity the token authenticates as rather than by the person who created the…; source: content/docs/administration/concepts/rbac/_index.md)
  • L72 in content/docs/administration/concepts/access-tokens.md "By assigning a custom role (documented at /docs/administration/concepts/rbac/roles/) with only the scopes automation needs, you can follow the principle of…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/roles.md exists and has a "Custom roles" section describing custom roles as combining entity access rules and scopes to grant only the permissions needed — consistent with…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L76 in content/docs/administration/concepts/access-tokens.md "By assigning different roles, an organization token can be scoped to exactly the operations the automation needs, such as a token that can only read stack…" → ✅ verified (framing: Source describes general role/permission-set/entity mechanics; claim states specific narrower examples (read-only stack state token…; evidence: The RBAC roles page confirms a role combines entity access rules (permission sets like Stack Read/Write applied to specific stacks) with org-wide access, e.g. "Direct rules grant a permission set to individually selected entities...…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L78 in content/docs/administration/concepts/access-tokens.md "Actions taken by organization tokens appear in audit logs attributed to the organization rather than an individual user, with the token's unique name…" → ✅ verified (framing: L78 restates and elaborates the summary claim already made at L29 and reinforced by the audit-log traceability rationale at L82/L100 within the same document.; evidence: The same doc states at L29 "Actions taken with organization tokens appear in audit logs attributed to the organization" and L82 requires each token name be unique "so that tokens can be reliably identified in audit logs and incident…; source: repo:content/docs/administration/concepts/access-tokens.md (L29, L82, L100))
  • L94 in content/docs/administration/concepts/access-tokens.md "Team tokens are a good fit for long-lived automation where access needs may evolve over time." → ✅ verified (evidence: The live Pulumi docs page states verbatim: "This makes team tokens a good fit for long-lived automation where access needs may evolve over time," directly following the explanation that a team token's permissions update automatically as…; source: https://www.pulumi.com/docs/administration/access-identity/access-tokens/)
  • L94 in content/docs/administration/concepts/access-tokens.md "A team token's effective permissions are the union of all roles assigned to that team (documented at /docs/administration/concepts/rbac/teams/), evaluated at…" → ✅ verified (evidence: The linked teams.md page states teams can have "multiple role assignments" and "Members of the team receive the permissions from all of those roles in addition to their own organization role," which supports the access-tokens.md claim…; source: repo:content/docs/administration/concepts/rbac/teams.md)
  • L97 in content/docs/administration/concepts/access-tokens.md "In addition to the team's role assignments, a team token also receives the organization's default Member permissions, i.e., the baseline access configured in…" → ✅ verified (framing: Source describes baseline Member permissions generally applying to org members without custom roles; claim narrows this to the specific case of team tokens…; evidence: The linked anchor exists and matches: roles.md §"Organization-wide role settings" states these settings "configure the built-in Member role: its default access levels for stacks, environments, and accounts" and apply to "members ... who…; source: content/docs/administration/concepts/rbac/roles.md#organization-wide-role-settings)
  • L100 in content/docs/administration/concepts/access-tokens.md "Team token activity is recorded in audit logs with the token's name, keeping actions traceable without exposing individual users." → ✅ verified (evidence: The same document states for organization tokens: "Actions taken by organization tokens appear in audit logs attributed to the organization rather than an individual user, with the token's unique name surfaced in every event" and…; source: repo:content/docs/administration/concepts/access-tokens.md (lines 29-30, 78, 100))
  • L127 in content/docs/administration/concepts/access-tokens.md "While an access token expiry policy is active, the Access Tokens tab shows a banner with the current cap and an Edit policy shortcut to the policy setting." → 🤷 unverifiable (evidence: The sentence in question is a first-party description of Pulumi Cloud UI behavior (a banner on the Access Tokens tab with an Edit policy shortcut). The only hyperlink in that sentence points to /docs/administration/concepts/audit-logs/…; source: content/docs/administration/concepts/access-tokens.md (line 127); content/docs/administration/concepts/audit-logs.md)
  • L148 in content/docs/administration/concepts/access-tokens.md "Web console sessions are unaffected by the access token expiry policy, as are short-lived tokens issued through OIDC token exchange (documented at…" → ✅ verified (evidence: The linked oidc-issuers page describes the exchange as producing short-lived tokens ("Workloads ... receive short-lived Pulumi access tokens in exchange" and "Max expiration — caps the duration of Pulumi access tokens issued via this…; source: content/docs/administration/guides/oidc-issuers/_index.md)
  • L150 in content/docs/administration/concepts/access-tokens.md "Requests rejected by the access token expiry policy receive a 403 Forbidden response whose message names the organization and its policy maximum." → ✅ verified (evidence: An independent Pulumi blog post on the same feature states: "rejections are designed to be self-explanatory. A blocked request fails with a 403 Forbidden that names your organization and its policy maximum" and shows an example error…; source: pulumi/docs:content/blog/access-token-expiry-policy/index.md)
  • L168 in content/docs/administration/concepts/access-tokens.md "For new automation, Pulumi recommends assigning a custom role (documented at /docs/administration/concepts/rbac/roles/) instead of the built-in Admin/Member…" → ✅ verified (evidence: The source file states: "For new automation, prefer assigning a custom role instead — custom roles let you follow the principle of least privilege by granting only the scopes your automation…; source: repo:content/docs/administration/concepts/access-tokens.md#L168; repo:content/docs/administration/concepts/rbac/roles.md)
  • L172 in content/docs/administration/concepts/access-tokens.md "Instructions for how to register and configure an issuer for OIDC-issued tokens are documented at /docs/administration/guides/oidc-issuers/." → ✅ verified (evidence: The page at content/docs/administration/guides/oidc-issuers/_index.md exists and contains "Configuring an OIDC Issuer in the UI" with a "Register the OIDC Issuer" section and "Configure the authorization policies" section, matching the…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L172 in content/docs/administration/concepts/access-tokens.md "To perform operations that require elevated access, such as creating or deleting stacks, you must explicitly request the admin scope when exchanging the OIDC…" → ❌ contradicted (framing: Source defines scope as identifying a target team/user for team/personal tokens; claim recasts it as an "admin" privilege-escalation flag, a usage not…; evidence: The cited oidc-issuers guide documents the scope parameter only as: "a single scope used when requesting a team or personal token, identifying the target team or user. Format: team:{TEAM_NAME} ... or user:{USER_LOGIN}" — there is…; source: content/docs/administration/guides/oidc-issuers/_index.md (line 160); content/docs/administration/concepts/access-tokens.md (line 172, 176-180); intuition: "admin scope" as a literal scope value isn't attested anywhere in the OIDC token-exchange parameter docs, which only…)
  • L36 in content/docs/administration/concepts/accounts.md "* Add an organization backed by Atlassian, GitHub, GitLab, or a SAML 2.0-compatible identity provider, such…" → ✅ verified (framing: Source states general SAML 2.0 support with Okta/Google Workspace guides; claim's mention of Active Directory as an example SAML 2.0 IdP is a narrower…; evidence: The linked page /docs/administration/concepts/organizations/ confirms organizations can be backed by GitHub, GitLab, Bitbucket (Atlassian), or SAML 2.0 identity providers: "Pulumi Cloud supports any SAML 2.0-based identity provider" with…; source: repo:content/docs/administration/concepts/organizations.md)
  • L12 in content/docs/administration/concepts/agent-accounts.md "- /docs/administration/organizations-teams/agent-accounts/" → ➖ not-a-claim (evidence: The line is a Hugo aliases front-matter entry that sets up a redirect from the old URL path (/docs/administration/organizations-teams/agent-accounts/) to this page. It's routing metadata, not a falsifiable factual assertion.; source: repo:content/docs/administration/concepts/agent-accounts.md)
  • L80 in content/docs/administration/concepts/agent-accounts.md "- Pulumi Cloud accounts" → ✅ verified (evidence: The parent Concepts index page (content/docs/administration/concepts/_index.md) lists "Accounts — individual user accounts, profiles, and identity providers." confirming this is a valid…; source: repo:content/docs/administration/concepts/_index.md)
  • L9-11 in content/docs/administration/concepts/audit-logs.md "The Audit Logs page is now organized under the 'administration-concepts' parent navigation section instead of 'administration-security-compliance'." → ✅ verified (evidence: The file's frontmatter sets parent: administration-concepts under the administration menu, and its aliases list includes /docs/administration/security-compliance/audit-logs/, confirming the page was moved from the…; source: repo:content/docs/administration/concepts/audit-logs.md)
  • L20 in content/docs/administration/concepts/audit-logs.md "/docs/administration/security-compliance/ is a valid alias URL that redirects to this Audit Logs concepts page." → ✅ verified (evidence: The page's frontmatter aliases list at line 20 literally contains - /docs/administration/security-compliance/, which in Hugo generates a redirect from that URL to this Audit Logs concepts page.; source: repo:content/docs/administration/concepts/audit-logs.md (frontmatter aliases, line 20))
  • L60 in content/docs/administration/concepts/audit-logs.md "The AWS S3 export guide for audit logs is located at /docs/administration/guides/export-audit-logs/aws-s3/." → ❌ contradicted (evidence: The pulumi/docs repo has no path content/docs/administration/guides/export-audit-logs/aws-s3/. The actual AWS S3 export guide lives at content/docs/administration/security-compliance/audit-logs/aws-s3.md, and the sibling file…; source: gh api repos/pulumi/docs/contents/content/docs/administration/security-compliance/audit-logs)
  • L64 in content/docs/administration/concepts/audit-logs.md "The Microsoft Sentinel export guide for audit logs is located at /docs/administration/guides/export-audit-logs/azure-sentinel/." → ✅ verified (evidence: The file content/docs/administration/guides/export-audit-logs/azure-sentinel.md exists and is titled "Export to Microsoft Sentinel" / "Export audit logs to Microsoft Sentinel", matching the linked path and description in audit-logs.md…; source: repo:content/docs/administration/guides/export-audit-logs/azure-sentinel.md)
  • L14 in content/docs/administration/concepts/customer-managed-keys.md "- /docs/administration/security-compliance/customer-managed-keys/" → ➖ not-a-claim (evidence: This is an aliases frontmatter entry recording that this page was previously located at /docs/administration/security-compliance/customer-managed-keys/. It's redirect/routing metadata for the page itself, not a falsifiable factual…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L68 in content/docs/administration/concepts/customer-managed-keys.md "described here." → ✅ verified (evidence: The target page content/docs/administration/guides/customer-managed-keys/aws-kms.md exists, has title "AWS KMS" and menu identifier "administration-guides-customer-managed-keys-aws-kms" (parent…; source: repo:content/docs/administration/guides/customer-managed-keys/aws-kms.md)
  • L9 in content/docs/administration/concepts/organizations.md "The Organizations documentation page's menu entry has a parent of administration-concepts." → ✅ verified (evidence: The frontmatter at line 9 reads parent: administration-concepts, exactly matching the claim.; source: repo:content/docs/administration/concepts/organizations.md)
  • L99-102 in content/docs/administration/concepts/organizations.md "If a user needs to delegate billing-only access to a team member without granting full admin rights, they should see the Billing Managers guide at…" → ✅ verified (evidence: The Billing Managers page actually lives at content/docs/administration/concepts/billing-managers.md (menu parent: administration-concepts), which resolves to /docs/administration/concepts/billing-managers/ exactly as the claim/link…; source: repo:content/docs/administration/concepts/billing-managers.md)
  • L118-121 in content/docs/administration/concepts/organizations.md "Both permissions required to transfer a stack are configured through the organization's access controls, as described in the Role-based access control page…" → ✅ verified (evidence: organizations.md line 121 reads "Transferring a stack requires two permissions... Both are configured through your organization's access controls — see Role-based access control for details." The…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L119 in content/docs/administration/concepts/organizations.md "Stack admins can transfer individual stacks between personal accounts and organizations, or between organizations." → ✅ verified (evidence: The same doc section states: "Stack admins can transfer individual stacks between personal accounts and organizations, or between organizations. Organization admins can transfer stacks in bulk." This is immediately followed by consistent…; source: repo:content/docs/administration/concepts/organizations.md (lines 117-135))
  • L179-182 in content/docs/administration/concepts/organizations.md "A Pulumi organization can also be backed by a SAML 2.0 identity provider, as described at /docs/administration/guides/saml/." → ✅ verified (evidence: The linked page content/docs/administration/guides/saml/_index.md states: "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," matching the claim that organizations can be backed by a SAML 2.0 identity…; source: repo:content/docs/administration/guides/saml/_index.md)
  • L247 in content/docs/administration/concepts/organizations.md "Pulumi Cloud supports any SAML 2.0-based identity provider." → ✅ verified (evidence: The dedicated SAML guide index states: "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," and lists integration guides for Entra ID, Google Workspace, JumpCloud, Okta, Auth0, and OneLogin — consistent with…; source: repo:content/docs/administration/guides/saml/_index.md)
  • L249-253 in content/docs/administration/concepts/organizations.md "Documentation for configuring Microsoft Entra ID as a SAML identity provider is located at /docs/administration/guides/saml/entra/." → ✅ verified (evidence: Found the file content/docs/administration/guides/saml/entra.md, titled "Configuring Microsoft Entra ID" and identified with menu identifier "pulumi-cloud-access-management-saml-entra" under parent "administration-guides-saml" — this…; source: repo:content/docs/administration/guides/saml/entra.md)
  • L255 in content/docs/administration/concepts/organizations.md "Members of SSO organizations can log in to Pulumi with the organization name auto-filled in the UI by visiting https://app.pulumi.com/welcome/<organization-nam…" → ✅ verified (evidence: (escalated from pass1) The Pulumi Cloud Organizations doc states verbatim: "Members of SSO organizations can login to Pulumi with the organization name auto-filled in the UI by visiting…; source: https://www.pulumi.com/docs/administration/organizations-teams/organizations/)
  • L8-9 in content/docs/administration/concepts/rbac/_index.md "- /docs/administration/access-identity/rbac/" → ➖ not-a-claim (evidence: The line is part of Hugo front matter aliases: list on the RBAC concepts page, providing a redirect from the old URL /docs/administration/access-identity/rbac/ to the current page. It's redirect metadata, not a factual assertion.; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L10 in content/docs/administration/concepts/rbac/_index.md "- /docs/pulumi-cloud/access-management/" → ➖ not-a-claim (evidence: This is a Hugo aliases: front-matter entry listing a legacy URL path that should redirect to this page. It's redirect metadata, not a falsifiable assertion about content.; source: content/docs/administration/concepts/rbac/_index.md (front matter, aliases list))
  • L18 in content/docs/administration/concepts/rbac/_index.md "Organization-wide role settings, documented at /docs/administration/concepts/rbac/roles#organization-wide-role-settings, establish the baseline permissions…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/roles.md has an "Organization-wide role settings" section (matching the #organization-wide-role-settings anchor) stating: "Organization-wide role settings configure the built-in…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L18 in content/docs/administration/concepts/rbac/_index.md "In Pulumi Cloud, access is composed from reusable building blocks — scopes, permission sets, and roles — which are assigned to users, teams, and machine tokens." → ✅ verified (evidence: The _index.md page states "You compose access from reusable building blocks — scopes, permission sets, and roles — and assign it to users, teams, and machine tokens," matching the claim, and the linked anchor "Organization-wide role…; source: repo:content/docs/administration/concepts/rbac/_index.md and repo:content/docs/administration/concepts/rbac/roles.md)
  • L21 in content/docs/administration/concepts/rbac/_index.md "Pulumi's pricing page is located at /pricing/." → ✅ verified (evidence: content/pricing/_index.md is the source file for the site's pricing page, which renders at the /pricing/ route (title: Pricing, layout: pricing), matching the link "pricing page" used in the RBAC doc.; source: repo:content/pricing/_index.md)
  • L21 in content/docs/administration/concepts/rbac/_index.md "Pulumi Cloud's configurable RBAC features — custom roles, custom permission sets, teams, and tag-based (ABAC) rules — are only available in the Pulumi…" → ✅ verified (evidence: The cited roles.md page states custom roles are gated by edition ("Pulumi Enterprise allows up to 25 custom roles; Pulumi Business Critical allows unlimited custom roles"), while the _index.md source itself states "The built-in roles…; source: repo:content/docs/administration/concepts/rbac/roles.md and repo:content/docs/administration/concepts/rbac/_index.md)
  • L35-38 in content/docs/administration/concepts/rbac/_index.md "Each organization member in Pulumi Cloud has exactly one organization role: Admin, Member, Billing Manager, or a custom role." → 🤝 matches (evidence: The same page states "Every member of a Pulumi organization has a user role — a built-in role (Admin, Member, or Billing Manager) or a custom role," and the sibling roles.md page confirms the same three built-in roles (Admin, Member…; source: repo:content/docs/administration/concepts/rbac/_index.md and repo:content/docs/administration/concepts/rbac/roles.md)
  • L36-38 in content/docs/administration/concepts/rbac/_index.md "In Pulumi Cloud, a team can be granted access two ways — through roles and through entity access granted directly on specific stacks, environments, and cloud…" → ✅ verified (evidence: The linked teams page describes both mechanisms: "teams can be assigned roles (default or custom). This is separate from Team entity access grants (stack-level access)" and "Team entity access grants allow team admins to manage their…; source: content/docs/administration/concepts/rbac/teams.md)
  • L64 in content/docs/administration/concepts/rbac/_index.md "Users in multiple Pulumi Cloud teams accumulate permissions from every team they belong to." → ✅ verified (evidence: The same page states this explicitly and consistently in three places: "Members of a team receive the union of the team's roles..." (L36), "a member who belongs to two teams accumulates the permissions of their own user role plus every…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L64 in content/docs/administration/concepts/rbac/_index.md "Pulumi Cloud teams can be granted entity access directly on specific stacks, environments, and cloud accounts, outside of any role, and team members receive…" → ✅ verified (evidence: The linked section "Team Entity Access Grants" in teams.md states: "Team entity access grants allow team admins to manage their team's access to specific stacks, environments, and cloud accounts directly, without requiring org-level role…; source: content/docs/administration/concepts/rbac/teams.md#team-entity-access-grants)
  • L68 in content/docs/administration/concepts/rbac/_index.md "This automatic Stack Admin grant applies to machine tokens as well as to people: a stack created with an organization or team token carries the same…" → ✅ verified (evidence: The access-tokens page (linked source) states: "A stack created with a token carries an automatic creator grant... of the Stack Admin permission set, including deletion. That grant is held by the machine identity the token authenticates…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L81-85 in content/docs/administration/concepts/rbac/_index.md "In Pulumi Cloud RBAC, entities and organization-level access are the Pulumi Cloud objects that permission sets are granted on — stacks, environments, and…" → ✅ verified (evidence: Both content/docs/administration/concepts/rbac/_index.md ("Entities and organization-level access: The Pulumi Cloud objects that permission sets are granted on — stacks, environments, and cloud accounts — plus the organization-level…; source: repo:content/docs/administration/concepts/rbac/_index.md and repo:content/docs/administration/concepts/rbac/scopes.md)
  • L87 in content/docs/administration/concepts/rbac/_index.md "The Roles documentation at /docs/administration/concepts/rbac/roles contains a diagram of how a role is composed." → ✅ verified (evidence: content/docs/administration/concepts/rbac/roles.md contains a mermaid flowchart diagram showing entity access, organization-wide access, scopes, permission sets, and how they combine into a Role assigned to principals — directly matching…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L87 in content/docs/administration/concepts/rbac/_index.md "In Pulumi Cloud RBAC, scopes are bundled into permission sets; a permission set applied to a set of entities forms an entity access rule; and a role combines…" → ✅ verified (evidence: The linked /docs/administration/concepts/rbac/roles page states: "A role combines two kinds of access, both built from scopes bundled into permission sets: entity access — permission sets applied to specific entities (stacks…; source: content/docs/administration/concepts/rbac/roles.md)
  • L14 in content/docs/administration/concepts/rbac/entities.md "- /docs/administration/access-identity/rbac/entities/" → ➖ not-a-claim (evidence: This is a YAML aliases entry in frontmatter, redirecting the old URL path (/docs/administration/access-identity/rbac/entities/) to this restructured page. It's site-metadata describing the page's own redirect configuration, not a…; source: repo:content/docs/administration/concepts/rbac/entities.md)
  • L17 in content/docs/administration/concepts/rbac/entities.md "An entity is a Pulumi object that can have permission sets granted on it, and the permission-sets documentation is located at…" → ✅ verified (evidence: entities.md line 17 reads: "An entity is a Pulumi object that can have permission sets granted on it." The linked file content/docs/administration/concepts/rbac/permission-sets.md…; source: repo:content/docs/administration/concepts/rbac/entities.md and repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L19 in content/docs/administration/concepts/rbac/entities.md "In Pulumi Cloud's authorization model, the term 'entity' is used instead of 'resource' to refer to such objects, specifically to avoid confusion with cloud…" → ➖ not-a-claim (evidence: The text is a direct paraphrase of the same doc's own explanation: "we use the term 'entity' instead of 'resource'... This is because 'resource' already has a specific meaning within Pulumi (referring to cloud infrastructure resources).…; source: repo:content/docs/administration/concepts/rbac/entities.md)
  • L27 in content/docs/administration/concepts/rbac/entities.md "Pulumi Cloud has three entity types." → ✅ verified (evidence: The same page enumerates exactly three entity types immediately after the claim: "Pulumi Cloud has three entity types: * Stacks ... * Environments (Pulumi ESC) ... * Cloud accounts ..." — the list matches the stated count.; source: repo:content/docs/administration/concepts/rbac/entities.md)
  • L27-31 in content/docs/administration/concepts/rbac/entities.md "Cloud accounts are an entity type covering all operations that affect cloud accounts—accounts, policy evaluations, scan configurations, and results and…" → ✅ verified (evidence: The entities.md source line reads: "Cloud accounts: All operations that affect cloud accounts — accounts, policy evaluations, scan configurations, and results and reports. See [cloud account…; source: repo:content/docs/administration/concepts/rbac/entities.md and repo:content/docs/administration/reference/rbac-scopes/insights-accounts.md)
  • L35 in content/docs/administration/concepts/rbac/entities.md "Information on how organization access is configured, including custom roles, is documented at /docs/administration/concepts/rbac/roles#custom-roles." → ✅ verified (evidence: roles.md contains a ## Custom roles heading (line 105) which generates the anchor #custom-roles, and that section covers organization access configuration via custom roles, matching the cross-reference target…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L35 in content/docs/administration/concepts/rbac/entities.md "Organization-level operations—billing, member management, audit logs, integrations, and other organization settings—are not an entity type, are not tied to…" → ✅ verified (evidence: entities.md line 35 states org-level operations are "not an entity type" and are governed by "a role's organization access level," linking to roles.md#custom-roles. That target section (## Custom roles) confirms: "Organization access…; source: content/docs/administration/concepts/rbac/roles.md (## Custom roles section, line 105 and 163))
  • L37 in content/docs/administration/concepts/rbac/entities.md "Creating a stack (stack:create), a team (team:create), or a cloud account (insights_account:create) is governed at the organization level rather than…" → 🤝 matches (evidence: roles.md independently corroborates: "When disabled, only members whose role includes the stack:create scope can do so" and identical language for team:create ("Allow organization members to create teams... only members whose role…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L37 in content/docs/administration/concepts/rbac/entities.md "Organization-level access covers meta-permissions: actions that cannot be attached to an existing entity because the entity doesn't exist yet." → ➖ not-a-claim (evidence: The claim is a near-verbatim restatement of the reviewed doc's own text ("Organization-level access also covers meta-permissions: actions that can't be attached to an existing entity because the entity doesn't exist yet"), describing…; source: repo:content/docs/administration/concepts/rbac/entities.md and repo:content/docs/administration/concepts/rbac/roles.md)
  • L40 in content/docs/administration/concepts/rbac/entities.md "Organization-level scopes such as stack:create and team:create are granted through a role's organization access level, and these are separate from the…" → ✅ verified (evidence: roles.md's "Organization-wide role settings" section states: "Allow organization members to create stacks and transfer stacks to this organization — When enabled, members on the Member role can create new stacks... When disabled, only…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L45-48 in content/docs/administration/concepts/rbac/entities.md "Scopes are the most granular access rights in Pulumi Cloud, written as object:action, each scope belongs to one entity type, and scopes are the building…" → ✅ verified (evidence: The linked scopes.md page states: "Scopes are the most granular level of access control in Pulumi Cloud's RBAC system... Scopes follow a consistent naming pattern: object:action... Scopes are always associated with a specific entity…; source: repo:content/docs/administration/concepts/rbac/scopes.md)
  • L46-48 in content/docs/administration/concepts/rbac/entities.md "Roles are collections of permission sets applied to entities and combined with an organization access level." → ✅ verified (evidence: entities.md's "Related resources" section states: "Roles: Collections of permission sets applied to entities and combined with an organization access level." This is corroborated by roles.md: "A role combines two kinds of access...…; source: repo:content/docs/administration/concepts/rbac/entities.md and repo:content/docs/administration/concepts/rbac/roles.md)
  • L9 in content/docs/administration/concepts/rbac/permission-sets.md "The permission sets page's menu parent identifier is administration-concepts-rbac." → ✅ verified (evidence: The file's frontmatter menu block reads: menu:\n administration:\n name: Permission sets\n parent: administration-concepts-rbac\n weight: 2\n identifier: pulumi-cloud-access-management-rbac-permission-sets — confirming the…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L15-20 in content/docs/administration/concepts/rbac/permission-sets.md "The permission sets page has aliases at /docs/administration/access-identity/rbac/permission-sets/, /docs/administration/access-identity/stack-permissions/…" → ✅ verified (evidence: The file's frontmatter aliases list (lines 15-20) exactly contains: /docs/administration/access-identity/rbac/permission-sets/, /docs/administration/access-identity/stack-permissions/, /docs/console/collaboration/stack-permissions/…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L20 in content/docs/administration/concepts/rbac/permission-sets.md "- /docs/reference/service/roles-and-access-controls/" → ➖ not-a-claim (evidence: Line 20 is part of the page's frontmatter aliases list (old URL paths redirected to this page), not a falsifiable assertion about content or a source.; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L24 in content/docs/administration/concepts/rbac/permission-sets.md "Permission sets in Pulumi Cloud provide a convenient way to grant related access rights to an entity (resource) or set of entities (resources)." → 🤝 matches (evidence: permission-sets.md states permission sets "are predefined bundles of scopes... provide a convenient way to grant related access rights to an entity (resource) or set of entities (resources)"; the linked scopes.md sibling page…; source: repo:content/docs/administration/concepts/rbac/scopes.md)
  • L26 in content/docs/administration/concepts/rbac/permission-sets.md "There is a documentation section on entity types located at /docs/administration/concepts/rbac/entities#entity-types." → ✅ verified (evidence: entities.md contains a heading "## Entity types" (line 21) which produces the anchor #entity-types, and the surrounding content ("Pulumi Cloud has three entity types...") matches the section being linked to.; source: repo:content/docs/administration/concepts/rbac/entities.md)
  • L59 in content/docs/administration/concepts/rbac/permission-sets.md "There is a documentation section on organization-level access located at /docs/administration/concepts/rbac/entities#organization-level-access." → ✅ verified (evidence: entities.md contains the H2 heading "## Organization-level access" (line 33), which Hugo renders as anchor #organization-level-access, matching the linked URL /docs/administration/concepts/rbac/entities#organization-level-access.; source: repo:content/docs/administration/concepts/rbac/entities.md)
  • L87-90 in content/docs/administration/concepts/rbac/permission-sets.md "There is a documentation page on entities and organization-level access located at /docs/administration/concepts/rbac/entities." → ✅ verified (evidence: The file content/docs/administration/concepts/rbac/entities.md exists with title "Entities and Organization Level Access" and covers entity types plus an "Organization-level access" section, matching the linked text "Entities and…; source: repo:content/docs/administration/concepts/rbac/entities.md)
  • L9 in content/docs/administration/concepts/rbac/roles.md "The Roles page is positioned as a child of the administration-concepts-rbac section in the documentation navigation menu." → ✅ verified (evidence: The page's own frontmatter menu block sets parent: administration-concepts-rbac under the administration menu, matching the claim that Roles is positioned as a child of the administration-concepts-rbac section.; source: repo:content/docs/administration/concepts/rbac/roles.md (frontmatter, lines ~5-10))
  • L18 in content/docs/administration/concepts/rbac/roles.md "A role in Pulumi Cloud is the primary way to define what resources a principal (user, team, or machine token) can access and what they can do with them." → 🤝 matches (evidence: roles.md states "A role...is the primary way to define what resources a principal (user, team, or machine token) can access and what they can do with them. Roles allow you to apply permission sets to a set of entities...and assign this…; source: repo:content/docs/administration/concepts/rbac/roles.md and repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L20 in content/docs/administration/concepts/rbac/roles.md "A role combines two kinds of access: entity access (permission sets applied to specific entities such as stacks, environments, and accounts) and an…" → ✅ verified (evidence: roles.md states: "A role combines two kinds of access, both built from scopes bundled into permission sets: entity access — permission sets applied to specific entities (stacks, environments, and accounts)... and an organization access…; source: repo:content/docs/administration/concepts/rbac/roles.md and repo:content/docs/administration/concepts/rbac/scopes.md)
  • L45-47 in content/docs/administration/concepts/rbac/roles.md "The Pulumi Cloud Admin role has full access to all organization resources and settings, and can manage members, roles, and organization-wide configurations." → ➖ not-a-claim (evidence: The claim text is a verbatim restatement of the table row in the same file under review: "Admin | Full access to all organization resources and settings. Can manage members, roles, and organization-wide configurations." This is the…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L50 in content/docs/administration/concepts/rbac/roles.md "To change the default role, you select a role and choose Actions > Set as organization default role in Pulumi Cloud." → ❌ contradicted (framing: source: "The default role is set from Settings > Roles (not from the Access Management page)" vs claim: "select a role and choose Actions > Set as…; evidence: (escalated from pass1) The live Pulumi Cloud Roles doc states: "The default role is set from Settings > Roles (not from the Access Management page)." This describes a Settings-page based mechanism, not an "Actions > Set as organization…; source: https://www.pulumi.com/docs/administration/access-identity/rbac/roles/)
  • L55 in content/docs/administration/concepts/rbac/roles.md "Organization-wide role settings apply only to members on the Member role who have not been given an explicit custom role; a member with an assigned custom…" → ✅ verified (evidence: The same doc states elsewhere: "The baseline permissions for members who have not been given an explicit custom role are configured in Organization-wide role settings" (L112) and "Members who have the Member organization role and have…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L55 in content/docs/administration/concepts/rbac/roles.md "Organization-wide role settings in Pulumi Cloud configure the built-in Member role's default access levels for stacks, environments, and accounts, plus a few…" → ➖ not-a-claim (evidence: The claim is a direct paraphrase of the doc's own descriptive text (L55): "Organization-wide role settings configure the built-in Member role: its default access levels for stacks, environments, and accounts, plus a few org-wide…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L55 in content/docs/administration/concepts/rbac/roles.md "The Member role also carries a fixed baseline of permissions that the Organization-wide role settings panel does not expose." → ✅ verified (evidence: The sibling permission-sets.md page describes the Standard permission set (which underlies Member-level org access) as including scopes like ai_conversations:create, environment:create, project:encrypt, project:decrypt…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md (Standard permission set row) and repo:content/docs/administration/concepts/rbac/roles.md L55)
  • L57 in content/docs/administration/concepts/rbac/roles.md "Only organization admins can change organization-wide role settings in Pulumi Cloud." → 🤝 matches (evidence: The claim ("Only organization admins can change these settings") is consistent with the established RBAC pattern documented across sibling pages — e.g., permission-sets.md states "To create a custom permission set, you must be an…; source: content/docs/administration/concepts/rbac/permission-sets.md (sibling page))
  • L57 in content/docs/administration/concepts/rbac/roles.md "To open organization-wide role settings, navigate to Settings > Access management, select the Roles tab, and choose View organization-wide role settings." → 🤷 unverifiable (evidence: The exact navigation text ("navigate to Settings > Access management, select the Roles tab, and choose View organization-wide role settings") appears verbatim in pulumi/docs' existing roles.md and is referenced consistently across…; source: gh search code --owner pulumi "View organization-wide role settings" -R pulumi/docs)

  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor
continued from previous comment
  • L60 in content/docs/administration/concepts/rbac/roles.md "Organization-wide role settings in Pulumi Cloud are a leftover from Pulumi Cloud's pre-RBAC permission system, retained for backward compatibility." → 🤷 unverifiable (framing: Source presents org-wide role settings as a first-class, currently-relevant RBAC feature ("establish the baseline permissions that every member receives by…; evidence: (escalated from pass1) Current Pulumi Cloud docs describe organization-wide role settings as a core, actively-used part of RBAC — e.g. "Organization-wide role settings establish the baseline permissions that every member receives by…; source: https://www.pulumi.com/docs/administration/access-identity/rbac/; intuition: The claim asserts an internal historical/design rationale (a 'pre-RBAC system' predecessor) that no public doc… (WebSearch dispatched but verification did not converge within the turn budget))

  • L67 in content/docs/administration/concepts/rbac/roles.md "Creator grants are not configurable in the Stack permissions dropdown; to remove one, you delete it from the stack's Access tab." → ✅ verified (evidence: The same docs set states: "Like every other grant, a creator grant is additive, so no role or organization-wide setting suppresses it... To change a creator grant after the fact: Remove the grant: open the stack, select the Access tab…; source: repo:content/docs/administration/concepts/rbac/_index.md (Creator grants section) and repo:content/docs/administration/concepts/rbac/roles.md L67)

  • L67-69 in content/docs/administration/concepts/rbac/roles.md "When the Stack permissions setting is None, members have no default access to stacks and can only access stacks granted to them through a role, a team, or a…" → ✅ verified (evidence: roles.md itself states: "None — Members have no default access to stacks. They can only access stacks granted to them through a role, a team, or a creator grant — the automatic Stack Admin permission set that whoever creates a stack…; source: content/docs/administration/concepts/rbac/roles.md L67; content/docs/administration/concepts/rbac/_index.md L66-68)

  • L69 in content/docs/administration/concepts/rbac/roles.md "Removing a stack itself via pulumi stack rm is not included in the Write stack permission level." → ✅ verified (evidence: The cited RBAC scopes page for stacks shows stack:delete ("Delete a stack and its associated resources...") is "Granted by default permission set: Stack Admin", not Stack Write, confirming that removing a stack via `pulumi stack…; source: content/docs/administration/reference/rbac-scopes/stacks.md)

  • L73-75 in content/docs/administration/concepts/rbac/roles.md "When the 'Allow organization members to create stacks and transfer stacks to this organization' toggle is enabled, members on the Member role can create new…" → ➖ not-a-claim (evidence: The claim text is a verbatim restatement of the doc's own line: "When enabled, members on the Member role can create new stacks and transfer existing stacks into the organization." Since this is the same file under review describing…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L81-84 in content/docs/administration/concepts/rbac/roles.md "When the Environment permissions setting is Open, members can open environments, resolving and decrypting their values for use." → ✅ verified (evidence: The existing sibling docs page pulumi/docs:content/docs/administration/access-identity/rbac/roles.md contains the identical line: "- Open — Members can open environments, resolving and decrypting their values for use." This matches…; source: gh search code --owner pulumi "environment:open resolving and decrypting" (pulumi/docs:content/docs/administration/access-identity/rbac/roles.md); content/docs/administration/reference/rbac-scopes/environments.md)

  • L90-92 in content/docs/administration/concepts/rbac/roles.md "When the Account permissions setting is Write, members can update existing accounts and run and manage their scans (start, cancel, pause, and resume)." → 🤝 matches (evidence: The sibling permission-sets.md doc defines Account Write as: "Account Read, + insights_account:update, insights_account:scan, insights_account_scan:update, insights_account_scan:cancel, insights_account_scan:pause…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md (Cloud account permission sets table))

  • L92-93 in content/docs/administration/concepts/rbac/roles.md "The Admin account permission level provides full control, including everything Write allows, plus deleting accounts and managing who else can access them." → ✅ verified (evidence: Line 93 of the same file states: "Admin — Full control: everything Write allows, plus deleting accounts and managing who else can access them." This is a verbatim match to the claim text.; source: repo:content/docs/administration/concepts/rbac/roles.md L93)

  • L92 in content/docs/administration/concepts/rbac/roles.md "Creating cloud accounts is governed by the 'Allow organization members to create accounts' toggle." → ✅ verified (evidence: Doc text at line 92 states: "Write does not include creating or deleting accounts: creating is governed by the Allow organization members to create accounts toggle below," and line 97 confirms the toggle: "Allow organization members to…; source: repo:content/docs/administration/concepts/rbac/roles.md (also pulumi/docs:content/docs/administration/access-identity/rbac/roles.md))

  • L97 in content/docs/administration/concepts/rbac/roles.md "When the 'Allow organization members to create accounts' toggle is disabled, only members whose role includes the insights_account:create scope can create…" → ✅ verified (evidence: The scope reference page confirms insights_account:create scope: "Create a new cloud account. This allows setting up monitoring and analysis capabilities for infrastructure." And the sibling roles.md page…; source: pulumi/docs:content/docs/administration/access-identity/rbac/scopes/org-settings.md and content/docs/administration/access-identity/rbac/roles.md)

  • L103 in content/docs/administration/concepts/rbac/roles.md "When the 'Allow organization members to create teams' toggle is disabled, only members whose role includes the team:create scope can create new teams." → 🤝 matches (evidence: roles.md itself states: "Allow organization members to create teams — When enabled, members on the Member role can create new teams... When disabled, only members whose role includes the team:create scope can do so." This is consistent…; source: repo:content/docs/administration/concepts/rbac/roles.md (L103), repo:content/docs/administration/concepts/rbac/teams.md (L31-35))

  • L110 in content/docs/administration/concepts/rbac/roles.md "Pulumi Business Critical allows unlimited custom roles." → ✅ verified (evidence: The identical sentence "Pulumi Enterprise allows up to 25 custom roles; Pulumi Business Critical allows unlimited custom roles." already exists verbatim on the live published docs page…; source: gh search code -R pulumi/docs "Custom roles" "25" (data/pulumi_pricing.yaml: "enterprise: Up to 25"; content/docs/administration/access-identity/rbac/roles.md: "Pulumi Enterprise allows up to 25 custom roles; Pulumi Business Critical allows unlimited custom roles."))

  • L112 in content/docs/administration/concepts/rbac/roles.md "The baseline permissions for members who have not been given an explicit custom role are configured in Organization-wide role settings." → 🤝 matches (evidence: Line 55 states "These settings apply only to members on the Member role who have not been given an explicit custom role" and line 181 reiterates "Members who have the Member organization role and have not been given an explicit custom…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L115 in content/docs/administration/concepts/rbac/roles.md "Custom roles in Pulumi Cloud combine entity access rules (direct, global, or tag-based) with an organization access level." → ➖ not-a-claim (evidence: This sentence is the page's own restatement of its immediately following explanatory text: "A custom role can include any combination of the following entity access rule types, plus an organization access level" and the "Rule types"…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L119 in content/docs/administration/concepts/rbac/roles.md "To create a custom role in Pulumi Cloud, you must be an organization admin." → 🤝 matches (evidence: roles.md L119 states "To create a custom role, you must be an organization admin." This matches the identical, sibling-consistent pattern in permission-sets.md L71: "To create a custom permission set, you must be an organization admin."…; source: repo:content/docs/administration/concepts/rbac/roles.md and repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L121 in content/docs/administration/concepts/rbac/roles.md "To see your organization's roles, navigate to Settings > Access management and select the Roles tab." → ✅ verified (evidence: The document itself states at line 121: "Navigate to Settings > Access management and select the Roles tab to see your organization's roles," and this is consistent with the same navigation path described earlier at line 57…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L123 in content/docs/administration/concepts/rbac/roles.md "To create a new role in Pulumi Cloud, you select Create custom role, and provide a unique name and, optionally, a description." → ➖ not-a-claim (evidence: Line 123 of the same file reads: "To create a new role, select Create custom role. Provide a unique name and, optionally, a description to contextualize the role's purpose." The claim is simply a paraphrase of this documentation line…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L125 in content/docs/administration/concepts/rbac/roles.md "A custom role in Pulumi Cloud can include any combination of entity access rule types, plus an organization access level." → ➖ not-a-claim (evidence: This is a direct paraphrase of the document's own line 125 ("A custom role can include any combination of the following entity access rule types, plus an organization access level"), consistent with line 115 ("Custom roles combine entity…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L131 in content/docs/administration/concepts/rbac/roles.md "To configure a direct entity access rule, you choose the entity type (stack, environment, or cloud account), select Select specific [type], then select…" → ➖ not-a-claim (evidence: The claim text is a verbatim restatement of the doc's own line 131: "Choose the entity type (stack, environment, or cloud account), select Select specific [type], then select Choose [type] to open a searchable list." This is the…; source: repo:content/docs/administration/concepts/rbac/roles.md#L131)

  • L131 in content/docs/administration/concepts/rbac/roles.md "Direct entity access rules grant a permission set to individually selected entities." → ➖ not-a-claim (evidence: The claim is a near-verbatim paraphrase of the doc's own line 131 ("Direct rules grant a permission set to individually selected entities"), describing Pulumi Cloud's own RBAC UI feature design as documented consistently alongside…; source: repo:content/docs/administration/concepts/rbac/roles.md L131)

  • L135 in content/docs/administration/concepts/rbac/roles.md "To finish selecting entities in a direct access rule dialog, you check the entities to include and select Confirm selection." → ➖ not-a-claim (evidence: Line 135 of the same doc reads "Check the entities to include in the rule, then select Confirm selection." The claim is a direct paraphrase of this documentation line describing the Pulumi Cloud UI's own dialog flow, not an…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L137 in content/docs/administration/concepts/rbac/roles.md "After confirming a direct entity access rule, you select Save rule, and the Entity Access section displays a table of all configured rules, with an option to…" → ➖ not-a-claim (evidence: The claim is a direct paraphrase of the doc's own line 137: "After confirming, select Save rule. The Entity Access section displays a table of all configured rules, and you can add more with Add rule." This is the file…; source: repo:content/docs/administration/concepts/rbac/roles.md#L137)

  • L141 in content/docs/administration/concepts/rbac/roles.md "To configure a global entity access rule, you choose the entity type and select Apply to all [type] to grant the chosen permission set across all current and…" → ➖ not-a-claim (evidence: The claim is a near-verbatim restatement of the doc's own sentence describing Pulumi Cloud's "Global entity access" UI feature (line 141: "Global rules apply a permission set to all entities of a given type within the organization.…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L145 in content/docs/administration/concepts/rbac/roles.md "Tag-based rules are also called ABAC (attribute-based access control) and grant a permission set when a resource's tags match defined conditions." → ➖ not-a-claim (evidence: Line 145 of the same file is the literal source of this text ("Tag-based rules (also called ABAC — attribute-based access control) grant a permission set when a resource's tags match defined conditions"), and the file consistently uses…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L147-149 in content/docs/administration/concepts/rbac/roles.md "A tag-based rule has an entity type (stack, environment, or cloud account), one or more tag conditions, and a permission set to grant when conditions match." → ➖ not-a-claim (evidence: Lines 147-149 of the same doc file explicitly list: "Entity type — Stack, environment, or cloud account.", "Tag conditions — One or more conditions on resource tags...", "Permission set — The permission set to grant when the conditions…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L153 in content/docs/administration/concepts/rbac/roles.md "When evaluating access, Pulumi Cloud checks the user's roles and the roles of the teams they belong to, evaluating each tag rule's conditions against the…" → ➖ not-a-claim (evidence: The claim is a restatement of the doc's own "How it works" text at line 153: "When evaluating access, Pulumi Cloud checks the user's roles (and the roles of the teams they belong to). For each tag rule in those roles, it evaluates the…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L156 in content/docs/administration/concepts/rbac/roles.md "A machine token that creates a stack in Pulumi Cloud holds a creator grant of Stack Admin on that stack, and can keep operating on it even though the stack's…" → ✅ verified (evidence: The linked "Creator grants" section states: "Whoever creates a stack is automatically granted the Stack Admin permission set on that stack... This applies to machine tokens as well as to people" and "a creator grant is additive, so no…; source: repo:content/docs/administration/concepts/rbac/_index.md (Creator grants section))

  • L161 in content/docs/administration/concepts/rbac/roles.md "In the Pulumi Cloud UI and API, tag-based rules may be labeled 'tag rules' or 'tag-based access control rules'." → 🤷 unverifiable (evidence: The exact same sentence already exists verbatim in the currently published pulumi/docs page content/docs/administration/access-identity/rbac/roles.md ("In the Pulumi Cloud UI and API, these rules may be labeled "tag rules" or…; source: gh search code --owner pulumi "tag-based access control" (matched pulumi/docs:content/docs/administration/access-identity/rbac/roles.md))

  • L161 in content/docs/administration/concepts/rbac/roles.md "ABAC (attribute-based access control) is the general industry term for tag-based rules." → ✅ verified (framing: ABAC is broader (any attribute, not just tags), but tag-based rules are a well-documented special case/common implementation of ABAC, so the claim is…; evidence: NIST and Wikipedia confirm ABAC is the standard industry term for access control based on attributes; industry sources (AWS, Frontegg, SecurEnds) describe tags as a common attribute type used in ABAC's tag-based rules, e.g. "Use…; source: https://frontegg.com/guides/abac; https://en.wikipedia.org/wiki/Attribute-based_access_control; https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf)

  • L163 in content/docs/administration/concepts/rbac/roles.md "Organization access sets the permission level for organization-level operations such as creating stacks, managing billing, and audit logs, and is separate…" → ✅ verified (evidence: Line 163 of the same file states: "Organization access sets the permission level for organization-level operations (e.g. creating stacks, managing billing, audit logs). This applies to the organization as a whole and is separate from the…; source: repo:content/docs/administration/concepts/rbac/roles.md#L163)

  • L171 in content/docs/administration/concepts/rbac/roles.md "Effective permissions in Pulumi Cloud are the union of the user's organization role and all roles assigned to the teams they belong to." → ✅ verified (evidence: The doc states: "Roles can be assigned to organization access tokens, users, and teams. Effective permissions are the union of the user's organization role and all roles assigned to the teams they belong to (composability)." This is…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L175 in content/docs/administration/concepts/rbac/roles.md "Organization access tokens in Pulumi Cloud can be assigned exactly one role (default or custom) that defines the token's permissions across the organization." → ✅ verified (evidence: A sibling RBAC docs page (content/docs/administration/access-identity/rbac/_index.md) states: "Organization access tokens: Machine tokens that are assigned exactly one role defining the token's permissions across the organization,"…; source: pulumi/docs:content/docs/administration/access-identity/rbac/_index.md and content/docs/administration/access-identity/access-tokens.md)

  • L177 in content/docs/administration/concepts/rbac/roles.md "A token's access in Pulumi Cloud is limited to the permissions of the role assigned to it within the organization." → ✅ verified (evidence: access-tokens.md states "An organization token can do anything its assigned RBAC role permits. By assigning different roles, you can scope a token to exactly the operations your automation needs" — confirming a token's access is limited…; source: repo:content/docs/administration/concepts/access-tokens.md)

  • L181 in content/docs/administration/concepts/rbac/roles.md "Members who have the Member organization role and have not been given an explicit custom role receive the baseline permissions defined in Organization-wide…" → 🤝 matches (evidence: The claim at L181 is consistent with the same document's earlier statements: L46 "The baseline permissions every member receives are configured in Organization-wide role settings," L55 "These settings apply only to members on the Member…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L185 in content/docs/administration/concepts/rbac/roles.md "Team members in Pulumi Cloud receive the union of their own user role and all roles assigned to the teams they belong to." → ✅ verified (evidence: teams.md states: "teams can also be assigned roles ... so that members receive the union of the team's roles and their own user role," and the #role-assignments section reiterates "Members of the team receive the permissions from all of…; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L194 in content/docs/administration/concepts/rbac/roles.md "When automation creates stacks with a machine token, having the run transfer stack ownership to a break-glass user or team, or removing the automatic creator…" → ✅ verified (evidence: The linked source (rbac/_index.md #creator-grants) states: "a long-lived machine token accumulates a creator grant on every stack it has ever created, so its standing access grows well beyond what its assigned role suggests. For…; source: repo:content/docs/administration/concepts/rbac/_index.md)

  • L200-203 in content/docs/administration/concepts/rbac/roles.md "Entities in Pulumi Cloud are the objects that permission sets are granted on: stacks, environments, and cloud accounts." → ✅ verified (evidence: entities.md states "An entity is a Pulumi object that can have permission sets granted on it" and "Pulumi Cloud has three entity types: Stacks, Environments (Pulumi ESC), Cloud accounts" — matching the claim's assertion that entities are…; source: repo:content/docs/administration/concepts/rbac/entities.md)

  • L200-203 in content/docs/administration/concepts/rbac/roles.md "Each team member in Pulumi Cloud inherits the union of the team's roles on top of their own role." → ✅ verified (evidence: teams.md states: "teams can also be assigned roles ... so that members receive the union of the team's roles and their own user role," which matches roles.md's own text (L185): "Team members receive the union of their own user role and…; source: repo:content/docs/administration/concepts/rbac/teams.md (L27) and repo:content/docs/administration/concepts/rbac/roles.md (L185))

  • L201-202 in content/docs/administration/concepts/rbac/roles.md "Permission sets can be granted on entities or used to set a role's organization access level." → ✅ verified (evidence: The permission-sets.md page states organization settings permission sets "bundle organization-level (global) scopes. Rather than granting access to a specific entity, they set a role's organization access level" while others are "granted…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L12-15 in content/docs/administration/concepts/rbac/scopes.md "- /docs/pulumi-cloud/access-management/rbac/scopes/" → ➖ not-a-claim (evidence: The cited text is a frontmatter aliases entry (/docs/pulumi-cloud/access-management/rbac/scopes/), one of several legacy redirect URLs listed alongside the source_hint alias (/docs/intro/pulumi-service/scopes/) for this page. This…; source: repo:content/docs/administration/concepts/rbac/scopes.md)

  • L19 in content/docs/administration/concepts/rbac/scopes.md "Each scope in Pulumi Cloud's RBAC system represents a specific action that can be performed on a resource, such as reading stack configurations or updating…" → ✅ verified (evidence: scopes.md itself states: "Scopes are the most granular level of access control in Pulumi Cloud's RBAC system. Each scope represents a specific action that can be performed on a resource, such as reading stack configurations or updating…; source: content/docs/administration/concepts/rbac/scopes.md; content/docs/administration/concepts/rbac/permission-sets.md)

  • L23-27 in content/docs/administration/concepts/rbac/scopes.md "Scopes in Pulumi Cloud follow a consistent naming pattern of object:action." → ✅ verified (evidence: The doc page itself defines and consistently uses the object:action pattern across all listed scope examples (stack:read, environment:write, team:create, stack_deployment:create), and sibling scope-listing pages…; source: repo:content/docs/administration/concepts/rbac/scopes.md)

  • L25-27 in content/docs/administration/concepts/rbac/scopes.md "The environment:write scope in Pulumi Cloud allows modifying environment settings." → ✅ verified (evidence: The environment:write scope is a real RBAC permission in Pulumi's pulumiservice provider (RbacPermissionEnvironmentWrite = "environment:write"), and the sibling docs page content/docs/administration/access-identity/rbac/scopes/environm…; source: gh search code --owner pulumi "environment:write" (pulumi/pulumi-pulumiservice:provider/pkg/apitype/rbac_permission_.go, pulumi/docs:content/docs/administration/access-identity/rbac/scopes/environments.md))

  • L26 in content/docs/administration/concepts/rbac/scopes.md "- environment:write - Allows modifying environment settings" → ➖ not-a-claim (evidence: (escalated from pass3) This line is an illustrative example within the doc's own explanation of the object:action scope naming convention ("Scopes follow a consistent naming pattern: object:action. For example: ...…; source: repo:content/docs/administration/concepts/rbac/scopes.md)

  • L27 in content/docs/administration/concepts/rbac/scopes.md "- team:create - Allows creating new teams" → 🤝 matches (evidence: The sibling page entities.md explicitly references the same scope: "Creating a stack (stack:create), a team (team:create), or a cloud account (insights_account:create) is governed at the organization level" — confirming…; source: repo:content/docs/administration/concepts/rbac/entities.md)

  • L29 in content/docs/administration/concepts/rbac/scopes.md "This entity-type matching design in Pulumi Cloud ensures permission sets remain logically grouped and can't mix actions across different types of resources." → ✅ verified (evidence: entities.md#entity-types states: "When creating a permission set, it must be of a specific entity type, and can only include scopes of that same type," matching scopes.md's claim that entity-type matching ensures permission sets stay…; source: content/docs/administration/concepts/rbac/entities.md)

  • L31-36 in content/docs/administration/concepts/rbac/scopes.md "A 'Stack Manager' permission set example in Pulumi Cloud might include the scopes stack:read, stack:write, stack:delete, and stack_deployment:create." → 🤝 matches (evidence: scopes.md's "Stack Manager" example lists stack:read, stack:write, stack:delete, stack_deployment:create — all four are real, documented scopes that appear in permission-sets.md's Stack permission sets table (Stack Read includes…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L33 in content/docs/administration/concepts/rbac/scopes.md "- stack:read" → 🤷 unverifiable (evidence: The official Pulumi docs page at /docs/administration/access-identity/rbac/scopes/stacks/ exists and is described as defining "all the available scopes in Pulumi Cloud assignable to specific stacks or sets of stacks," and other pages…; source: https://www.pulumi.com/docs/administration/access-identity/rbac/scopes/stacks/ (WebSearch dispatched but verification did not converge within the turn budget))

  • L34 in content/docs/administration/concepts/rbac/scopes.md "- stack:write" → ✅ verified (framing: Source confirms the object:action scope format and dedicated stack-scopes page; specific stack:write token not directly quoted from search results but is…; evidence: Pulumi's own RBAC docs describe scopes as written in "object:action" format and have a dedicated page "RBAC Scopes - Stacks" that "defines all the available scopes in Pulumi Cloud assignable to specific stacks or sets of stacks,"…; source: https://www.pulumi.com/docs/administration/access-identity/rbac/scopes/stacks/)

  • L35 in content/docs/administration/concepts/rbac/scopes.md "- stack:delete" → ✅ verified (evidence: Pulumi's own IAM announcement blog references this exact scope: "Define custom, reusable Permissions with fine-grained scopes (e.g., stack:delete only)." This confirms stack:delete is a real Pulumi Cloud RBAC scope, consistent with the…; source: https://www.pulumi.com/blog/pulumi-cloud-iam-launch/)

  • L36 in content/docs/administration/concepts/rbac/scopes.md "- stack_deployment:create" → 🤝 matches (evidence: (escalated from pass3) The sibling page permission-sets.md lists stack_deployment:create as a scope included in the "Stack Write" default permission set, confirming this scope name is real and consistent with its use as an example in…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md (line 37))

  • L40 in content/docs/administration/concepts/rbac/scopes.md "Pulumi Cloud has a documentation section on default roles at /docs/administration/concepts/rbac/roles#default-roles." → ❌ contradicted (framing: claim asserts a "default roles" documentation section exists at that anchor; the actual heading is "Pulumi-defined roles" with a different anchor slug; evidence: roles.md's relevant section is headed "## Pulumi-defined roles" (which generates anchor #pulumi-defined-roles), not "Default roles" — there is no heading in roles.md that produces a #default-roles anchor, so the link target…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L42-44 in content/docs/administration/concepts/rbac/scopes.md "Regular members in Pulumi Cloud have access to basic read and write scopes for common operations." → 🤝 matches (evidence: The scopes.md claim ("Regular members have access to basic read and write scopes for common operations") is consistent with the sibling roles.md page, which describes the default Member role as having "Basic access to view organization…; source: content/docs/administration/concepts/rbac/roles.md)

  • L48-53 in content/docs/administration/concepts/rbac/scopes.md "Pulumi Cloud provides a list of available scopes organized by entity type, covering Stacks, Environments, Cloud accounts, and Organization settings." → ✅ verified (evidence: The page's "Available scopes" section states "You can view the list of available scopes, organized by entity type:" followed by links to Stacks, Environments, Cloud accounts, and Organization settings — matching the claim exactly.; source: repo:content/docs/administration/concepts/rbac/scopes.md)

  • L57-60 in content/docs/administration/concepts/rbac/scopes.md "Entities in Pulumi Cloud's RBAC system are the objects that permission sets are granted on: stacks, environments, and cloud accounts, plus organization-level…" → 🤝 matches (evidence: permission-sets.md's Related resources section states: "Entities and organization-level access: The objects that permission sets are granted on (stacks, environments, and cloud accounts), plus the organization-level access that governs…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L1 in content/docs/administration/concepts/rbac/teams.md "Scopes are written in the format 'object:action'." → ✅ verified (evidence: The sibling page scopes.md states: "Scopes follow a consistent naming pattern: object:action" with examples like stack:read, environment:write, team:create, and teams.md itself links to scopes as "written as object:action" …; source: repo:content/docs/administration/concepts/rbac/scopes.md, repo:content/docs/administration/concepts/rbac/teams.md)

  • L1 in content/docs/administration/concepts/rbac/teams.md "Members of a team receive the permissions from all of the team's assigned roles in addition to their own organization role." → ✅ verified (evidence: The docs page states "Members of the team receive the permissions from all of those roles in addition to their own organization role," and this is corroborated by the Pulumi blog: "Custom roles can now be assigned directly to teams...…; source: pulumi/docs blog/expanding-pulumi-iam-custom-permissions/index.md; content/docs/administration/concepts/rbac/teams.md)

  • L1 in content/docs/administration/concepts/rbac/teams.md "The 'Teams' documentation page's menu parent is 'administration-concepts-rbac'." → ✅ verified (evidence: The front matter of teams.md shows: menu: administration: name: Teams parent: administration-concepts-rbac, confirming the menu parent value stated in the claim.; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L1 in content/docs/administration/concepts/rbac/teams.md "The page at /docs/administration/concepts/rbac/teams.md has aliases including /docs/administration/organizations-teams/teams/…" → ✅ verified (evidence: The file's front matter aliases list includes exactly the URLs cited: /docs/administration/organizations-teams/teams/, /docs/reference/service/teams/, /docs/console/collaboration/teams/, /docs/intro/console/collaboration/…; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L1 in content/docs/administration/concepts/rbac/teams.md "Enabling the 'Allow organization members to create teams' toggle in Organization-wide role settings (located at /docs/administration/concepts/rbac/roles#organi…" → ✅ verified (evidence: roles.md states: "Allow organization members to create teams — When enabled, members on the Member role can create new teams. When disabled, only members whose role includes the team:create scope can do so." teams.md itself…; source: repo:content/docs/administration/concepts/rbac/roles.md (line 103), repo:content/docs/administration/concepts/rbac/teams.md (line 34))

  • L1 in content/docs/administration/concepts/rbac/teams.md "A role-backed team can be created by creating a team, assigning it a custom role (e.g., with access only to certain stacks or tag-based rules), and then…" → ✅ verified (evidence: The pulumi-pulumiservice provider ships exactly this workflow: Team, OrganizationRole (custom roles), and TeamRoleAssignment resources — CHANGELOG: "Added TeamRoleAssignment resource for assigning a custom role to a team.…; source: gh search code --owner pulumi "custom role" team roleAssignment (pulumi/pulumi-pulumiservice CHANGELOG.md, examples/ts-rbac/README.md))

  • L1 in content/docs/administration/concepts/rbac/teams.md "Each scope belongs to one entity type and is the building block of permission sets." → ✅ verified (evidence: teams.md's Related resources section contains this exact sentence describing scopes: "Each scope belongs to one entity type and is the building block of permission sets." This matches scopes.md's own description: "Scopes are always…; source: repo:content/docs/administration/concepts/rbac/teams.md and repo:content/docs/administration/concepts/rbac/scopes.md)

  • L9 in content/docs/administration/concepts/rbac/teams.md "The Teams documentation page's navigation parent identifier is administration-concepts-rbac." → ✅ verified (evidence: The front matter of content/docs/administration/concepts/rbac/teams.md line 9 reads parent: administration-concepts-rbac, matching the claim exactly, and sibling page roles.md uses the same parent value confirming consistency.; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L16-23 in content/docs/administration/concepts/rbac/teams.md "The Teams documentation page is reachable via alias paths including /docs/administration/organizations-teams/teams/, /docs/reference/service/teams/…" → ✅ verified (evidence: The frontmatter of content/docs/administration/concepts/rbac/teams.md (lines 16-23) lists exactly the eight aliases cited: /docs/administration/organizations-teams/teams/, /docs/reference/service/teams/…; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L31 in content/docs/administration/concepts/rbac/teams.md "By default, all organization admins can create new teams." → 🤝 matches (evidence: roles.md (sibling page) confirms: "Allow organization members to create teams — When enabled, members on the Member role can create new teams. When disabled, only members whose role includes the team:create scope can do so." This matches…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L34 in content/docs/administration/concepts/rbac/teams.md "To allow all organization members to create teams, enable the Allow organization members to create teams toggle in [Organization-wide role…" → ✅ verified (evidence: roles.md contains the "#### Team permissions" subsection under "### Organization-wide role settings" stating: "Allow organization members to create teams — When enabled, members on the Member role can create new teams. When…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L37-53 in content/docs/administration/concepts/rbac/teams.md "To allow all organization members to create teams, enable the 'Allow organization members to create teams' toggle in Organization-wide role settings at…" → ✅ verified (evidence: roles.md confirms the exact toggle and section: "Allow organization members to create teams — When enabled, members on the Member role can create new teams" under "#### Team permissions" within "### Organization-wide role settings"…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L54-56 in content/docs/administration/concepts/rbac/teams.md "Each team can have multiple role assignments, and members of the team receive the permissions from all of those roles in addition to their own organization…" → ✅ verified (evidence: roles.md contains a "### Users" section (anchor #users) stating "Each organization member has exactly one organization role..." and separately under "### Teams" states "Team members receive the union of their own user role and all roles…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L57 in content/docs/administration/concepts/rbac/teams.md "To add or remove role assignments for a team, a user must hold a role that grants both the role:update and team:update scopes." → ✅ verified (evidence: The scopes reference (content/docs/administration/access-identity/rbac/scopes/org-settings.md) documents both role:update ("Allows modifying existing custom roles and their permission sets") and team:update ("Allows modifying team…; source: gh search code "team:update" --repo pulumi/docs (content/docs/administration/access-identity/rbac/scopes/org-settings.md, content/blog/expanding-pulumi-iam-custom-permissions/index.md))

  • L57 in content/docs/administration/concepts/rbac/teams.md "Being a team admin alone is not sufficient to modify role assignments; a team admin without role:update access cannot modify role assignments." → ✅ verified (evidence: (escalated from pass1) The live Pulumi docs page for Teams states verbatim: "Being a team admin is not sufficient on its own; a team admin without role:update access cannot modify role assignments."; source: https://www.pulumi.com/docs/administration/access-identity/rbac/teams/)

  • L57 in content/docs/administration/concepts/rbac/teams.md "Team admins can always manage the team's Entity Access grants directly, regardless of their role scopes." → ✅ verified (evidence: (escalated from pass1) The Pulumi Cloud Teams doc page states verbatim: "Team admins can, however, always manage the team's Entity Access grants directly, regardless of their role scopes."; source: https://www.pulumi.com/docs/administration/access-identity/rbac/teams/)

  • L58 in content/docs/administration/concepts/rbac/teams.md "Role-backed teams work by creating a team, assigning it a custom role (e.g. with access only to certain stacks or tag-based rules documented at…" → ✅ verified (evidence: roles.md defines the anchor exactly: "##### Tag-based rules (ABAC) {#tag-based-abac-rules}" describing tag conditions and permission sets, matching the linked description in teams.md line 58: "Create a team, assign it a custom role (e.g.…; source: repo:content/docs/administration/concepts/rbac/roles.md#L143, repo:content/docs/administration/concepts/rbac/teams.md#L58)

  • L156-159 in content/docs/administration/concepts/rbac/teams.md "Entities and organization-level access documentation at /docs/administration/concepts/rbac/entities describes the objects that permission sets are granted on…" → ✅ verified (evidence: The entities.md page states "Pulumi Cloud has three entity types: Stacks..., Environments..., Cloud accounts..." (the objects permission sets are granted on) and a separate "## Organization-level access" section describing org-wide…; source: repo:content/docs/administration/concepts/rbac/entities.md)

  • L16 in content/docs/administration/get-started/_index.md "- /docs/administration/onboarding-guide/" → ➖ not-a-claim (evidence: The line is an entry in the page's aliases: front-matter list (- /docs/administration/onboarding-guide/), meaning this page itself now serves as a redirect target for that old URL. It's routing/redirect metadata, not a falsifiable…; source: repo:content/docs/administration/get-started/_index.md)

  • L8 in content/docs/administration/get-started/choose-edition.md "- /docs/administration/onboarding-guide/choose-edition/" → ➖ not-a-claim (evidence: The line is a frontmatter aliases entry (/docs/administration/onboarding-guide/choose-edition/) pointing to the old URL path of this now-renamed/moved file, used for redirect purposes — it's metadata, not a falsifiable assertion.; source: repo:content/docs/administration/get-started/choose-edition.md)

  • L85 in content/docs/administration/get-started/choose-edition.md "Both billing options include detailed usage insights through the Billing & usage page in your organization settings. Track IaC resources, deployment minutes…" → ✅ verified (evidence: The linked page content/docs/ai/neo/usage-limits/_index.md exists and states: "A Neo usage limit caps what your organization spends on Neo in a monthly billing period... Members with the Admin or Billing Manager role can view and change…; source: repo:content/docs/ai/neo/usage-limits/_index.md)

  • L98 in content/docs/administration/get-started/choose-edition.md "Sign up using your email address and password, or connect with your GitHub, GitLab, or Atlassian identity at [app.pulumi.com/signup](https://app.pulumi.com/sig…" → 🤷 unverifiable (evidence: The pre-fetched URL returned HTTP 200 but the body is just a minimal shell ("Pulumi Cloud") since it's a JS-rendered signup app; no content confirms or denies the specific sign-up methods (email/password, GitHub, GitLab, Atlassian) or…; source: https://app.pulumi.com/signup)

  • L7 in content/docs/administration/get-started/migrating-to-pulumi.md "- /docs/administration/onboarding-guide/migrating-to-pulumi/" → ➖ not-a-claim (evidence: The line is a frontmatter aliases: entry listing a legacy URL path that should redirect to this page. It's redirect metadata from a page reorganization, not a falsifiable assertion.; source: repo:content/docs/administration/get-started/migrating-to-pulumi.md)

  • L7 in content/docs/administration/get-started/setting-up-for-success.md "- /docs/administration/onboarding-guide/setting-up-for-success/" → ➖ not-a-claim (evidence: This line is part of the aliases list in the page's front matter, recording a prior URL path (/docs/administration/onboarding-guide/setting-up-for-success/) that should redirect to this current page. It's redirect/routing metadata…; source: repo:content/docs/administration/get-started/setting-up-for-success.md)

  • L7 in content/docs/administration/get-started/ways-of-working.md "- /docs/administration/onboarding-guide/ways-of-working/" → ➖ not-a-claim (evidence: Line 7 is an entry in the page's own aliases: frontmatter list, listing a former URL path (/docs/administration/onboarding-guide/ways-of-working/) that redirects to this current page. This is redirect metadata describing the page's own…; source: repo:content/docs/administration/get-started/ways-of-working.md)

  • L79 in content/docs/administration/get-started/ways-of-working.md "Teams are groups of individual users that typically reflect your company's structure or working groups. By organizing members into teams, you can control…" → ✅ verified (framing: The teams page describes stack-level permissions, role assignments, and entity access grants (stacks/environments/cloud accounts) plus GitHub-based team…; evidence: The linked page /docs/administration/concepts/rbac/teams/ confirms: "The Pulumi Cloud offers role-based access control (RBAC) using teams. Teams allow organization admins to assign a set of stack permissions to a group of users," plus…; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L83 in content/docs/administration/get-started/ways-of-working.md "Many organizations prefer to use Single Sign-On (SSO) with identity providers like Microsoft Entra ID, Google Workspace, Okta, or any SAML 2.0 compliant…" → ✅ verified (evidence: The linked page /docs/administration/guides/saml/ confirms Pulumi Cloud supports SAML 2.0 SSO with example integration guides for Microsoft Entra ID, Google Workspace, and Okta, and includes an SSO/SCIM limits notice, matching the…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L85 in content/docs/administration/get-started/ways-of-working.md "Once you've completed the setup steps, you're ready to invite your team. Refer to [Inviting members to an organization](/docs/administration/concepts/organizat…" → ✅ verified (evidence: content/docs/administration/concepts/organizations.md contains a heading "## Inviting members to an organization" (line 62) with detailed invite instructions, matching the anchor /docs/administration/concepts/organizations/#inviting-member…; source: repo:content/docs/administration/concepts/organizations.md)

  • L142 in content/docs/administration/get-started/ways-of-working.md "4. Set up Pulumi Cloud access tokens for automation" → ❌ contradicted (evidence: The docs repo has no content/docs/administration/concepts/ directory at all (404 on lookup), and every other reference to access tokens across the site (e.g. content/docs/iac/cli/api.md…; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts (404); gh search code --owner pulumi access-tokens --repo pulumi/docs)

  • L5 in content/docs/administration/guides/_index.md "This guides section covers task-oriented guides for administering Pulumi Cloud, specifically SAML SSO, SCIM provisioning, OIDC issuers, audit log export, and…" → 🌀 framing-drift (framing: Claim presents an exhaustive list ("specifically ... and customer-managed keys") but the source page lists a sixth guide, Least Privilege, not mentioned in…; evidence: The page's own guide list includes six guides, not five: SAML SSO, SCIM, OIDC issuers, export audit logs, customer managed keys, AND "Least privilege — apply least-privilege access across IaC, ESC, and CI/CD." The claim's enumeration…; source: repo:content/docs/administration/guides/_index.md)

  • L14 in content/docs/administration/guides/_index.md "There is a Concepts page at /docs/administration/concepts/ describing the model that these administration guides configure." → ✅ verified (evidence: content/docs/administration/concepts/_index.md exists at the path /docs/administration/concepts/ and describes "How Pulumi Cloud models your organization and who can do what inside it," and itself links back: "see…; source: repo:content/docs/administration/concepts/_index.md)

  • L18-20 in content/docs/administration/guides/_index.md "Pulumi Cloud's SAML SSO feature can connect Pulumi Cloud to Microsoft Entra ID, Okta, Google Workspace, Auth0, JumpCloud, or OneLogin." → ✅ verified (evidence: The SAML SSO guide page lists "Integration Guides" for exactly: Microsoft Entra ID, Google Workspace, JumpCloud, Okta, Auth0, and OneLogin, matching the claim's list of six providers.; source: repo:content/docs/administration/guides/saml/_index.md)

  • L19 in content/docs/administration/guides/_index.md "Pulumi Cloud's SCIM feature can automate user and team provisioning from a customer's identity provider." → ✅ verified (evidence: The SCIM guide states: "SCIM enables you to manage your users and groups centrally in your Identity Provider (IdP) and then synchronize those users and groups to the Pulumi Cloud," and details user/group (team) provisioning, matching the…; source: repo:content/docs/administration/guides/scim/_index.md)

  • L20 in content/docs/administration/guides/_index.md "The OIDC issuers guide describes letting GitHub, GitLab, or a Kubernetes cluster exchange its own OIDC tokens for Pulumi Cloud credentials." → ✅ verified (framing: Source lists GitHub Actions, GitLab CI, AWS EKS, Google GKE "and others" as issuers; claim's GitHub/GitLab/Kubernetes cluster examples are a subset entailed…; evidence: The OIDC Issuers page states: "Any third-party service that can issue OIDC id_tokens — GitHub Actions, GitLab CI, AWS EKS, Google GKE, and others — can be registered in Pulumi Cloud as a trusted OIDC Issuer" and describes the flow: "The…; source: content/docs/administration/guides/oidc-issuers/_index.md)

  • L24-26 in content/docs/administration/guides/_index.md "The export audit logs guide describes streaming an organization's audit log to AWS S3 or Microsoft Sentinel." → ✅ verified (evidence: The export-audit-logs guide page lists exactly two export destinations: "Export to AWS S3" and "Export to Microsoft Sentinel", matching the parent page's summary "stream your organization's audit log to AWS S3 or Microsoft Sentinel."; source: repo:content/docs/administration/guides/export-audit-logs/_index.md)

  • L25 in content/docs/administration/guides/_index.md "Pulumi Cloud's customer managed keys feature lets customers bring their own encryption key from an external key management system." → ✅ verified (framing: Source describes the setup process (owning/revoking a key via external KMS); claim's summary of "bring their own encryption key from an external key…; evidence: The customer-managed-keys guide page states: "Set up an external key management system so Pulumi Cloud encrypts your organization's data with a key you own and can revoke," confirming the claim that customers bring their own key from an…; source: content/docs/administration/guides/customer-managed-keys/_index.md)

  • L26 in content/docs/administration/guides/_index.md "Pulumi Cloud's least privilege guide covers applying least-privilege access across IaC, ESC, and CI/CD." → ❌ contradicted (framing: Content is accurately described but the cited URL path (/docs/administration/guides/least-privilege/) does not match the real location…; evidence: The least-privilege guide exists and does cover "least-privilege security across Pulumi IaC, ESC, and CI/CD" (per its meta_desc), but it lives at /docs/administration/security-compliance/least-privilege/, not at the cited…; source: gh api repos/pulumi/docs/contents/content/docs/administration/security-compliance/least-privilege/_index.md)

  • L30 in content/docs/administration/guides/_index.md "- Billing managers — assign the people who manage billing and subscriptions." → ❌ contradicted (evidence: The current content/docs/administration/guides/_index.md does not contain a "Billing managers" entry at all, and the linked path /docs/administration/guides/billing-managers/ does not exist. The actual billing managers page lives at…; source: repo:content/docs/administration/guides/_index.md; gh search code --repo pulumi/docs billing-managers)

  • L16 in content/docs/administration/guides/billing-managers.md "- /docs/administration/organizations-teams/billing-managers/" → ➖ not-a-claim (evidence: The line is a Hugo aliases: front-matter entry in a page being moved from content/docs/administration/organizations-teams/billing-managers.md to content/docs/administration/guides/billing-managers.md. The alias target…; source: gh_query api repos/pulumi/docs/contents/content/docs/administration/organizations-teams/billing-managers.md (ref=master))

  • L31 in content/docs/administration/guides/billing-managers.md "Billing Managers, like members, must be members of the [organization identity provider](/docs/administration/concepts/organizations/#organization-identity-prov…" → ✅ verified (framing: Source states the general rule for all members joining a third-party-IdP-backed org; claim narrows this to Billing Managers specifically, which is a valid…; evidence: (escalated from pass1 after exhausting its 12-turn cap) Pulumi's organizations documentation confirms: "If using a third-party identity provider all members need to belong to the third-party identity provider in order to join a Pulumi…; source: https://www.pulumi.com/docs/administration/organizations-teams/organizations/)

  • L12 in content/docs/administration/guides/customer-managed-keys/_index.md "Customer managed keys is a named Pulumi Cloud feature identified by the key 'customer-managed-keys', implying it may be gated to specific plans/tiers." → ✅ verified (evidence: The page's frontmatter pulumi_cloud_feature: customer-managed-keys matches the documented pattern in pulumi/docs AGENTS.md: "add pulumi_cloud_feature: <feature-id> to the front matter... We only mark what a reader has to buy, so an…; source: gh search code --owner pulumi "pulumi_cloud_feature" -R pulumi/docs (AGENTS.md, data/pulumi_pricing.yaml); content/blog/bring-your-own-keys-with-pulumi-esc/index.md)

  • L15 in content/docs/administration/guides/customer-managed-keys/_index.md "Pulumi's documentation includes a page titled 'Customer managed keys' at /docs/administration/concepts/customer-managed-keys/ that explains how customer…" → ❌ contradicted (evidence: The pulumi/docs repo's content/docs/administration/ directory contains only access-identity, onboarding-guide, organizations-teams, security-compliance, and self-hosting subdirectories — there is no "concepts" directory, so…; source: gh api repos/pulumi/docs/contents/content/docs/administration)

  • L17 in content/docs/administration/guides/customer-managed-keys/_index.md "Pulumi's documentation includes an AWS KMS guide at /docs/administration/guides/customer-managed-keys/aws-kms/ for configuring customer managed keys." → ✅ verified (evidence: Found content/docs/administration/guides/customer-managed-keys/aws-kms.md, a full step-by-step "AWS KMS" guide with menu identifier "administration-guides-customer-managed-keys-aws-kms" that renders at…; source: repo:content/docs/administration/guides/customer-managed-keys/aws-kms.md)

  • L15 in content/docs/administration/guides/customer-managed-keys/aws-kms.md "- /docs/administration/security-compliance/customer-managed-keys/aws-kms/" → ➖ not-a-claim (evidence: This line is a Hugo aliases: frontmatter entry listing a prior URL path for redirect purposes, not a falsifiable assertion — it's metadata about the page's own history, not a claim about external content.; source: repo:content/docs/administration/guides/customer-managed-keys/aws-kms.md)

  • L20 in content/docs/administration/guides/customer-managed-keys/aws-kms.md "Keys (CMKs) with Pulumi Cloud](/docs/administration/concepts/customer-managed-keys/). It covers setting up the necessary AWS" → ✅ verified (evidence: The linked page content/docs/administration/concepts/customer-managed-keys.md exists, renders at /docs/administration/concepts/customer-managed-keys/, and documents "Customer Managed Keys (CMKs)" for Pulumi Cloud, matching the anchor…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)

  • L122 in content/docs/administration/guides/customer-managed-keys/aws-kms.md "the Customer Managed Keys documentation." → ✅ verified (evidence: The file content/docs/administration/concepts/customer-managed-keys.md exists with title "Customer Managed Keys" and identifier administration-concepts-customer-managed-keys, matching the linked path…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)

  • L5 in content/docs/administration/guides/export-audit-logs/_index.md "Pulumi Cloud supports streaming an organization's audit log to an external system for long-term retention and analysis." → ✅ verified (evidence: The pulumi-pulumiservice repo ships a real "audit-log-export" API (examples/api/audit-log-export), the feature is tracked in data/pulumi_pricing.yaml as "audit-log-export", and Pulumi's own release notes reference "Automated audit log…; source: gh search code --owner pulumi audit-log-export (pulumi/pulumi-pulumiservice examples/api/audit-log-export; data/pulumi_pricing.yaml id: audit-log-export; content/blog/pulumi-release-notes-m63))

  • L12 in content/docs/administration/guides/export-audit-logs/_index.md "Audit log export is a Pulumi Cloud feature gated by the identifier 'audit-log-export'." → ✅ verified (evidence: The page's front matter sets pulumi_cloud_feature: audit-log-export, and the same identifier audit-log-export is used consistently across the docs repo (sibling audit-log pages, data/pulumi_pricing.yaml with `- id…; source: repo:content/docs/administration/guides/export-audit-logs/_index.md; gh search code --owner pulumi "audit-log-export")

  • L15 in content/docs/administration/guides/export-audit-logs/_index.md "Exporting Pulumi Cloud audit logs to an external system lets you correlate Pulumi activity with the rest of your security tooling." → ✅ verified (evidence: The guide's own body text states: "Pulumi Cloud retains audit logs for a limited window. Exporting them to a system you control gives you long-term retention and lets you correlate Pulumi activity with the rest of your security tooling."…; source: repo:content/docs/administration/guides/export-audit-logs/_index.md and repo:content/docs/administration/concepts/_index.md)

  • L17-18 in content/docs/administration/guides/export-audit-logs/_index.md "Pulumi Cloud supports exporting audit logs to Microsoft Sentinel (via Azure)." → ✅ verified (evidence: The sibling docs page content/docs/administration/guides/export-audit-logs/azure-sentinel.md details how "Pulumi Cloud can continuously export audit log events into Microsoft Sentinel... using a Codeless Connector (CCF)", and the…; source: repo:content/docs/administration/guides/export-audit-logs/azure-sentinel.md; gh api repos/pulumi/examples/contents/azure-ts-sentinel-audit-logs)

  • L17-18 in content/docs/administration/guides/export-audit-logs/_index.md "- Export to Microsoft Sentinel" → ✅ verified (evidence: (escalated from pass1 after exhausting its 12-turn cap) Pulumi's audit logs documentation confirms a dedicated Microsoft Sentinel export guide exists alongside the AWS S3 export guide: "See the Microsoft Sentinel export guide for setup…; source: https://www.pulumi.com/docs/administration/security-compliance/audit-logs/)

  • L13 in content/docs/administration/guides/export-audit-logs/aws-s3.md "- /docs/administration/security-compliance/audit-logs/aws-s3/" → ➖ not-a-claim (evidence: The referenced line is an aliases: front-matter entry (/docs/administration/security-compliance/audit-logs/aws-s3/) used to set up a redirect from the old page path to the current one — it's site routing metadata, not a factual…; source: repo:content/docs/administration/guides/export-audit-logs/aws-s3.md)

  • L13 in content/docs/administration/guides/export-audit-logs/azure-sentinel.md "- /docs/administration/security-compliance/audit-logs/azure-sentinel/" → ➖ not-a-claim (evidence: This is an aliases frontmatter entry providing a redirect from the old URL path to this renamed/moved doc page — it's routing metadata describing the PR author's own restructuring, not a falsifiable factual assertion.; source: repo:content/docs/administration/guides/export-audit-logs/azure-sentinel.md)


  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor
continued from previous comment
  • L9-11 in content/docs/administration/guides/least-privilege.md "The 'Least Privilege' documentation page is organized under the 'administration-guides' menu section with a weight of 6 and identifier…" → ✅ verified (evidence: The file's front matter reads: menu: administration: name: Least Privilege, parent: administration-guides, weight: 6, identifier: administration-guides-least-privilege — matching the claim exactly.; source: repo:content/docs/administration/guides/least-privilege.md)

  • L16 in content/docs/administration/guides/least-privilege.md "The path /docs/administration/security-compliance/least-privilege/ is a valid alias that redirects to this Least Privilege guide." → ✅ verified (evidence: Frontmatter of least-privilege.md lists /docs/administration/security-compliance/least-privilege/ under aliases:, confirming it is a valid Hugo alias that redirects to this page.; source: repo:content/docs/administration/guides/least-privilege.md)

  • L22 in content/docs/administration/guides/least-privilege.md "Access to Pulumi Cloud itself is governed by role-based access control (RBAC), documented at /docs/administration/concepts/rbac/, which decides who can read…" → ✅ verified (evidence: The linked page /docs/administration/concepts/rbac/ exists and describes RBAC as controlling "who can access which resources in your organization and what actions they can take," with permission sets like Stack Read (includes…; source: repo:content/docs/administration/concepts/rbac/_index.md and repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L41 in content/docs/administration/guides/least-privilege.md "For access to Pulumi Cloud from automation, OIDC issuers (documented at /docs/administration/guides/oidc-issuers/) let a pipeline authenticate without a…" → ✅ verified (evidence: The linked page content/docs/administration/guides/oidc-issuers/_index.md states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC. Instead of provisioning a long-lived Pulumi access token and…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L63 in content/docs/administration/guides/least-privilege.md "Pulumi Cloud RBAC, documented at /docs/administration/concepts/rbac/, decides who can view and update stacks." → ✅ verified (framing: Source states RBAC controls access to "resources" and actions generally; claim narrows this to the specific case of viewing/updating stacks, which is a…; evidence: The rbac/_index.md page states "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take," and permission sets referenced there (Stack Read/Write/Admin)…; source: repo:content/docs/administration/concepts/rbac/_index.md)

  • L67 in content/docs/administration/guides/least-privilege.md "The roles documentation at /docs/administration/concepts/rbac/roles/#organization-wide-role-settings covers where to configure the organization's default…" → ✅ verified (evidence: The target page has a "### Organization-wide role settings" section (anchor #organization-wide-role-settings) which states: "Organization-wide role settings configure the built-in Member role: its default access levels for stacks…; source: repo:content/docs/administration/concepts/rbac/roles.md)

  • L77 in content/docs/administration/guides/least-privilege.md "Permission sets, documented at /docs/administration/concepts/rbac/permission-sets/#stack-permission-sets, are used to grant elevated access and are assigned…" → ✅ verified (framing: Source says roles (assignable to users, teams, or machine tokens) bundle permission sets; claim's narrower framing ("assigned through roles and teams rather…; evidence: The target page content/docs/administration/concepts/rbac/permission-sets.md exists, contains a "### Stack permission sets" section (which generates the #stack-permission-sets anchor) describing Stack Read/Write/Admin permission sets…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L79-81 in content/docs/administration/guides/least-privilege.md "Pulumi Cloud offers a 'Stack Read' permission set granting read-only access to stacks, including running previews." → ✅ verified (evidence: The RBAC permission-sets doc lists: "Stack Read | Basic read-only access to stacks. Allows for running previews." matching the claim's description exactly.; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L83 in content/docs/administration/guides/least-privilege.md "Teams are documented at /docs/administration/concepts/rbac/teams/, and a team can hold one or more roles and be granted access to specific stacks." (also L85-86) → ✅ verified (evidence: The teams reference (pulumi/docs content/docs/administration/access-identity/rbac/roles.md) confirms: "teams can have role assignments: one or more roles (default or custom)... Team members receive the union of their own user role and…; source: gh search code --owner pulumi repo:pulumi/docs "one or more roles" (content/docs/administration/access-identity/rbac/roles.md, rbac/_index.md))

  • L86 in content/docs/administration/guides/least-privilege.md "The command pulumi stack new --teams YourTeamName grants a team access to a stack when it is created." → ✅ verified (evidence: pulumi/pulumi's pkg/cmd/pulumi/stack/stack_new.go defines the stack new command (aliased init, create, setup) with flag: `cmd.PersistentFlags().StringArrayVar(&sicmd.teams, "teams", nil, "A list of team names that should have…; source: gh api repos/pulumi/pulumi/contents/pkg/cmd/pulumi/stack/stack_new.go)

  • L102 in content/docs/administration/guides/least-privilege.md "Environment permission sets are documented at /docs/administration/concepts/rbac/permission-sets/#environment-permission-sets and are used to grant…" → ✅ verified (evidence: The target page content/docs/administration/concepts/rbac/permission-sets.md contains a section heading "### Environment permission sets" (line 40) with a table of Environment Read/Open/Write/Admin permission sets used to grant…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L104-107 in content/docs/administration/guides/least-privilege.md "Pulumi ESC offers an 'Environment Open' permission set that reads the environment and decrypts its secrets and retrieves dynamic credentials." → ✅ verified (evidence: The RBAC permission-sets reference page lists: "Environment Open | Ability to read the environment and access environment secrets. | Environment Read, + environment:open, environment:clone, environment_version:open…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)

  • L109 in content/docs/administration/guides/least-privilege.md "When you grant a team environment access, Pulumi Cloud labels these permissions Environment reader, opener, editor, and admin, and the teams reference at…" → ✅ verified (evidence: The teams reference page contains a table: "| read | Environment reader | ... | open | Environment opener | ... | write | Environment editor | ... | admin | Environment admin |" confirming the four labeled permission levels for…; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L141 in content/docs/administration/guides/least-privilege.md "If you run your own CI/CD, prefer OIDC token exchange over a stored Pulumi token: your pipeline presents an OIDC token from its platform, and Pulumi Cloud…" → ✅ verified (evidence: The linked /docs/administration/guides/oidc-issuers/ page states: "Workloads on the service then present their own short-lived OIDC id_tokens and receive short-lived Pulumi access tokens in exchange — no hardcoded credentials," and…; source: content/docs/administration/guides/oidc-issuers/_index.md)

  • L143-144 in content/docs/administration/guides/least-privilege.md "On GitHub Actions (documented at /docs/administration/guides/oidc-issuers/github/), the pulumi/auth-actions action performs the OIDC token exchange and can…" → ❌ contradicted (framing: Technical claim about auth-actions is accurate, but the cited link target path does not exist in the docs repo — likely a broken/incorrect internal link…; evidence: The technical assertion (pulumi/auth-actions performs OIDC exchange and can request a team-scoped token) is confirmed by the actual GitHub OIDC docs page, which shows team tokens using `requested-token-type…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/oidc-issuers/github.md; gh search code --owner pulumi "administration/guides/oidc-issuers"; intuition: Cited path uses "guides/oidc-issuers" while the actual doc tree uses "access-identity/oidc-issuers" — looks like a…)

  • L146 in content/docs/administration/guides/least-privilege.md "Team-scoped tokens, which confine a run to one team's permissions, require the Enterprise or Business Critical edition." → ✅ verified (evidence: Pulumi's official docs on Access Tokens and OIDC Issuers state team tokens are edition-gated: "This Pulumi Cloud feature is available in the Enterprise and Business Critical editions" and "Team tokens require the Enterprise or Business…; source: https://www.pulumi.com/docs/administration/access-identity/access-tokens/ and https://www.pulumi.com/docs/administration/access-identity/oidc-issuers/github/)

  • L150 in content/docs/administration/guides/least-privilege.md "A long-lived Pulumi access token is the least preferable authentication choice for CI/CD, because a long-lived token in a CI secret is exactly the standing…" → ➖ not-a-claim (evidence: Line 150 is the guide's own editorial recommendation: "Where OIDC is not an option, you can fall back to a stored Pulumi access token. This is the least preferable choice, because a long-lived token in a CI secret is exactly the standing…; source: repo:content/docs/administration/guides/least-privilege.md (L39-41, L148-150))

  • L154 in content/docs/administration/guides/least-privilege.md "A stack's automatic Stack Admin creator grant belongs to the organization or team the token authenticates as, so it outlives the token itself, including a…" → ✅ verified (framing: Source states this generally for machine tokens (including long-lived ones); claim narrows to the OIDC-issued short-lived token case, which is a specific…; evidence: The RBAC concepts page's "Creator grants" section states the automatic Stack Admin grant "applies to machine tokens as well as to people: a stack created with an organization or team token carries the same automatic grant, held by the…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/rbac/_index.md (Creator grants section))

  • L162 in content/docs/administration/guides/least-privilege.md "Audit logs for access and deployment activity are documented at /docs/administration/concepts/audit-logs/." → ✅ verified (evidence: The file content/docs/administration/concepts/audit-logs.md exists and documents audit logs covering user actions, event timestamps, source IPs, and export of access/deployment activity: "Audit logs enable you to track the activity of…; source: repo:content/docs/administration/concepts/audit-logs.md)

  • L22 in content/docs/administration/guides/oidc-issuers/_index.md "The page at /docs/administration/access-identity/oidc-issuers/ is an alias that redirects to this OIDC Issuers page." → ✅ verified (evidence: The front matter of content/docs/administration/guides/oidc-issuers/_index.md lists aliases including line 22: "- /docs/administration/access-identity/oidc-issuers/", confirming this exact path is a Hugo alias that redirects to this OIDC…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L25 in content/docs/administration/guides/oidc-issuers/_index.md "Registering an external service as a trusted OIDC Issuer in Pulumi Cloud allows workloads on that service to present their own short-lived OIDC id_tokens and…" → ➖ not-a-claim (evidence: This is a paraphrase of the same doc's own introductory line 25 ("OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Instead of provisioning a long-lived Pulumi access token... Workloads on the…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L25 in content/docs/administration/guides/oidc-issuers/_index.md "Workloads on a service registered as a trusted OIDC Issuer present their own short-lived OIDC id_tokens and receive short-lived Pulumi access tokens in…" → ➖ not-a-claim (evidence: This line is a restatement of the same page's own feature description (Overview section: "The workload obtains an OIDC id_token... exchanges that id_token with Pulumi Cloud for a short-lived Pulumi access token"), i.e. a faithful…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L181-184 in content/docs/administration/guides/oidc-issuers/_index.md "The guide for configuring OIDC for Google Kubernetes Engine is located at /docs/administration/guides/oidc-issuers/kubernetes-gke/." → ✅ verified (evidence: The file content/docs/administration/guides/oidc-issuers/kubernetes-gke.md exists with title "Google Kubernetes Engine" / h1 "Configuring OpenID Connect for Google Kubernetes Engine", confirming the link at…; source: repo:content/docs/administration/guides/oidc-issuers/kubernetes-gke.md)

  • L17 in content/docs/administration/guides/oidc-issuers/github.md "- /docs/administration/access-identity/oidc-issuers/github/" → ➖ not-a-claim (evidence: This is a frontmatter aliases entry providing a redirect from the page's former URL path to its current location — it's metadata describing the page's own redirect configuration, not a falsifiable external assertion.; source: repo:content/docs/administration/guides/oidc-issuers/github.md (frontmatter aliases list))

  • L20 in content/docs/administration/guides/oidc-issuers/github.md "This document outlines the steps required to configure Pulumi Cloud to accept GitHub id_tokens and exchange them for Pulumi access tokens. Three token types…" → ✅ verified (evidence: The linked target /docs/administration/guides/oidc-issuers/#token-types-by-edition in _index.md has a "Token types by edition" section stating: "Individual: personal", "Team: personal, organization", "Enterprise: personal…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L16 in content/docs/administration/guides/oidc-issuers/gitlab.md "- /docs/administration/access-identity/oidc-issuers/gitlab/" → ➖ not-a-claim (evidence: The line is part of the aliases list in the page's YAML front matter, used to redirect old URLs to this page. It is metadata, not an assertion of fact.; source: repo:content/docs/administration/guides/oidc-issuers/gitlab.md)

  • L26 in content/docs/administration/guides/oidc-issuers/gitlab.md "This guide demonstrates using organization tokens. Depending on your Pulumi edition…" → ✅ verified (evidence: The linked page content/docs/administration/guides/oidc-issuers/_index.md has a "## Token types by edition" heading (anchor #token-types-by-edition) listing: "Individual: personal", "Team: personal, organization", "Enterprise: personal…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L17 in content/docs/administration/guides/oidc-issuers/kubernetes-eks.md "- /docs/administration/access-identity/oidc-issuers/kubernetes-eks/" → ➖ not-a-claim (evidence: The line - /docs/administration/access-identity/oidc-issuers/kubernetes-eks/ is an entry in the page's aliases: frontmatter list, used to configure a redirect from the old URL to this page's new location. It's a routing/config…; source: repo:content/docs/administration/guides/oidc-issuers/kubernetes-eks.md)

  • L34 in content/docs/administration/guides/oidc-issuers/kubernetes-eks.md "This guide demonstrates using personal tokens. Depending on your Pulumi edition, you…" → ✅ verified (evidence: The linked page content/docs/administration/guides/oidc-issuers/_index.md has a "## Token types by edition" section stating: "Individual: personal; Team: personal, organization; Enterprise: personal, organization, team; Business…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L117 in content/docs/administration/guides/oidc-issuers/kubernetes-eks.md "1. Set Token type to Personal. See the token types section for other options." → ✅ verified (evidence: The oidc-issuers _index.md contains a heading "## Token types by edition" (renders to anchor #token-types-by-edition) listing available token types per edition ("Individual: personal", "Team: personal, organization", etc.), matching the…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L16 in content/docs/administration/guides/oidc-issuers/kubernetes-gke.md "- /docs/administration/access-identity/oidc-issuers/kubernetes-gke/" → ➖ not-a-claim (evidence: Line 16 is part of the aliases: frontmatter list in the page itself, listing prior URL paths that should redirect to this page. It's redirect metadata, not a falsifiable assertion.; source: repo:content/docs/administration/guides/oidc-issuers/kubernetes-gke.md)

  • L35 in content/docs/administration/guides/oidc-issuers/kubernetes-gke.md "This guide demonstrates using organization tokens. Depending on your Pulumi edition…" → ✅ verified (evidence: The target page content/docs/administration/guides/oidc-issuers/_index.md has a "## Token types by edition" section stating: "The available OIDC token types vary by Pulumi edition: Individual: personal; Team: personal, organization…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • L18 in content/docs/administration/guides/saml/_index.md "- /docs/administration/access-identity/saml/" → ➖ not-a-claim (evidence: The line /docs/administration/access-identity/saml/ appears in the aliases: list of the front matter, which is redirect metadata for the page (old URL paths that should resolve to this page), not a factual assertion to verify.; source: repo:content/docs/administration/guides/saml/_index.md)

  • L30 in content/docs/administration/guides/saml/_index.md "If you're a member of a SAML-based Pulumi organization, you can sign in to your account via Single Sign-On. To…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/accounts.md exists and describes Pulumi Cloud accounts, including "Single Sign-on" as a sign-up/sign-in identity option, matching the anchor text "your account" for signing in via SSO.; source: repo:content/docs/administration/concepts/accounts.md)

  • L17 in content/docs/administration/guides/saml/auth0.md "- /docs/administration/access-identity/saml/auth0/" → ➖ not-a-claim (evidence: This line is part of the aliases front-matter list in auth0.md, providing redirect support from a legacy URL path (/docs/administration/access-identity/saml/auth0/) to the current page. It is redirect/route metadata, not a factual…; source: repo:content/docs/administration/guides/saml/auth0.md)

  • L21 in content/docs/administration/guides/saml/auth0.md "This guide walks you through configuring your Auth0 Authentication Platform as a SAML SSO identity provider" → ✅ verified (evidence: The target page content/docs/administration/guides/saml/_index.md is titled "SAML(SSO)" / "SAML Single Sign-On (SSO) Guides" and states "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," and explicitly…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L65 in content/docs/administration/guides/saml/auth0.md "For additional help, see the SAML SSO troubleshooting guide or [contact…" → 🤷 unverifiable (evidence: The cited support.pulumi.com URL returned HTTP 403 Forbidden on fetch, which typically indicates a bot-blocking/access-control mechanism rather than a dead page (unlike a 404). Since this is likely a live support portal that blocks…; source: https://support.pulumi.com/; intuition: 403 could be bot-protection on a legitimate live support portal rather than a broken link; treating as contradicted…)

  • L20 in content/docs/administration/guides/saml/entra.md "- /docs/administration/access-identity/saml/entra/" → ➖ not-a-claim (evidence: The line is part of the page's aliases front-matter list (a set of legacy URLs that redirect to this page), not a falsifiable statement of fact.; source: repo:content/docs/administration/guides/saml/entra.md)

  • L24 in content/docs/administration/guides/saml/entra.md "This guide walks you through configuring Microsoft Entra ID as a SAML SSO identity provider" → ✅ verified (evidence: The target page content/docs/administration/guides/saml/_index.md is titled "SAML(SSO)" and states "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," listing "Microsoft Entra ID (formerly Azure Active…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L118 in content/docs/administration/guides/saml/entra.md "For help resolving SAML SSO configuration issues, see the SAML SSO troubleshooting guide or [contact…" → 🤷 unverifiable (evidence: The cited support.pulumi.com URL returned HTTP 403 (Forbidden) rather than a 4xx/5xx indicating the page doesn't exist; this is likely a bot/anti-scraping block rather than a dead link, since support portals commonly gate access. Cannot…; source: https://support.pulumi.com/; intuition: 403 responses from support/help portals are frequently due to bot protection (e.g. Cloudflare) rather than the page…)

  • L18 in content/docs/administration/guides/saml/gsuite.md "- /docs/administration/access-identity/saml/gsuite/" → ➖ not-a-claim (evidence: This line is part of the aliases front-matter list on the current gsuite.md page, recording a legacy URL path that should redirect to this doc. It's redirect metadata, not a falsifiable assertion.; source: repo:content/docs/administration/guides/saml/gsuite.md)

  • L22 in content/docs/administration/guides/saml/gsuite.md "This guide walks you through configuring your Google Workspace (formerly known as G Suite) service as a SAML SSO…" → ✅ verified (evidence: The linked page content/docs/administration/guides/saml/_index.md is titled "SAML Single Sign-On (SSO) Guides" and states "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," matching the claim's reference to…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L105 in content/docs/administration/guides/saml/gsuite.md "For additional help, see the SAML SSO troubleshooting guide or [contact…" → 🤷 unverifiable (evidence: The cited URL https://support.pulumi.com/ returned HTTP 403 Forbidden when fetched, which appears to be a bot/access-blocking response rather than a genuine dead link (support portals often block automated fetches). Cannot confirm or…; source: https://support.pulumi.com/; intuition: 403 responses from support/helpdesk portals are commonly due to anti-bot protection rather than the page being…)

  • L15 in content/docs/administration/guides/saml/jumpcloud.md "- /docs/administration/access-identity/saml/jumpcloud/" → ➖ not-a-claim (evidence: Line is part of the page's aliases: frontmatter list, used for URL redirect handling — it's metadata, not a factual assertion about content.; source: repo:content/docs/administration/guides/saml/jumpcloud.md)

  • L19 in content/docs/administration/guides/saml/jumpcloud.md "This guide walks you through configuring JumpCloud as a SAML SSO identity provider (IdP) for Pulumi Cloud." → ✅ verified (evidence: The linked page content/docs/administration/guides/saml/_index.md is titled "Pulumi Cloud SAML(SSO)" and states "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," and lists JumpCloud as one of the…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L113 in content/docs/administration/guides/saml/jumpcloud.md "For full SCIM configuration steps on the JumpCloud side, refer to JumpCloud's Integrate with Pulumi…" → 🤷 unverifiable (framing: Page returned 200 but the fetched body did not contain the supporting passage (likely JS-rendered content not present in the static fetch).; evidence: The pre-fetched content for https://jumpcloud.com/support/integrate-with-pulumi returns HTTP 200 but the body consists entirely of client-side script/consent-management boilerplate (Intellimize, Webflow, cookie consent logic) with no…; source: https://jumpcloud.com/support/integrate-with-pulumi)

  • L121 in content/docs/administration/guides/saml/jumpcloud.md "If you encounter issues with your JumpCloud SAML configuration, refer to the SAML troubleshooting guide…" → ✅ verified (evidence: The file content/docs/administration/guides/saml/troubleshooting.md exists at the linked path and contains sections on common SAML error patterns (validation errors, invalid Name ID format, missing SSO binding) with remediation steps…; source: repo:content/docs/administration/guides/saml/troubleshooting.md)

  • L18 in content/docs/administration/guides/saml/okta.md "- /docs/administration/access-identity/saml/okta/" → ➖ not-a-claim (evidence: This line is a front-matter aliases entry listing a previous URL path for redirect purposes, alongside several other historical aliases (/docs/reference/service/saml-okta/, /docs/console/accounts/saml/okta/, etc.). It's metadata…; source: content/docs/administration/guides/saml/okta.md)

  • L22 in content/docs/administration/guides/saml/okta.md "This guide walks you through configuring Okta as a SAML SSO identity provider (IdP) for Pulumi Cloud." → ✅ verified (evidence: The target page content/docs/administration/guides/saml/_index.md exists, describes SAML SSO configuration for Pulumi Cloud ("The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider"), and links to the Okta guide…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L64 in content/docs/administration/guides/saml/okta.md "If you plan on using SCIM, you will need to provide the above attributes, in addition to the email attribute." → ✅ verified (evidence: The linked page content/docs/administration/guides/scim/okta.md exists at /docs/administration/guides/scim/okta/ and its "Changing the SAML SSO Settings For SCIM" section confirms the requirement to add the email attribute alongside…; source: repo:content/docs/administration/guides/scim/okta.md)

  • L141 in content/docs/administration/guides/saml/okta.md "For help resolving SAML SSO configuration issues, see the SAML SSO troubleshooting guide or [contact…" → 🤷 unverifiable (evidence: The cited support.pulumi.com URL returned HTTP 403 Forbidden on fetch, likely due to bot/access protection rather than the page being genuinely dead (support portals commonly block automated requests). No body content was available to…; source: https://support.pulumi.com/; intuition: 403 on a support portal is often an anti-bot gate rather than a true dead link; treating it as contradicted could be…)

  • L18 in content/docs/administration/guides/saml/onelogin.md "- /docs/administration/access-identity/saml/onelogin/" → ➖ not-a-claim (evidence: This is a line in the aliases front-matter list of the page, recording a legacy URL path that should redirect to the current page. It's routing metadata, not a factual assertion.; source: repo:content/docs/administration/guides/saml/onelogin.md)

  • L22 in content/docs/administration/guides/saml/onelogin.md "This guide walks you through configuring OneLogin as a SAML SSO identity provider (IdP) for Pulumi Cloud." → ✅ verified (evidence: The linked page content/docs/administration/guides/saml/_index.md is titled "Pulumi Cloud SAML(SSO)" and states "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," and its Integration Guides section…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L113 in content/docs/administration/guides/saml/onelogin.md "For help resolving SAML SSO configuration issues, see the SAML SSO troubleshooting guide or [contact…" → 🤷 unverifiable (evidence: The cited support.pulumi.com URL returned HTTP 403 (Forbidden) on fetch, which is typically a bot-blocking/auth-wall response rather than a dead page (unlike a 404). This is a support portal likely requiring login, so it cannot be…; source: https://support.pulumi.com/; intuition: 403 responses from support/auth-gated portals are common and don't necessarily mean the link is dead; worth…)

  • L14 in content/docs/administration/guides/saml/saml-admin.md "- /docs/administration/access-identity/saml/saml-admin/" → ➖ not-a-claim (evidence: This is a Hugo aliases front-matter entry providing a redirect from the old URL path to the current page; it's site metadata, not a falsifiable assertion.; source: repo:content/docs/administration/guides/saml/saml-admin.md)

  • L18 in content/docs/administration/guides/saml/sso.md "- /docs/administration/access-identity/saml/sso/" → ➖ not-a-claim (evidence: Line is part of the aliases: front-matter list for redirects, listing a legacy path /docs/administration/access-identity/saml/sso/ that redirects to this page — it's metadata, not a factual assertion.; source: repo:content/docs/administration/guides/saml/sso.md)

  • L26 in content/docs/administration/guides/saml/sso.md "For examples of setting up SAML SSO with popular identity providers, refer to our integration guides." → ✅ verified (evidence: content/docs/administration/guides/saml/_index.md contains a "## Integration Guides" section (anchor #integration-guides) stating: "If you're looking to integrate Pulumi with your SAML 2.0 identity provider, refer to one of our example…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L95 in content/docs/administration/guides/saml/sso.md "For information on the SAML admin role and how to configure it, see SAML admin." → ✅ verified (evidence: content/docs/administration/guides/saml/saml-admin.md exists at the linked path, titled "SAML admin", and describes the SAML admin role and how to configure/change it, matching the link text exactly.; source: repo:content/docs/administration/guides/saml/saml-admin.md)

  • L99 in content/docs/administration/guides/saml/sso.md "For help resolving SAML SSO configuration issues, see SAML SSO troubleshooting." → ✅ verified (evidence: content/docs/administration/guides/saml/troubleshooting.md exists, titled "SAML SSO troubleshooting" ("h1: SAML SSO troubleshooting"), matching the link target /docs/administration/guides/saml/troubleshooting/ and its anchor text.; source: repo:content/docs/administration/guides/saml/troubleshooting.md)

  • L14 in content/docs/administration/guides/saml/troubleshooting.md "- /docs/administration/access-identity/saml/troubleshooting/" → ➖ not-a-claim (evidence: This is a frontmatter aliases entry for the file's own page (redirect metadata for a legacy URL path), not a falsifiable factual assertion.; source: repo:content/docs/administration/guides/saml/troubleshooting.md)

  • L19 in content/docs/administration/guides/saml/troubleshooting.md "If you are locked out of your Pulumi organization due to a SAML configuration error or an expired certificate, a [SAML admin](/docs/administration/guides/saml/…" → ✅ verified (evidence: The target page content/docs/administration/guides/saml/saml-admin.md exists at the linked path and states: "A SAML admin can log in to your Pulumi organization using an alternative login method. This ensures someone can always log in to…; source: repo:content/docs/administration/guides/saml/saml-admin.md)

  • L39 in content/docs/administration/guides/saml/troubleshooting.md "As mentioned in the Name ID Format section, Pulumi expects specific values in your IdP metadata XML." → ✅ verified (evidence: content/docs/administration/guides/saml/sso.md contains a "### Name ID Format" section (anchor #name-id-format) stating "Pulumi only accepts stable and persistent identifiers for users. Identity providers must be able to set either a…; source: repo:content/docs/administration/guides/saml/sso.md)

  • L14 in content/docs/administration/guides/scim/_index.md "- /docs/administration/access-identity/scim/" → ➖ not-a-claim (evidence: The line is a redirect alias entry in the page's front matter (aliases: - /docs/administration/access-identity/scim/), indicating this is a former URL for the page that should redirect here. It's routing/metadata configuration, not a…; source: repo:content/docs/administration/guides/scim/_index.md)

  • L20 in content/docs/administration/guides/scim/_index.md "SCIM provisions two things in Pulumi Cloud." → ➖ not-a-claim (evidence: The line "SCIM provisions two things in Pulumi Cloud:" is immediately followed by the two bulleted items (Users, Groups) in the same document, making it a structural summary/topic sentence for the page's own content rather than an…; source: repo:content/docs/administration/guides/scim/_index.md)

  • L20-23 in content/docs/administration/guides/scim/_index.md "Through SCIM provisioning, groups become teams, and group membership becomes team membership, with teams grantable access to stacks, environments, and other…" → ✅ verified (evidence: The SCIM doc itself states: "Groups become teams, and group membership becomes team membership. Grant those teams access to stacks, environments, and other entities with RBAC," linking to /docs/administration/concepts/rbac/teams/ and…; source: content/docs/administration/guides/scim/_index.md L20-23; content/docs/administration/concepts/rbac/_index.md)

  • L23 in content/docs/administration/guides/scim/_index.md "- Groups become teams, and group membership becomes team membership. Grant those teams access to stacks…" → ✅ verified (evidence: The linked RBAC concepts page confirms Teams are the mechanism for group-based access: "Teams: Groups of users that can be assigned roles" and describes granting teams roles/entity access on stacks, environments, and cloud accounts…; source: content/docs/administration/concepts/rbac/_index.md)

  • L25 in content/docs/administration/guides/scim/_index.md "Every identity provider uses the same routes, schemas, and attributes for Pulumi's SCIM implementation, so only the IdP-side setup differs from one provider…" → 🤝 matches (evidence: All three sibling provider guides (Entra, Okta, OneLogin) reference the identical base URL pattern https://api.pulumi.com/scim/v2/{orgName}, the same attribute list (userName, displayName, name.givenName, name.familyName, emails[type…; source: content/docs/administration/guides/scim/entra.md, content/docs/administration/guides/scim/okta.md, content/docs/administration/guides/scim/onelogin.md)

  • L25 in content/docs/administration/guides/scim/_index.md "Pulumi implements a single SCIM 2.0 endpoint, and every identity provider uses the same routes, schemas, and attributes, so only the IdP-side setup differs…" → 🤝 matches (evidence: Sibling provider guides (Okta, Entra) both point to the identical endpoint pattern https://api.pulumi.com/scim/v2/<orgName> and both explicitly defer to the shared capabilities/attributes section on this _index.md page ("For the…; source: content/docs/administration/guides/scim/okta.md, content/docs/administration/guides/scim/entra.md)

  • L25 in content/docs/administration/guides/scim/_index.md "The guides at the end of the page cover popular identity providers, and everything documented on the page applies to each of them." → 🤝 matches (evidence: The Okta and Entra ID guides both link back to the main SCIM page's Capabilities section ("For the capabilities and attributes Pulumi's SCIM implementation supports, see Pulumi Cloud & SCIM") and both independently reflect the same rules…; source: content/docs/administration/guides/scim/okta.md; content/docs/administration/guides/scim/entra.md)

  • L44 in content/docs/administration/guides/scim/_index.md "Pulumi implements only the core SCIM 2.0 schemas, so a request that adds or updates any attribute not listed in the supported-attributes lists fails with a…" → ✅ verified (evidence: The troubleshooting doc's "Unknown path" section shows the exact response: {"status": "400", "scimType": "invalidPath", "detail": "Unknown path: {path}."} with cause "Pulumi only supports adding or updating the following user attributes"…; source: repo:content/docs/administration/guides/scim/troubleshooting.md and repo:content/docs/administration/guides/scim/_index.md)

  • L112 in content/docs/administration/guides/scim/_index.md "Pulumi provides example guides for setting up synchronization between Pulumi and a SAML 2.0 identity provider." → ❌ contradicted (evidence: The claim describes L112 of the SCIM guide page, which reads "To set up synchronization between Pulumi and your SAML 2.0 identity provider, refer to one of our example guides" — but the entire page (title "SCIM 2.0 Integration Guides"…; source: repo:content/docs/administration/guides/scim/_index.md (L112) vs repo:content/blog/easily-bring-your-team-to-pulumi/index.md ("To configure user and group synchronization via SCIM, use the guide that matches your IdP"))

  • L112-116 in content/docs/administration/guides/scim/_index.md "Pulumi provides example setup guides for synchronizing SCIM with Microsoft Entra ID (formerly Azure Active Directory), Okta, and OneLogin, located at…" → ✅ verified (evidence: The _index.md file's "Next steps" section lists exactly these three links with matching labels: "Microsoft Entra ID (formerly Azure Active Directory)"…; source: repo:content/docs/administration/guides/scim/_index.md (lines 112-116))

  • L118 in content/docs/administration/guides/scim/_index.md "A troubleshooting guide covering the provisioning errors users are most likely to encounter and how to resolve them is located at…" → ✅ verified (evidence: A troubleshooting.md file for SCIM exists in the docs repo (content/docs/administration/access-identity/scim/troubleshooting.md, mirroring the guides/scim path structure used in this PR), and the parent _index.md links to it the same…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/scim (troubleshooting.md present))

  • L17 in content/docs/administration/guides/scim/entra.md "- /docs/administration/access-identity/scim/entra/" → ➖ not-a-claim (evidence: The line is an aliases: entry in the frontmatter of entra.md, listing /docs/administration/access-identity/scim/entra/ as the old URL now redirecting to this page post-rename — a faithful description of the file's own redirect…; source: repo:content/docs/administration/guides/scim/entra.md)

  • L23 in content/docs/administration/guides/scim/entra.md "For the capabilities and attributes Pulumi's SCIM implementation supports, see Pulumi Cloud & SCIM." → ✅ verified (evidence: content/docs/administration/guides/scim/_index.md contains an H2 heading "## Capabilities" (line 31) with a table of supported SCIM capabilities/attributes, which generates the anchor #capabilities referenced by the link.; source: repo:content/docs/administration/guides/scim/_index.md)

  • L27 in content/docs/administration/guides/scim/entra.md "* Your organization must already be configured to use SAML SSO with Pulumi." → ✅ verified (evidence: content/docs/administration/guides/saml/entra.md exists and is titled "SAML: Configuring Microsoft Entra ID", confirming the link target /docs/administration/guides/saml/entra/ is a valid SAML SSO guide for Pulumi, matching the claim.; source: repo:content/docs/administration/guides/saml/entra.md)

  • L15 in content/docs/administration/guides/scim/okta.md "- /docs/administration/access-identity/scim/okta/" → ➖ not-a-claim (evidence: The line is part of the aliases: list in the frontmatter of okta.md, declaring that the old URL path /docs/administration/access-identity/scim/okta/ should redirect to this current page (confirmed the file no longer exists at that…; source: repo:content/docs/administration/guides/scim/okta.md)

  • L21 in content/docs/administration/guides/scim/okta.md "For the capabilities and attributes Pulumi's SCIM implementation supports, see Pulumi Cloud & SCIM." → ✅ verified (evidence: content/docs/administration/guides/scim/_index.md contains a ## Capabilities heading (line 31) with a table of supported SCIM capabilities/attributes, which generates the anchor #capabilities matching the linked target…; source: repo:content/docs/administration/guides/scim/_index.md)

  • L25 in content/docs/administration/guides/scim/okta.md "* Your organization must already be configured to use SAML SSO with Pulumi." → ✅ verified (evidence: The linked page content/docs/administration/guides/saml/okta.md exists, titled "SAML: Configuring Okta" ("This guide walks you through configuring Okta as a SAML SSO identity provider (IdP) for Pulumi Cloud"), matching the…; source: repo:content/docs/administration/guides/saml/okta.md)

  • L15 in content/docs/administration/guides/scim/onelogin.md "- /docs/administration/access-identity/scim/onelogin/" → ➖ not-a-claim (evidence: The line is part of the page's own aliases frontmatter list (a redirect from an old URL path to this page), not a falsifiable external assertion.; source: repo:content/docs/administration/guides/scim/onelogin.md)

  • L21 in content/docs/administration/guides/scim/onelogin.md "For the capabilities and attributes Pulumi's SCIM implementation supports, see Pulumi Cloud & SCIM." → ✅ verified (evidence: The target page content/docs/administration/guides/scim/_index.md contains a "## Capabilities" section (line 31) listing supported capabilities and attributes (user provisioning, deprovisioning, group sync, PATCH, filtering), matching…; source: repo:content/docs/administration/guides/scim/_index.md)

  • L25 in content/docs/administration/guides/scim/onelogin.md "* Your organization must already be configured to use SAML SSO with Pulumi." → ✅ verified (evidence: The linked page content/docs/administration/guides/saml/onelogin.md exists at path /docs/administration/guides/saml/onelogin/ and its content confirms: "This guide walks you through configuring OneLogin as a SAML SSO identity provider…; source: repo:content/docs/administration/guides/saml/onelogin.md)

  • L86 in content/docs/administration/guides/scim/onelogin.md "Whatever value you choose for scimusername, it must stay stable for the lifetime of the account. Pulumi usernames are immutable, so an update that changes…" → ✅ verified (evidence: The linked section "Usernames cannot change" in scim/_index.md states: "A Pulumi username is immutable once the account exists... If your IdP pushes a changed userName on an update, the request fails with a 400 immutability response."…; source: repo:content/docs/administration/guides/scim/_index.md (section ### Usernames cannot change))

  • L17 in content/docs/administration/guides/scim/troubleshooting.md "- /docs/administration/access-identity/scim/troubleshooting/" → ➖ not-a-claim (evidence: Line 17 is an entry in the aliases: front-matter list of the new page (content/docs/administration/guides/scim/troubleshooting.md), pointing back to the old pre-move URL /docs/administration/access-identity/scim/troubleshooting/ so old…; source: repo:content/docs/administration/guides/scim/troubleshooting.md)

  • L50 in content/docs/administration/guides/scim/troubleshooting.md "If the existing account is already managed by SAML SSO in another Pulumi organization, use option 3. Signing in to the new organization directly returns an…" → ✅ verified (evidence: The saml/_index.md page has a heading "## Connect SAML SSO to an existing account" (anchor #connect-saml-sso-to-an-existing-account) stating: "If you already have a Pulumi account and need to access a SAML-based organization, connect…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L85 in content/docs/administration/guides/scim/troubleshooting.md "Cause: Pulumi usernames are immutable and cannot be updated. See Usernames cannot change." → ✅ verified (evidence: The target page content/docs/administration/guides/scim/_index.md contains a section '### Usernames cannot change' at line 94 stating: 'A Pulumi username is immutable once the account exists... If your IdP pushes a changed userName on an…; source: repo:content/docs/administration/guides/scim/_index.md)

  • L112 in content/docs/administration/guides/scim/troubleshooting.md "Provisioning jobs that try to add or update any other attribute fail. For the complete supported surface, including group attributes, see [Supported…" → ✅ verified (evidence: The linked page content/docs/administration/guides/scim/_index.md contains a "## Supported attributes" section (anchor #supported-attributes) stating: "The lists below are complete... so a request that adds or updates any attribute not…; source: repo:content/docs/administration/guides/scim/_index.md)

  • L156 in content/docs/administration/guides/scim/troubleshooting.md "Alongside the SCIM-managed teams, you can also configure and manage Pulumi-local teams in the Pulumi Cloud. See [Teams](/docs/administration/concepts/rbac/team…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/teams.md exists at the cited path /docs/administration/concepts/rbac/teams/ and describes exactly how to configure and manage teams in Pulumi Cloud: "The Pulumi Cloud offers…; source: repo:content/docs/administration/concepts/rbac/teams.md)

  • L160 in content/docs/administration/guides/scim/troubleshooting.md "- SCIM overview" → ✅ verified (evidence: content/docs/administration/guides/scim/_index.md exists and renders at the URL path /docs/administration/guides/scim/, matching the link text "SCIM overview" pointing to that page.; source: repo:content/docs/administration/guides/scim/_index.md)

  • L5 in content/docs/administration/reference/_index.md "This reference section provides lookup material for administering Pulumi Cloud, including the complete catalog of RBAC scopes and the Pulumi Cloud REST API." (also L16) → ✅ verified (evidence: The _index.md file itself states "Lookup material for administering Pulumi Cloud — the complete catalog of RBAC scopes and the Pulumi Cloud REST API" and links to /docs/administration/reference/rbac-scopes/, whose own index confirms…; source: repo:content/docs/administration/reference/_index.md, repo:content/docs/administration/reference/rbac-scopes/_index.md)

  • L18 in content/docs/administration/reference/_index.md "The Pulumi Cloud REST API provides endpoints for organizations, teams, access tokens, stacks, and environments." → ✅ verified (framing: The API surface covers many more categories (policy-groups, deployments, registry, audit-logs, etc.); the claim's list of five is a subset of the full…; evidence: The Pulumi Cloud REST API reference (content/docs/reference/cloud-rest-api/) is generated from the live OpenAPI spec and organized into tag-intro categories that include organizations, teams (per organizations.md: "The Organizations API…; source: gh search code --owner pulumi repo:pulumi/docs path:assets/openapi/tag-intros (organizations.md, access-tokens.md, environments.md))

  • L5 in content/docs/administration/reference/rbac-scopes/_index.md "This page provides the complete catalog of Pulumi Cloud RBAC scopes for stacks, environments, cloud accounts, and organization settings." → ➖ not-a-claim (evidence: The page's own meta_desc reads "The complete catalog of Pulumi Cloud RBAC scopes for stacks, environments, cloud accounts, and organization settings" and its body lists exactly those four sections (Stacks, Environments, Cloud accounts…; source: repo:content/docs/administration/reference/rbac-scopes/_index.md)

  • L12 in content/docs/administration/reference/rbac-scopes/_index.md "This RBAC scopes documentation page is gated behind or associated with a Pulumi Cloud feature flag/identifier named 'rbac'." → ✅ verified (evidence: The page's frontmatter contains pulumi_cloud_feature: rbac, which is the documented mechanism (per AGENTS.md: "add pulumi_cloud_feature: <feature-id> to the front matter (for example pulumi_cloud_feature: rbac)") for gating a page…; source: repo:content/docs/administration/reference/rbac-scopes/_index.md, repo:AGENTS.md, repo:data/pulumi_pricing.yaml)

  • L15 in content/docs/administration/reference/rbac-scopes/_index.md "A permission set can grant permissions, and the granted permissions are scoped by the entity they apply to (stacks, environments, cloud accounts, or…" → ✅ verified (evidence: Pulumi docs source (content/docs/administration/access-identity/rbac/permission-sets.md, the current-live version of the page the claim links to as concepts/rbac/permission-sets/) states permission sets "provide a convenient way to grant…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/rbac/permission-sets.md)

  • L17-20 in content/docs/administration/reference/rbac-scopes/_index.md "There is a Pulumi Cloud RBAC scopes reference page for 'Organization settings' at /docs/administration/reference/rbac-scopes/org-settings/." → ✅ verified (evidence: The _index.md at content/docs/administration/reference/rbac-scopes/_index.md lists "- Organization settings" alongside Stacks, Environments, and Cloud accounts. PR Administration IA phase 1: re-shelve the SaaS side into get-started / concepts / guides / reference #21056 (same…; source: gh pr diff 21056 -R pulumi/docs (rename ... rbac-scopes}/org-settings.md); repo:content/docs/administration/reference/rbac-scopes/_index.md)

  • L16 in content/docs/administration/reference/rbac-scopes/environments.md "- /docs/administration/access-identity/rbac/scopes/environments/" → ➖ not-a-claim (evidence: The line is part of the aliases front-matter list used for redirects to this page; it's metadata, not a falsifiable assertion about content.; source: repo:content/docs/administration/reference/rbac-scopes/environments.md)

  • L20 in content/docs/administration/reference/rbac-scopes/environments.md "This document defines all the available scopes in Pulumi Cloud assignable to specific environments or sets of…" → ✅ verified (evidence: The linked page at /docs/administration/concepts/rbac/scopes/ exists (content/docs/administration/concepts/rbac/scopes.md) and states "Scopes are the most granular level of access control in Pulumi Cloud's RBAC system," listing…; source: repo:content/docs/administration/concepts/rbac/scopes.md)

  • L22 in content/docs/administration/reference/rbac-scopes/environments.md "Note that creating, listing, or restoring environments are organization-level operations, and these scopes can be found in the [organization settings…" → ✅ verified (evidence: org-settings.md's Environments section lists environment:create, environment:list_deleted, and environment:restore_deleted as organization-level scopes ("Create a new environment...", "View a list of environments that have been…; source: repo:content/docs/administration/reference/rbac-scopes/org-settings.md)

  • L16 in content/docs/administration/reference/rbac-scopes/insights-accounts.md "- /docs/administration/access-identity/rbac/scopes/insights-accounts/" → ➖ not-a-claim (evidence: This is a front-matter aliases entry for redirect purposes, not a falsifiable assertion. It reflects a legitimate prior path structure — another file in the repo (entities.md) links to…; source: repo:content/docs/administration/access-identity/rbac/entities.md (gh search code --owner pulumi))

  • L20 in content/docs/administration/reference/rbac-scopes/insights-accounts.md "This document defines all the available scopes in Pulumi Cloud assignable to specific cloud accounts or sets of…" → ✅ verified (evidence: The target page content/docs/administration/concepts/rbac/scopes.md exists, defines "scopes" as "the most granular level of access control in Pulumi Cloud's RBAC system," and lists "Cloud accounts" under "Available…; source: repo:content/docs/administration/concepts/rbac/scopes.md)

  • L22 in content/docs/administration/reference/rbac-scopes/insights-accounts.md "Note that creating, listing, or restoring cloud accounts are organization-level operations, and these scopes can be found in the [organization settings…" → 🌀 framing-drift (framing: source only documents insights_account:create under org-settings "Cloud accounts"; claim asserts three operations (create/list/restore) live there, but…; evidence: org-settings.md has a "Cloud accounts" section confirming insights_account:create is an org-level scope (granted by Admin), validating the link and the "creating" part of the claim. However, that section only lists a :create scope …; source: content/docs/administration/reference/rbac-scopes/org-settings.md)

  • L16 in content/docs/administration/reference/rbac-scopes/org-settings.md "- /docs/administration/access-identity/rbac/scopes/org-settings/" → ➖ not-a-claim (evidence: The line - /docs/administration/access-identity/rbac/scopes/org-settings/ is an entry in the page's front-matter aliases: list (a redirect path), not a falsifiable assertion. Confirmed it is present verbatim in the file at that…; source: repo:content/docs/administration/reference/rbac-scopes/org-settings.md)

  • L20 in content/docs/administration/reference/rbac-scopes/org-settings.md "This document defines all the available scopes in Pulumi Cloud, organized by entity type and group." → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/entities.md contains a "## Entity types" section (line 21) describing the three entity types (Stacks, Environments, Cloud accounts), which matches the anchor #entity-types…; source: repo:content/docs/administration/concepts/rbac/entities.md)

  • L16 in content/docs/administration/reference/rbac-scopes/stacks.md "- /docs/administration/access-identity/rbac/scopes/stacks/" → ➖ not-a-claim (evidence: This is a frontmatter aliases entry providing a redirect from the file's former path (content/docs/administration/access-identity/rbac/scopes/stacks.md, confirmed to exist historically via repo search) to its current location. It's…; source: gh search code --owner pulumi "access-identity/rbac/scopes" --repo pulumi/docs)

  • L20 in content/docs/administration/reference/rbac-scopes/stacks.md "This document defines all the available scopes in Pulumi Cloud assignable to specific stacks or sets of stacks." → ✅ verified (evidence: The target page content/docs/administration/concepts/rbac/scopes.md exists at the linked path and defines "Scopes are the most granular level of access control in Pulumi Cloud's RBAC system," linking to the Stacks scopes page as one of…; source: repo:content/docs/administration/concepts/rbac/scopes.md)

  • L22 in content/docs/administration/reference/rbac-scopes/stacks.md "Note that creating, listing, or restoring stacks are organization-level operations, and these scopes can be found in the [organization settings…" → ✅ verified (evidence: org-settings.md contains a "## Stacks" section (lines 199-206) with stack:create, stack:list_deleted, and stack:restore_deleted scopes, exactly matching the claim that creating, listing, and restoring stacks are org-level scopes…; source: repo:content/docs/administration/reference/rbac-scopes/org-settings.md)

  • L102 in content/docs/administration/self-hosting/airgapped.md "* For more detailed organization configuration options, refer to this onboarding guide." → ✅ verified (evidence: The file content/docs/administration/get-started/_index.md exists at the linked path and is titled "Get Started with Pulumi Cloud," covering onboarding, setup, and organization configuration/adoption guidance — matching the link text…; source: repo:content/docs/administration/get-started/_index.md)

  • L81 in content/docs/administration/self-hosting/saml-sso.md "Once your self-hosted infrastructure is configured, complete the SAML SSO setup by configuring your identity provider and Pulumi organization using the…" → ✅ verified (evidence: The target page /docs/administration/guides/saml/ exists and is exactly the SAML SSO IdP configuration guide index, which itself notes "Running self-hosted Pulumi Cloud? You'll first need to configure your self-hosted infrastructure for…; source: repo:content/docs/administration/guides/saml/_index.md)

  • L25 in content/docs/ai/_index.md "Pulumi is built to be driven by AI agents, including the coding agents your team already uses. Because Pulumi infrastructure is real code with a verifiable…" → ✅ verified (evidence: The linked page content/docs/ai/cli-for-agents/index.md exists on the pulumi/docs master branch, confirming the /docs/ai/cli-for-agents/ target referenced in the claim's text is a real, live doc page (not a broken/future link)…; source: gh api repos/pulumi/docs/contents/content/docs/ai/cli-for-agents (index.md present on master))

  • L46 in content/docs/ai/_index.md "link: /docs/administration/concepts/agent-accounts/" → ❌ contradicted (evidence: The agent-accounts page actually lives at content/docs/administration/organizations-teams/agent-accounts.md (confirmed via repo contents listing), which resolves to the URL /docs/administration/organizations-teams/agent-accounts/. There…; source: gh api repos/pulumi/docs/contents/content/docs/administration/organizations-teams (lists agent-accounts.md); gh search code repo:pulumi/docs agent-accounts)


  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor
continued from previous comment
  • L63 in content/docs/ai/cli-for-agents/index.md "An agent that runs the CLI still needs somewhere to store state. Agent accounts remove that friction: when…" → ✅ verified (evidence: The target page content/docs/administration/concepts/agent-accounts/index.md exists and states: "When the Pulumi CLI detects it is running in an agent context and no Pulumi Cloud credentials are available, it creates an account…; source: repo:content/docs/administration/concepts/agent-accounts/index.md)
  • L69 in content/docs/ai/cli-for-agents/index.md "- Agent accounts — ephemeral Pulumi Cloud accounts provisioned automatically for agents." → ❌ contradicted (framing: Same anchor page/content, but claim cites wrong URL segment ('concepts' vs actual 'organizations-teams') — a broken/incorrect link.; evidence: The claim's link target /docs/administration/concepts/agent-accounts/ does not exist. The actual page lives at content/docs/administration/organizations-teams/agent-accounts.md, and the corresponding live line in…; source: gh api repos/pulumi/docs/contents/content/docs/administration/organizations-teams (agent-accounts.md found there); gh search code --owner pulumi "agent-accounts")
  • L430 in content/docs/ai/mcp-server/index.md "- Agent accounts - ephemeral Pulumi Cloud accounts provisioned automatically for agents" → ❌ contradicted (evidence: The linked path /docs/administration/concepts/agent-accounts/ does not exist in the pulumi/docs repo (404 on both content/docs/administration/concepts/agent-accounts and its listing). The actual agent-accounts page lives at…; source: gh api repos/pulumi/docs/contents/content/docs/administration/organizations-teams (agent-accounts.md present); gh api repos/pulumi/docs/contents/content/docs/administration/concepts/agent-accounts → 404)
  • L43 in content/docs/ai/neo/automations/_index.md "A scheduled task runs with the RBAC permissions of the user who scheduled it, evaluated at execution time. If that…" → ✅ verified (framing: RBAC page describes general permission accumulation model; claim narrows this to the specific case of scheduled task execution, which is a reasonable…; evidence: The linked RBAC page (/docs/administration/concepts/rbac/) exists and confirms the underlying model: "A user's effective permissions are the union of every grant that applies to them" via user role, team roles, and creator grants. The…; source: content/docs/administration/concepts/rbac/_index.md)
  • L34 in content/docs/ai/neo/code-reviews/_index.md "Neo matches your GitHub identity to your Pulumi user. If you signed in to Pulumi with GitHub, that link already exists; otherwise, [link a GitHub identity to…" → ❌ contradicted (evidence: The linked path in the claim, /docs/administration/concepts/accounts/#adding-new-identities, does not exist. The actual page with that anchor lives at /docs/administration/organizations-teams/accounts/#adding-new-identities (confirmed…; source: gh api repos/pulumi/docs/contents/content/docs/administration/organizations-teams/accounts.md; gh search code --owner pulumi adding-new-identities)
  • L49 in content/docs/ai/neo/code-reviews/_index.md "Neo code reviews run with the same governance as any other Neo task, including the [role-based access…" → ✅ verified (framing: Tasks page documents RBAC/permission enforcement generally for Neo tasks; code-reviews page's claim that reviews (a type of Neo task) inherit the same…; evidence: The linked page content/docs/ai/neo/tasks/_index.md exists and describes Neo task governance, including RBAC enforcement ("Links to stacks or resources within the shared task still enforce the viewer's existing RBAC permissions") and…; source: repo:content/docs/ai/neo/tasks/_index.md)
  • L82 in content/docs/ai/neo/editors/_index.md "An editor session uses your existing pulumi login and the RBAC permissions of your Pulumi user. Identity, RBAC, and…" → ✅ verified (framing: RBAC page describes the general permission model for Pulumi Cloud principals; claim narrows this to "an editor session" using the same login/RBAC — a…; evidence: The linked RBAC page confirms Pulumi Cloud RBAC governs "who can access which resources in your organization and what actions they can take," assigned to "users, teams, and machine tokens" via their Pulumi Cloud identity — consistent…; source: content/docs/administration/concepts/rbac/_index.md)
  • L36 in content/docs/ai/neo/get-started/_index.md "Neo operates within the conversing user's RBAC entitlements and cannot perform actions that the user couldn't perform…" → ✅ verified (evidence: The RBAC page at /docs/administration/concepts/rbac/ defines Pulumi Cloud's RBAC entitlement model, and the sibling Neo permissions page states the identical claim: "Neo operates within the acting user's role-based access control (RBAC)…; source: repo:content/docs/administration/concepts/rbac/_index.md, repo:content/docs/ai/neo/permissions/_index.md)
  • L47 in content/docs/ai/neo/integrations/slack/_index.md "Tasks started from Slack run with the RBAC permissions of the Pulumi Cloud user linked to your Slack identity." → ✅ verified (framing: RBAC page defines general permission model for Pulumi Cloud users; claim is a narrower application (Neo Slack tasks use the linked user's permissions)…; evidence: The RBAC page at /docs/administration/concepts/rbac/ exists and describes how a Pulumi Cloud user's effective permissions (role, team grants, etc.) are computed; it's a valid, on-topic link for the claim that Slack-initiated Neo tasks…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L20 in content/docs/ai/neo/permissions/_index.md "- Neo operates within the acting user's role-based access control (RBAC) entitlements and cannot perform actions that…" → ✅ verified (evidence: The cited target /docs/administration/concepts/rbac/ exists and correctly describes Pulumi Cloud's RBAC system ("Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what…; source: repo:content/docs/administration/concepts/rbac/_index.md and repo:content/docs/ai/neo/permissions/_index.md)
  • L27 in content/docs/ai/neo/permissions/_index.md "Neo has no identity of its own: by default a task carries the acting user's full set of role assignments. On…" → ✅ verified (framing: Source establishes RBAC roles and edition-gating pattern generally; claim narrows this to Neo's per-task role assumption specifically, which is consistent…; evidence: The linked RBAC page confirms roles are the unit of assignment ("Each organization member has exactly one organization role...or a custom role") and that custom/advanced RBAC features are Enterprise/Business Critical gated: "Pulumi…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L62 in content/docs/ai/neo/permissions/_index.md "Neo inherits the acting user's ESC access. If the user can open an environment (the environment:open permission), so…" → ✅ verified (framing: Source describes RBAC scopes generally (object:action pattern, environment entities); claim names the specific environment:open scope as a special case of…; evidence: The cited link /docs/administration/concepts/rbac/ resolves to the real RBAC concepts page, which explains that access in Pulumi Cloud is granted via granular scopes following an object:action naming pattern (the sibling scopes page…; source: repo:content/docs/administration/concepts/rbac/_index.md and repo:content/docs/administration/concepts/rbac/scopes.md)
  • L135-136 in content/docs/ai/neo/permissions/_index.md "- Least-privilege access — scoping down what a user, and so Neo, can do" → ❌ contradicted (evidence: The least-privilege guide actually lives at /docs/administration/security-compliance/least-privilege/ (confirmed via GitHub API: content/docs/administration/security-compliance/least-privilege/_index.md exists on pulumi/docs master…; source: gh api repos/pulumi/docs/contents/content/docs/administration/security-compliance/least-privilege/_index.md; gh search code --repo pulumi/docs least-privilege)
  • L42 in content/docs/ai/neo/pulumi-cli/_index.md "pulumi neo uses your existing pulumi login and the RBAC permissions of your Pulumi user. Identity, RBAC, and audit…" → ✅ verified (framing: RBAC page describes the general Pulumi Cloud identity/permission model; claim states pulumi neo (a CLI client authenticated via pulumi login) uses this same…; evidence: The linked RBAC page confirms Pulumi Cloud's RBAC system governs user/team/token permissions tied to Pulumi Cloud identity: "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization…; source: content/docs/administration/concepts/rbac/_index.md)
  • L90 in content/docs/ai/neo/tasks/_index.md "- Links to stacks or resources within the shared task still enforce the viewer's existing RBAC permissions" → ✅ verified (framing: RBAC page describes general resource-access enforcement in Pulumi Cloud; claim applies this to the specific case of links surfaced within a shared Neo task…; evidence: The RBAC page at /docs/administration/concepts/rbac/ exists and confirms: "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take," with access built…; source: content/docs/administration/concepts/rbac/_index.md)
  • L73 in content/docs/ai/neo/usage-limits/_index.md "- Billing managers — grant billing access without full admin rights" → ❌ contradicted (evidence: The Billing managers page actually lives at content/docs/administration/organizations-teams/billing-managers.md, whose front matter aliases are only /docs/pulumi-cloud/access-management/billing-managers/…; source: gh api repos/pulumi/docs/contents/content/docs/administration/organizations-teams/billing-managers.md (canonical path: content/docs/administration/organizations-teams/billing-managers.md); intuition: Link path uses "concepts" segment which doesn't exist as a subdirectory for this page; the real page sits under…)
  • L222 in content/docs/ai/skills/index.md "- Agent accounts - ephemeral Pulumi Cloud accounts provisioned automatically for agents" → ⚔️ mismatch (evidence: The link in content/docs/ai/skills/index.md points to /docs/administration/concepts/agent-accounts/, but every sibling reference in the same repo (content/docs/ai/cli-for-agents/index.md, content/docs/ai/mcp-server/index.md…; source: gh search code --owner pulumi "agent-accounts" (pulumi/docs repo, multiple files))
  • L35 in content/docs/deployments/concepts/settings/runner-pools.md "Organization roles are managed through the Roles section. For more information on creating and managing roles, see the [Roles…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/roles.md exists and covers exactly what the claim describes: "A role in Pulumi Cloud is the primary way to define what resources a principal ... can access" plus sections on…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L80 in content/docs/deployments/guides/customer-managed-workflow-runners.md "It is possible to use OpenID authentication to fetch Pulumi Pool tokens dynamically instead of configuring a static token for the workflow runners. You must…" → ✅ verified (evidence: The target page content/docs/administration/guides/oidc-issuers/_index.md exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... you register that external service as a trusted OIDC…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L84-85 in content/docs/deployments/guides/customer-managed-workflow-runners.md "- Configuring OpenID Connect for Google Kubernetes Engine" → ❌ contradicted (evidence: The repo's actual file lives at content/docs/administration/access-identity/oidc-issuers/kubernetes-gke.md (confirmed via GitHub API directory listing), not content/docs/administration/guides/oidc-issuers/kubernetes-gke/. Other docs…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/oidc-issuers)
  • L35 in content/docs/deployments/guides/oidc/_index.md "Pulumi Cloud can also accept OIDC tokens from trusted third-party identity providers and exchange them for short-lived Pulumi access tokens. This is a…" → ✅ verified (evidence: The linked page content/docs/administration/guides/oidc-issuers/_index.md exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L40 in content/docs/deployments/operations/permissions.md "The recommended approach for granting additional permissions to deployments is through role assignment. To assign a role to a deployment, navigate to your…" → ✅ verified (framing: The roles page broadly documents role assignment to principals (tokens, users, teams); the claim narrows this to deployment stack tokens inheriting role…; evidence: The linked page content/docs/administration/concepts/rbac/roles.md exists at the cited path and covers exactly what the claim's link text promises ("Organization roles are managed through the Roles section"): it explains roles, how…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L19 in content/docs/esc/administration/_index.md "- Pulumi Cloud organizations: Set up and manage organizations for team collaboration and secrets and…" → ✅ verified (evidence: The sibling page content/docs/administration/concepts/_index.md lists "Organizations — the top-level container that owns your stacks, environments, and settings," confirming the linked path…; source: repo:content/docs/administration/concepts/_index.md)
  • L20-21 in content/docs/esc/administration/_index.md "- Teams and Role-based access control (RBAC): Manage permissions at the organization and environment levels." → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/teams.md exists, titled "Teams", and covers RBAC via teams including org-level role assignments ("teams can be assigned roles... members receive the union of the team's roles and…; source: repo:content/docs/administration/concepts/rbac/teams.md)
  • L25 in content/docs/esc/administration/_index.md "- Access control: Manage environment permissions with role-based access controls at the…" → ❌ contradicted (evidence: The linked path /docs/administration/reference/rbac-scopes/environments/ does not exist in the pulumi/docs repo. The actual RBAC scopes-environments page lives at content/docs/administration/access-identity/rbac/scopes/environments.md…; source: gh search code --owner pulumi "rbac-scopes"; gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/rbac/scopes/environments.md; intuition: Link path segment "reference/rbac-scopes" doesn't match the actual content directory structure…)
  • L26 in content/docs/esc/administration/_index.md "- OpenID Connect (OIDC): Integrate with trusted third-party identity providers to authenticate users." → ✅ verified (evidence: The linked page /docs/administration/guides/oidc-issuers/ exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... register that external service as a trusted OIDC Issuer in Pulumi…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L27-28 in content/docs/esc/administration/_index.md "- SAML single sign-on (SSO): Configure SAML-based authentication for centralized access management." → ✅ verified (evidence: The target page content/docs/administration/guides/saml/_index.md exists and states: "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider," with sections on SSO configuration and integration guides — matching…; source: repo:content/docs/administration/guides/saml/_index.md)
  • L15 in content/docs/esc/administration/audit-logs.md "For comprehensive audit log documentation including how to view, filter, and export logs, see Audit Logs in the…" → ✅ verified (evidence: The target page content/docs/administration/concepts/audit-logs.md exists at that exact path and contains "View audit logs", "Automated export", and "Manual export" sections covering viewing, filtering, and exporting audit logs, matching…; source: repo:content/docs/administration/concepts/audit-logs.md)
  • L66 in content/docs/esc/administration/audit-logs.md "For a full list of Pulumi Cloud audit log events see the Pulumi Cloud audit logs documentation." → ✅ verified (evidence: The file content/docs/administration/concepts/audit-logs.md exists at the exact path /docs/administration/concepts/audit-logs/ (matches its menu/URL structure) and contains a "## List of audit log events" section with a full events…; source: repo:content/docs/administration/concepts/audit-logs.md)
  • L70 in content/docs/esc/administration/audit-logs.md "Pulumi ESC leverages the same audit log infrastructure as the Pulumi Cloud platform. For detailed information on exporting, and managing audit logs, see the…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/audit-logs.md exists in the repo and contains detailed sections on "Automated export" (S3, Microsoft Sentinel), "Manual export" (console, API), and "Supported audit log formats" …; source: repo:content/docs/administration/concepts/audit-logs.md)
  • L24 in content/docs/esc/concepts/_index.md "- Reach third-party secrets without sharing access directly. Rather than granting every user and pipeline direct access to systems like AWS Secrets…" → ✅ verified (evidence: The linked page /docs/administration/concepts/rbac/ exists and states: "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take," and environments…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L37 in content/docs/esc/concepts/_index.md "Environments are evaluated when they are opened, not when they are defined. When a client opens an environment, Pulumi Cloud authenticates the request…" → ✅ verified (evidence: The linked page /docs/administration/concepts/rbac/ exists and confirms: "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take," supporting the claim…; source: content/docs/administration/concepts/rbac/_index.md)
  • L91 in content/docs/esc/concepts/_index.md "- Access control, audit logs, and [customer-managed…" → ✅ verified (evidence: The target page /docs/administration/concepts/rbac/_index.md exists and describes "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take," consistent…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L46 in content/docs/esc/concepts/customer-managed-keys.md "See the Customer Managed Keys documentation for complete usage" → ✅ verified (evidence: content/docs/administration/concepts/customer-managed-keys.md exists at the linked path and contains full usage instructions for viewing, adding, and disabling Customer Managed Keys, matching the claim's description.; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L178 in content/docs/esc/concepts/environments.md "Access to environments is governed by Pulumi Cloud's role-based access control. Permissions are granted through roles and reusable permission sets — the…" → ✅ verified (evidence: The RBAC permission-sets doc lists the exact four built-in Environment permission sets: "Environment Read... Environment Open... Ability to read the environment and access environment secrets... Environment Write... Environment Admin |…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L27 in content/docs/esc/guides/environment-composition-patterns.md "Access is granted per environment through RBAC, so this decomposition is what makes…" → ✅ verified (evidence: The RBAC scopes reference page confirms scopes like environment:read, environment:write, environment:rotate are assignable "to specific environments or sets of environments," meaning access is granted per environment — directly…; source: repo:content/docs/administration/reference/rbac-scopes/environments.md)
  • L172 in content/docs/esc/guides/environment-composition-patterns.md "- Environment RBAC - Granting access per environment" → ❌ contradicted (framing: Claim links to a nonexistent path segment structure (reference/rbac-scopes/) while the real content lives under access-identity/rbac/scopes/ — same…; evidence: The pulumi/docs repo has no content/docs/administration/reference/ directory at all. The real page about environment RBAC scopes lives at content/docs/administration/access-identity/rbac/scopes/environments.md, which maps to…; source: gh api repos/pulumi/docs/contents/content/docs/administration (and subsequent listing of access-identity/rbac/scopes))
  • L33 in content/docs/esc/guides/integrate-with/github-actions.md "Before you can use OIDC, you must configure Pulumi Cloud to trust GitHub Actions as an OIDC issuer. Follow the [Configuring OpenID Connect for…" → ❌ contradicted (evidence: The actual OIDC GitHub guide lives at content/docs/administration/access-identity/oidc-issuers/github.md (title "Configuring OpenID Connect for GitHub"), with declared aliases /docs/administration/access-identity/oidc-client/github/…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/oidc-issuers/github.md; gh search code --owner pulumi "administration/guides/oidc-issuers")
  • L53 in content/docs/esc/guides/integrate-with/github-actions.md "The id-token: write permission is required for GitHub Actions to issue OIDC tokens to your workflow. The requested-token-type value determines the scope…" → ✅ verified (evidence: The linked page contains a "## Token types by edition" section stating: "The available OIDC token types vary by Pulumi edition: Individual: personal; Team: personal, organization; Enterprise: personal, organization, team; Business…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L57 in content/docs/esc/guides/integrate-with/github-actions.md "As an alternative to OIDC, you can authenticate with a long-lived Pulumi access token. Store the token as a…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/access-tokens.md confirms Pulumi access tokens are long-lived credentials ("Tokens can optionally be assigned an expiration period of up to two years... Expired tokens cannot be…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L27 in content/docs/esc/integrations/kubernetes/external-secrets-operator.md "Pulumi Access Tokens are recommended to access Pulumi ESC." → ✅ verified (evidence: The linked page /docs/administration/concepts/access-tokens/ exists and documents Pulumi Cloud access tokens ("Use access tokens to sign into the Pulumi Cloud via the CLI or automate your usage of the Pulumi Cloud using the REST API")…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L27 in content/docs/esc/integrations/kubernetes/secret-store-csi-driver.md "Pulumi Access Tokens are recommended to access Pulumi ESC." → ✅ verified (evidence: The linked page /docs/administration/concepts/access-tokens/ exists and describes Pulumi Cloud access tokens ("Use access tokens to sign into the Pulumi Cloud via the CLI or automate your usage of the Pulumi Cloud using the REST API")…; source: content/docs/administration/concepts/access-tokens.md; content/docs/esc/integrations/kubernetes/secret-store-csi-driver.md)
  • L37 in content/docs/esc/operations/rotation/aws-lambda.md "The first one is the managing credentials environment, containing managing user credentials for your database and the [OIDC AWS…" → ✅ verified (framing: The claim links "OIDC AWS login" to the aws-login provider page, which is the correct target and matches the linked resource's purpose.; evidence: The cited URL resolves (HTTP 200) to the Pulumi ESC "aws-login" provider documentation page, which matches the claim's reference to "OIDC AWS login" as a provider used within an ESC environment for AWS credential/OIDC configuration.; source: https://www.pulumi.com/docs/esc/providers/login/aws-login/)
  • L117 in content/docs/iac/_index.md "link: /docs/administration/guides/least-privilege/" → ❌ contradicted (evidence: The repo (pulumi/docs, master) has no content/docs/administration/guides directory (404 via API) — the actual Least Privilege page lives at content/docs/administration/security-compliance/least-privilege/_index.md, i.e. path…; source: gh api repos/pulumi/docs/contents/content/docs/administration/security-compliance (found least-privilege dir); gh api repos/pulumi/docs/contents/content/docs/administration/guides (404 Not Found))
  • L29 in content/docs/iac/cli/api.md "pulumi api uses the same access token as the rest of the Pulumi CLI. Anything that authorizes pulumi login — a personal, organization, or team [access…" → ✅ verified (evidence: The access-tokens page states "The token you use for pulumi login also authorizes the pulumi api command, which calls any REST API endpoint directly from the CLI without needing to set the Authorization header yourself," and…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L188 in content/docs/iac/cli/api.md "* Pulumi Cloud access tokens" → ✅ verified (evidence: The linked page exists at content/docs/administration/concepts/access-tokens.md with h1 "Pulumi Cloud access tokens" (matching the link text) and even reciprocally links back to /docs/iac/cli/api/: "The token you use for pulumi login…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L54 in content/docs/iac/comparisons/spacelift.md "| Access control | Pulumi Cloud teams and role-based access control, SAML/SSO, and [audit…" → ✅ verified (evidence: The linked /docs/iac/concepts/pulumi-cloud/ page (content/docs/iac/concepts/pulumi-cloud.md) explicitly lists "Role-based access control with SAML/SSO integration and fine-grained access tokens for automation" as a Pulumi Cloud…; source: repo:content/docs/iac/concepts/pulumi-cloud.md and repo:content/docs/administration/concepts/audit-logs.md)
  • L40 in content/docs/iac/comparisons/terraform-cloud.md "* Govern them with tag-based access control and team and user role assignments." → ✅ verified (evidence: The linked page /docs/administration/concepts/rbac/ describes RBAC built on scopes, permission sets, roles, and teams, explicitly noting roles "may be applied to all entities of that type, explicitly selected entities, or they can be…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L132 in content/docs/iac/comparisons/terraform/opentofu.md "Pulumi offers audit logs that allow you to monitor user activity within an organization. These logs record the UNIX timestamp of each event, the user who…" → ✅ verified (evidence: The audit-logs docs page states: "Pulumi's audit logs allow you to account for the activity your users are taking within your organization. The logs are immutable and record all user actions... The logs capture the UNIX timestamp of the…; source: repo:content/docs/administration/concepts/audit-logs.md)
  • L19 in content/docs/iac/concepts/pulumi-cloud.md "- Role-based access control with SAML/SSO integration and fine-grained [access…" → ✅ verified (evidence: Both linked pages exist and match their descriptions: /docs/administration/concepts/rbac/teams/ documents "role-based access control (RBAC) using teams" with role assignments (relevant to SAML/SSO-integrated RBAC), and…; source: repo:content/docs/administration/concepts/rbac/teams.md, repo:content/docs/administration/concepts/access-tokens.md)
  • L34 in content/docs/iac/concepts/pulumi-cloud.md "An organization is the top-level account in Pulumi Cloud that groups related projects, stacks, and people. It is the primary unit of collaboration…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/teams.md exists in the repo and is titled "Teams", describing "The Pulumi Cloud offers role-based access control (RBAC) using teams. Teams allow organization admins to assign a…; source: repo:content/docs/administration/concepts/rbac/teams.md)
  • L766 in content/docs/iac/concepts/secrets/_index.md "Decrypting this ciphertext requires the encryption key that was used to create it. For stacks managed with Pulumi Cloud, these keys are obtained…" → ✅ verified (evidence: The target page content/docs/administration/concepts/rbac/permission-sets.md has a real "### Stack permission sets" section (anchor #stack-permission-sets), listing Stack Read as including stack:read, stack:encrypt, stack:decrypt…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L108 in content/docs/iac/concepts/state-and-backends.md "This will display a prompt that asks for an access token:" → ✅ verified (evidence: The linked page content/docs/administration/concepts/access-tokens.md exists and is titled "Pulumi Cloud access tokens", matching the URL /docs/administration/concepts/access-tokens/ and describing the access token prompted for during…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L26 in content/docs/iac/get-started/terraform/terraform-state-backend.md "- Role-based access control — control who can read or modify each stack with teams and RBAC" → ✅ verified (evidence: The linked page /docs/administration/concepts/rbac/ exists and states "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take," and covers Teams as a…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L23 in content/docs/iac/guides/basics/organizing-projects-stacks/_index.md "unit of deployment with its own configuration, secrets, role-based access controls (RBAC), policies, and concurrent…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/_index.md exists and confirms: "Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take,"…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L41 in content/docs/iac/guides/basics/organizing-projects-stacks/_index.md "team boundaries lets you use stack permissions to give each team exactly the" → ✅ verified (evidence: The actual file content (decoded from repo) links to /docs/administration/access-identity/rbac/permission-sets/, which is a real, existing page (content/docs/administration/access-identity/rbac/permission-sets.md) consistently…; source: gh api repos/pulumi/docs/contents/content/docs/iac/guides/basics/organizing-projects-stacks/_index.md (decoded content) + gh search code confirming permission-sets.md exists at content/docs/administration/access-identity/rbac/permission-sets.md)
  • L724 in content/docs/iac/guides/basics/organizing-projects-stacks/_index.md "* Security. Stack permissions let you grant service teams read-only access" → ✅ verified (evidence: The linked page content/docs/administration/concepts/rbac/permission-sets.md exists at the exact URL cited and documents Stack Read: "Basic read-only access to stacks. Allows for running previews," confirming stack permission sets can…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L909 in content/docs/iac/guides/basics/organizing-projects-stacks/_index.md "tag-based (ABAC) rules in Pulumi Cloud RBAC, so" → ❌ contradicted (evidence: The actual RBAC roles doc with the tag-based ABAC anchor lives at content/docs/administration/access-identity/rbac/roles.md ("##### Tag-based rules (ABAC) {#tag-based-abac-rules}"), and other pages link to it as…; source: gh search code --owner pulumi "tag-based-abac-rules" (pulumi/docs:content/docs/administration/access-identity/rbac/roles.md))
  • L66 in content/docs/iac/guides/basics/pulumi-cloud-vs-oss.md "Pulumi Cloud provides a role-based access control model expressed in terms of Pulumi concepts and…" → ❌ contradicted (evidence: The repo has no content/docs/administration/concepts/ directory at all (subdirs under administration/ are access-identity, onboarding-guide, organizations-teams, security-compliance, self-hosting). The master-branch version of this…; source: gh api repos/pulumi/docs/contents/content/docs/administration (dir listing); gh search code repo:pulumi/docs "SAML/SSO" "teams" (shows master branch text linking to /docs/administration/organizations-teams/teams/); intuition: Link path /docs/administration/concepts/rbac/teams/ looks like a broken/renamed slug — repo has no "concepts" subdir…)
  • L18 in content/docs/iac/guides/building-extending/automation-api-advanced.md "The examples below assume the same setup as the getting-started guide: the Pulumi CLI on your PATH (or [installed…" → ✅ verified (evidence: Both linked targets exist: /docs/install/ is the live Download & Install Pulumi page, and automation-api.md contains a ### Install the CLI programmatically section (line 33) matching the anchor #install-the-cli-programmatically…; source: repo:content/docs/install/_index.md; repo:content/docs/iac/guides/building-extending/automation-api.md)
  • L30 in content/docs/iac/guides/building-extending/automation-api.md "- A Pulumi access token so your program can store state in Pulumi Cloud. Run pulumi login to authenticate…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/access-tokens.md exists at the /docs/administration/concepts/access-tokens/ URL and states: "Use access tokens to sign into the Pulumi Cloud via the CLI or automate your usage of the…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L32 in content/docs/iac/operations/_index.md "Least privilege - Apply least-privilege security across your Pulumi platform: cloud provider credentials…" → ❌ contradicted (evidence: The live pulumi/docs repo has no content/docs/administration/guides/ directory at all (404), and the actual least-privilege page lives at content/docs/administration/security-compliance/least-privilege/_index.md. The upstream repo's…; source: gh search code repo:pulumi/docs least-privilege; gh api repos/pulumi/docs/contents/content/docs/administration/guides (404))
  • L55 in content/docs/iac/operations/continuous-delivery/_index.md "Your pipeline needs a single Pulumi access token to authenticate with Pulumi Cloud." → ❌ contradicted (evidence: The actual access-tokens page lives at content/docs/administration/access-identity/access-tokens.md (title "Access tokens", menu parent "administration-access-identity"), and its aliases list only includes paths like…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/access-tokens.md (frontmatter aliases); gh api repos/pulumi/docs/contents/content/docs/administration (no 'concepts' subdirectory))
  • L57 in content/docs/iac/operations/continuous-delivery/_index.md "You can remove even that static secret with OpenID Connect (OIDC): the pipeline exchanges the OIDC token issued…" → ✅ verified (evidence: The linked OIDC Issuers page states: "Instead of provisioning a long-lived Pulumi access token and storing it as a secret in your CI system, build runner, or Kubernetes cluster, you register that external service as a trusted OIDC Issuer…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L66 in content/docs/iac/operations/continuous-delivery/argocd.md "The recommended way to give the cluster its Pulumi Cloud identity is OpenID Connect (OIDC). Register the Kubernetes cluster as a Pulumi Cloud [OIDC…" → ✅ verified (evidence: The linked /docs/administration/guides/oidc-issuers/ page confirms OIDC Issuers are exactly the mechanism described: "Any third-party service that can issue OIDC id_tokens — GitHub Actions, GitLab CI, AWS EKS, Google GKE, and others …; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L68 in content/docs/iac/operations/continuous-delivery/argocd.md "See Configuring OpenID Connect for Amazon EKS or [Configuring OpenID Connect for Google…" → ❌ contradicted (evidence: The linked path in argocd.md, /docs/administration/guides/oidc-issuers/kubernetes-eks/, does not exist. The actual page in pulumi/docs lives at content/docs/administration/access-identity/oidc-issuers/kubernetes-eks.md (path…; source: gh search code --repo pulumi/docs oidc-issuers; gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/oidc-issuers/kubernetes-eks.md)
  • L72 in content/docs/iac/operations/continuous-delivery/argocd.md "For clusters that are not registered as OIDC issuers, store a Pulumi access token in a Kubernetes Secret and…" → ❌ contradicted (evidence: The docs repo has no page under /docs/administration/concepts/access-tokens/. The actual access-tokens documentation lives at content/docs/administration/access-identity/access-tokens.md, resolving to…; source: gh search code --owner pulumi repo:pulumi/docs access-tokens (shows canonical path content/docs/administration/access-identity/access-tokens.md); no results for "administration/concepts")
  • L349 in content/docs/iac/operations/continuous-delivery/argocd.md "- OIDC issuers — exchange a cluster's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The target page content/docs/administration/guides/oidc-issuers/_index.md exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L50 in content/docs/iac/operations/continuous-delivery/aws-code-services.md "CodeBuild authenticates to Pulumi Cloud with a single Pulumi access token, supplied through the…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/access-tokens.md documents PULUMI_ACCESS_TOKEN usage and states "Organization and team access tokens are machine tokens that are not connected to a user account, and therefore should…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L164 in content/docs/iac/operations/continuous-delivery/aws-code-services.md "- OIDC issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ❌ contradicted (framing: The description text matches the real page's content, but the URL path segment ("guides" vs "access-identity") is wrong/broken.; evidence: The claim links to /docs/administration/guides/oidc-issuers/, but the actual OIDC Issuers page lives at content/docs/administration/access-identity/oidc-issuers/_index.md (URL /docs/administration/access-identity/oidc-issuers/), with…; source: gh_query search code --repo pulumi/docs oidc-issuers; gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/oidc-issuers/_index.md)
  • L49 in content/docs/iac/operations/continuous-delivery/azure-devops.md "Your pipeline needs a single Pulumi access token to authenticate with Pulumi Cloud." → ✅ verified (evidence: The linked page /docs/administration/concepts/access-tokens/ exists at content/docs/administration/concepts/access-tokens.md and states "Use access tokens to sign into the Pulumi Cloud via the CLI or automate your usage of the Pulumi…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L48 in content/docs/iac/operations/continuous-delivery/bitbucket.md "Your pipeline authenticates to Pulumi Cloud with a single Pulumi access token, supplied through the…" → ✅ verified (evidence: The target page content/docs/administration/concepts/access-tokens.md exists, defines Pulumi access tokens (personal, organization, team) used via PULUMI_ACCESS_TOKEN, and has the exact anchor "## Organization access tokens…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L60 in content/docs/iac/operations/continuous-delivery/bitbucket.md "Register Bitbucket Pipelines as a trusted OIDC issuer in Pulumi Cloud, and your pipeline can exchange that OIDC…" → ✅ verified (framing: Source describes the generic OIDC Issuer mechanism applicable to any third-party OIDC-issuing service ("and others"); claim applies this generic capability…; evidence: The linked OIDC Issuers doc states: "Any third-party service that can issue OIDC id_tokens — GitHub Actions, GitLab CI, AWS EKS, Google GKE, and others — can be registered in Pulumi Cloud as a trusted OIDC Issuer" and describes the exact…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L140 in content/docs/iac/operations/continuous-delivery/bitbucket.md "- OIDC issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The target page /docs/administration/guides/oidc-issuers/ exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own short-lived OIDC…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L67 in content/docs/iac/operations/continuous-delivery/buildkite.md "When your pipeline uses Pulumi Cloud as its backend, it needs only a single Pulumi access token to operate." → ✅ verified (evidence: The linked page /docs/administration/concepts/access-tokens/ confirms: "Use access tokens to sign into the Pulumi Cloud via the CLI or automate your usage of the Pulumi Cloud using the REST API," and describes org/team/personal tokens…; source: content/docs/administration/concepts/access-tokens.md)
  • L81 in content/docs/iac/operations/continuous-delivery/buildkite.md "You can remove even that static secret with OpenID Connect (OIDC). Register Buildkite as an OIDC issuer in…" → ✅ verified (evidence: The linked page /docs/administration/guides/oidc-issuers/ states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC. Instead of provisioning a long-lived Pulumi access token and storing it as a…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L171 in content/docs/iac/operations/continuous-delivery/buildkite.md "- OIDC issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The target page content/docs/administration/guides/oidc-issuers/_index.md exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L56 in content/docs/iac/operations/continuous-delivery/circleci.md "When your pipeline uses Pulumi Cloud as its backend, it needs only a single Pulumi access token to operate.…" → ❌ contradicted (evidence: The claim links to /docs/administration/concepts/access-tokens/, but no such path exists in the docs repo. The actual, correct path used consistently elsewhere (e.g. content/docs/iac/operations/continuous-delivery/_index.md: "Your…; source: gh search code --repo pulumi/docs "administration/concepts/access-tokens" (no results); gh search code --repo pulumi/docs "access-tokens" (shows canonical path /docs/administration/access-identity/access-tokens/); intuition: Link path uses "concepts" segment which doesn't match the established "access-identity" segment used site-wide …)
  • L58 in content/docs/iac/operations/continuous-delivery/circleci.md "Store the token in a CircleCI context rather than committing it to your repository. A context holds environment…" → ✅ verified (framing: Claim describes CircleCI contexts as org-level environment variable storage shared across projects, matching the general/well-known purpose of CircleCI…; evidence: The cited CircleCI docs page (https://circleci.com/docs/contexts/) is the official "Using contexts" documentation, which describes contexts as a mechanism for storing environment variables restricted by security groups at the…; source: https://circleci.com/docs/contexts/)
  • L205 in content/docs/iac/operations/continuous-delivery/circleci.md "- OIDC issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The target page /docs/administration/guides/oidc-issuers/ exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own short-lived OIDC…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L49 in content/docs/iac/operations/continuous-delivery/codefresh.md "When your pipeline uses Pulumi Cloud as its backend, it needs only a single Pulumi access token to operate.…" → ✅ verified (evidence: The pulumi/pulumi CLI source (pkg/cmd/pulumi/auth/login.go) states: "If PULUMI_ACCESS_TOKEN is set, that token is used. Otherwise, the command prompts for an [interactive login]" — confirming the CLI reads the token from that env var…; source: gh search code --owner pulumi --repo pulumi/pulumi PULUMI_ACCESS_TOKEN (pkg/cmd/pulumi/auth/login.go); repo:content/docs/administration/concepts/access-tokens.md)
  • L51 in content/docs/iac/operations/continuous-delivery/codefresh.md "Store the token outside of source control. Add it as an encrypted variable on the pipeline itself, or — to reuse it across pipelines — create a [shared…" → ✅ verified (framing: The claim links to the shared-configuration doc as the mechanism to reuse a variable across pipelines, which matches the page's stated topic.; evidence: The cited URL (https://codefresh.io/docs/docs/pipelines/configuration/shared-configuration/) resolves with HTTP 200 and is titled "Shared configuration for pipelines · Codefresh | Docs", matching the claim's reference to a shared…; source: https://codefresh.io/docs/docs/pipelines/configuration/shared-configuration/)
  • L55 in content/docs/iac/operations/continuous-delivery/codefresh.md "You can remove the static token entirely with OpenID Connect (OIDC): the pipeline exchanges a short-lived OIDC…" → ✅ verified (evidence: The linked OIDC Issuers page states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC. Instead of provisioning a long-lived Pulumi access token and storing it as a secret... Workloads on the service…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L146 in content/docs/iac/operations/continuous-delivery/codefresh.md "- OIDC Issuers — eliminate static tokens with short-lived, exchanged credentials." → ⚔️ mismatch (evidence: The live OIDC Issuers page in pulumi/docs lives at content/docs/administration/access-identity/oidc-issuers/_index.md (URL /docs/administration/access-identity/oidc-issuers/), and every sibling CI/CD doc (jenkins.md, harness.md…; source: gh search code --owner pulumi repo:pulumi/docs "oidc-issuers" (compared codefresh.md against jenkins.md, harness.md, bitbucket.md, buildkite.md, gitlab-ci.md, argocd.md; confirmed live path via gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/oidc-issuers))
  • L60 in content/docs/iac/operations/continuous-delivery/github-actions.md "Your workflow authenticates to Pulumi Cloud with a single Pulumi access token, supplied through the…" → ❌ contradicted (framing: Claim cites a path segment (administration/concepts/access-tokens) that has been renamed/moved to administration/access-identity/access-tokens elsewhere…; evidence: The linked path /docs/administration/concepts/access-tokens/ does not exist in the pulumi/docs repo (404 on content/docs/administration/concepts); the actual current location is…; source: gh_query: repos/pulumi/docs/contents/content/docs/administration/concepts (404); repos/pulumi/docs search showing sibling pages use content/docs/administration/access-identity/access-tokens.md)
  • L66 in content/docs/iac/operations/continuous-delivery/github-actions.md "You can remove the static token entirely. GitHub Actions can issue a short-lived [OpenID Connect (OIDC)](https://docs.github.com/actions/security-for-github-ac…" → ✅ verified (evidence: The cited GitHub Docs page (200 OK) is the official "About security hardening with OpenID Connect" page describing how GitHub Actions can issue short-lived OIDC tokens for workflow jobs to authenticate with cloud providers instead of…; source: https://docs.github.com/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect)
  • L617 in content/docs/iac/operations/continuous-delivery/github-actions.md "- OIDC issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The linked page content/docs/administration/guides/oidc-issuers/_index.md exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L50 in content/docs/iac/operations/continuous-delivery/gitlab-ci.md "Your pipeline authenticates to Pulumi Cloud with a single Pulumi access token, supplied through the…" → ✅ verified (evidence: The target page content/docs/administration/concepts/access-tokens.md exists and contains the exact anchor referenced: "## Organization access tokens {#creating-an-organization-access-token}", confirming both the base URL…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L56 in content/docs/iac/operations/continuous-delivery/gitlab-ci.md "You can remove the static token entirely. GitLab CI/CD can issue a short-lived [OpenID Connect (OIDC)](https://docs.gitlab.com/ci/secrets/id_token_authenticati…" → ✅ verified (evidence: The GitLab docs confirm that GitLab CI/CD generates ID tokens (JWTs) for OIDC authentication with third-party services, configured via the id_tokens keyword in a CI/CD job: "ID tokens are JSON web tokens (JWT) generated by GitLab…; source: https://docs.gitlab.com/ci/secrets/id_token_authentication/)
  • L75 in content/docs/iac/operations/continuous-delivery/gitlab-ci.md "With OIDC, the pipeline needs no PULUMI_ACCESS_TOKEN CI/CD variable. For the full setup — registering the issuer and writing the authorization policy that…" → ✅ verified (evidence: The linked page content/docs/administration/guides/oidc-issuers/gitlab.md contains "Register the OIDC Issuer" and "Configure the authorization policies" sections, including setting Aud (urn:pulumi:org:<org-name>) and Sub…; source: repo:content/docs/administration/guides/oidc-issuers/gitlab.md)
  • L436-437 in content/docs/iac/operations/continuous-delivery/gitlab-ci.md "- OIDC issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The target page /docs/administration/guides/oidc-issuers/ states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own short-lived OIDC id_tokens and…; source: content/docs/administration/guides/oidc-issuers/_index.md)
  • L44 in content/docs/iac/operations/continuous-delivery/google-cloud-build.md "- A stored access token — create a Pulumi access token and keep it in [Secret…" → ✅ verified (evidence: The cited URL https://cloud.google.com/secret-manager/docs returns HTTP 200 and is the official Google Cloud Secret Manager documentation landing page, consistent with the claim's description of it as "Secret Manager" documentation where…; source: https://cloud.google.com/secret-manager/docs)
  • L53 in content/docs/iac/operations/continuous-delivery/google-cloud-build.md "Create a Pulumi access token, preferring an organization or team token…" → ✅ verified (evidence: The target page content/docs/administration/concepts/access-tokens.md has the anchor ## Organization access tokens {#creating-an-organization-access-token} and states organization tokens "are the recommended token type for any…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L71 in content/docs/iac/operations/continuous-delivery/google-cloud-build.md "You can avoid storing a static token by having Cloud Build obtain a short-lived OpenID Connect (OIDC)…" → ✅ verified (evidence: The cited URL returns HTTP 200 and is the OpenID Foundation's official explainer page "How OpenID Connect Works," which supports the general description of OIDC used as background context in the claim; the claim itself makes no specific…; source: https://openid.net/developers/how-connect-works/)
  • L414 in content/docs/iac/operations/continuous-delivery/google-cloud-build.md "- OIDC issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The target page /docs/administration/guides/oidc-issuers/ exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own short-lived OIDC…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L34 in content/docs/iac/operations/continuous-delivery/harness.md "When your pipeline uses Pulumi Cloud as its backend, it needs only a single Pulumi access token to operate.…" → ✅ verified (framing: Claim links to the Harness secrets doc for the general concept of adding/using a secret, which matches the page's content and title.; evidence: The cited Harness docs page (HTTP 200) is titled "Add and reference text secrets" and covers Harness secrets functionality, consistent with the claim's instruction to add the Pulumi token as a Harness secret and reference it from a…; source: https://developer.harness.io/docs/platform/secrets/add-use-text-secrets/)
  • L38 in content/docs/iac/operations/continuous-delivery/harness.md "To remove the static token entirely, Harness can act as an OIDC issuer, and Pulumi Cloud can register any third-party issuer as a trusted [OIDC…" → ✅ verified (framing: Source states the general capability for "any third-party service that can issue OIDC id_tokens"; claim applies this general capability specifically to…; evidence: The OIDC Issuers page states: "Any third-party service that can issue OIDC id_tokens — GitHub Actions, GitLab CI, AWS EKS, Google GKE, and others — can be registered in Pulumi Cloud as a trusted OIDC Issuer... Instead of provisioning a…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L212 in content/docs/iac/operations/continuous-delivery/harness.md "- OIDC Issuers — exchange a CI/CD system's OIDC token for a short-lived Pulumi access token." → ✅ verified (evidence: The target page /docs/administration/guides/oidc-issuers/ exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC... Workloads on the service then present their own short-lived OIDC…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)

  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor
continued from previous comment
  • L44 in content/docs/iac/operations/continuous-delivery/jenkins.md "- A stored access token. A long-lived Pulumi access token saved as a Jenkins credential. Simple to set up…" → ✅ verified (evidence: The linked page content/docs/administration/concepts/access-tokens.md exists and describes Pulumi access tokens (personal, organization, team) used to "sign into the Pulumi Cloud via the CLI", explicitly recommending organization tokens…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L49 in content/docs/iac/operations/continuous-delivery/jenkins.md "When your pipeline uses Pulumi Cloud as its backend, it needs only a single Pulumi access token to operate.…" → ✅ verified (evidence: The linked /docs/administration/concepts/access-tokens/ page confirms access tokens are used "to sign into the Pulumi Cloud via the CLI" and are the standard mechanism for automation. The claim's phrasing and mechanism…; source: repo:content/docs/administration/concepts/access-tokens.md; repo:content/docs/iac/operations/continuous-delivery/github-actions.md)
  • L59 in content/docs/iac/operations/continuous-delivery/jenkins.md "Prefer an organization or team token over a personal token so the…" → ✅ verified (evidence: The access-tokens doc has a section "## Organization access tokens {#creating-an-organization-access-token}" stating: "Organization tokens authenticate as the organization itself rather than any individual user. They are the recommended…; source: content/docs/administration/concepts/access-tokens.md)
  • L63 in content/docs/iac/operations/continuous-delivery/jenkins.md "You can remove the static token entirely with OpenID Connect (OIDC). Pulumi Cloud can register any trusted…" → ✅ verified (evidence: The linked page states: "Any third-party service that can issue OIDC id_tokens — GitHub Actions, GitLab CI, AWS EKS, Google GKE, and others — can be registered in Pulumi Cloud as a trusted OIDC Issuer" and describes workloads exchanging…; source: content/docs/administration/guides/oidc-issuers/_index.md)
  • L212 in content/docs/iac/operations/continuous-delivery/jenkins.md "- OIDC Issuers — eliminate static tokens with short-lived, exchanged credentials." → ✅ verified (evidence: The target page content/docs/administration/guides/oidc-issuers/_index.md exists at that exact path and states: "Instead of provisioning a long-lived Pulumi access token and storing it as a secret... Workloads on the service then present…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L44 in content/docs/iac/operations/continuous-delivery/octopus-deploy.md "- A stored access token. Save a long-lived Pulumi access token as a sensitive Octopus variable. Simple to…" → ✅ verified (framing: The claim describes a specific usage pattern (storing as an Octopus variable) that is a narrower application of the general access token concept described in…; evidence: The linked page /docs/administration/concepts/access-tokens/ exists and describes Pulumi access tokens (personal, organization, team) including their use in CI/CD pipelines and expiration up to two years — consistent with describing them…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L49 in content/docs/iac/operations/continuous-delivery/octopus-deploy.md "Pulumi reads its access token from the PULUMI_ACCESS_TOKEN environment variable and authenticates without an interactive login. Store the token as a…" → ✅ verified (framing: Claim links to Octopus's project variables doc as the place to store a sensitive token; page is confirmed live and topically matches.; evidence: The cited URL (https://octopus.com/docs/projects/variables) returns HTTP 200 and is Octopus Deploy's official documentation page on project variables, consistent with the claim's reference to storing a sensitive project variable. The…; source: https://octopus.com/docs/projects/variables)
  • L55 in content/docs/iac/operations/continuous-delivery/octopus-deploy.md "Octopus Deploy 2025.1 and later can issue a short-lived OIDC token for a deployment run through a [Generic OpenID Connect…" → 🤷 unverifiable (evidence: The pre-fetched page returns HTTP 200 but the truncated body only contains generic site navigation/chrome ("Docs API CLI... Start for free Sign in") with no content about OIDC tokens, deployment runs, or version 2025.1 support, so the…; source: https://octopus.com/docs/infrastructure/accounts/openid-connect)
  • L64 in content/docs/iac/operations/continuous-delivery/octopus-deploy.md "The OIDC path requires Octopus Deploy 2025.1 or later, and Pulumi Cloud must be able to reach your Octopus Server's OIDC discovery endpoint to validate the…" → ✅ verified (framing: Source describes the general OIDC discovery fetch mechanism (applicable to any issuer); claim applies this generic reachability requirement specifically to…; evidence: The OIDC Issuers page confirms the underlying mechanism: "Pulumi Cloud fetches the OpenID configuration metadata by appending /.well-known/openid-configuration to this URL" — i.e., Pulumi Cloud makes an outbound call to the issuer's…; source: content/docs/administration/guides/oidc-issuers/_index.md)
  • L138 in content/docs/iac/operations/continuous-delivery/octopus-deploy.md "- OIDC Issuers — eliminate static tokens with short-lived, exchanged credentials." → ❌ contradicted (evidence: The canonical OIDC issuers page in the pulumi/docs repo lives at content/docs/administration/access-identity/oidc-issuers/_index.md, i.e. URL /docs/administration/access-identity/oidc-issuers/ — used consistently across dozens of sibling…; source: gh search code --owner pulumi repo:pulumi/docs "oidc-issuer"; gh api repos/pulumi/docs/contents/content/docs/administration/guides (404 Not Found))
  • L43 in content/docs/iac/operations/continuous-delivery/teamcity.md "When your pipeline uses Pulumi Cloud as its backend, it needs only a single Pulumi access token to operate.…" → ✅ verified (evidence: Pulumi CLI source (pkg/cmd/pulumi/auth/login.go) states: "If PULUMI_ACCESS_TOKEN is set, that token is used. Otherwise, the command prompts for an [interactive login]" — confirming the CLI reads the token from that env var and skips…; source: gh search code --repo pulumi/pulumi PULUMI_ACCESS_TOKEN (pkg/cmd/pulumi/auth/login.go); content/docs/administration/concepts/access-tokens.md)
  • L45 in content/docs/iac/operations/continuous-delivery/teamcity.md "Store the token outside of source control. Add it as a build parameter of type…" → ✅ verified (framing: Source describes password parameters generically for hiding sensitive values; claim applies this general mechanism to the specific env.PULUMI_ACCESS_TOKEN…; evidence: The page confirms env.-prefixed parameters are passed as environment variables to the build process, and that password-type parameters are used "to hide these sensitive values from both TeamCity UI and build logs" — matching the claim…; source: https://www.jetbrains.com/help/teamcity/configuring-build-parameters.html)
  • L130 in content/docs/iac/operations/continuous-delivery/teamcity.md "- OIDC Issuers — eliminate static tokens on CI/CD systems that can issue OIDC tokens." → ✅ verified (evidence: The linked page /docs/administration/guides/oidc-issuers/ exists and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC. Instead of provisioning a long-lived Pulumi access token and storing it…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L72 in content/docs/iac/operations/continuous-delivery/travis.md "When your pipeline uses Pulumi Cloud as its backend, it needs a single Pulumi access token to operate. Prefer…" → ✅ verified (evidence: The linked page /docs/administration/concepts/access-tokens/ exists and states organization tokens "are the recommended token type for any automated or non-interactive workflow, including: CI/CD pipelines... deploying infrastructure…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L26 in content/docs/iac/operations/continuous-delivery/troubleshooting.md "- A way to authenticate with your backend — a Pulumi access token when using Pulumi Cloud." → ❌ contradicted (evidence: The actual docs page lives at content/docs/administration/access-identity/access-tokens.md, i.e. URL /docs/administration/access-identity/access-tokens/ — there is no content/docs/administration/concepts/ directory at all. A sibling page…; source: gh search code --repo pulumi/docs access-tokens; gh api repos/pulumi/docs/contents/content/docs/administration/access-identity)
  • L44 in content/docs/iac/operations/continuous-delivery/troubleshooting.md "- Prefer an organization or team access token over a personal one, so…" → ✅ verified (evidence: The target page has heading "## Organization access tokens {#creating-an-organization-access-token}" and states: "Organization tokens authenticate as the organization itself rather than any individual user. They are the recommended token…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L46 in content/docs/iac/operations/continuous-delivery/troubleshooting.md "To avoid storing a long-lived secret at all, use OpenID Connect (OIDC): the pipeline exchanges a short-lived…" → ✅ verified (evidence: The linked page /docs/administration/guides/oidc-issuers/ describes exactly this: "Instead of provisioning a long-lived Pulumi access token and storing it as a secret in your CI system... Workloads on the service then present their own…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L47 in content/docs/iac/operations/stack-management/restoring-deleted-stacks.md "- For stacks that should never be removable through routine operations, restrict who has organization-admin or stack-write permissions. See [Teams and…" → ✅ verified (evidence: The target page content/docs/administration/concepts/rbac/teams.md exists at the linked path and documents Pulumi Cloud RBAC via teams, including team-level and organization-admin permission concepts referenced by the claim (e.g. "Teams…; source: repo:content/docs/administration/concepts/rbac/teams.md)
  • L26 in content/docs/idp/concepts/terraform-modules.md "Every surface authenticates with a Pulumi access token. It is the bearer token for everything Pulumi Cloud…" → ✅ verified (framing: Source describes access tokens as the general sign-in/API credential for Pulumi Cloud; claim narrows this to the specific HashiCorp-protocol surfaces…; evidence: The linked page /docs/administration/concepts/access-tokens/ confirms: "Use access tokens to sign into the Pulumi Cloud via the CLI or automate your usage of the Pulumi Cloud using the REST API." This establishes the access token as the…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L25 in content/docs/idp/guides/publishing-from-github-actions.md "- Configure Pulumi and GitHub integrations: OIDC, [GitHub App](/docs/integrations/version-control/github-ap…" → ✅ verified (evidence: The linked page content/docs/administration/guides/oidc-issuers/github.md exists and covers exactly this topic: "This document outlines the steps required to configure Pulumi Cloud to accept GitHub id_tokens and exchange them for Pulumi…; source: repo:content/docs/administration/guides/oidc-issuers/github.md)
  • L303 in content/docs/idp/guides/publishing-from-github-actions.md "- pulumi/auth-actions - authenticate with Pulumi Cloud (make sure to [setup GitHub…" → ✅ verified (evidence: The repo exists at github.com/pulumi/auth-actions and its description confirms it is for Pulumi Cloud authentication: "Simplify Pulumi authentication without having to configure secrets for your workflows."; source: https://github.com/pulumi/auth-actions)
  • L72 in content/docs/insights/discovery/_index.md "Resource search is available to all organization members, but users can only see and query resources they have [permission](/docs/administration/concepts/rbac/…" → ❌ contradicted (evidence: The claim links to /docs/administration/concepts/rbac/permission-sets/#stack-permission-sets, but the actual permission-sets doc lives at /docs/administration/access-identity/rbac/permission-sets/. Sibling pages in the same repo…; source: gh search code --owner pulumi "stack-permission-sets" -R pulumi/docs; intuition: Broken internal link path: /docs/administration/concepts/rbac/... does not exist; correct path is…)
  • L439 in content/docs/insights/discovery/search.md "Resource Search is available to all members of an organization, but as a user you are only able to see and query resources that you have…" → ✅ verified (evidence: The target page content/docs/administration/concepts/rbac/permission-sets.md contains a "### Stack permission sets" section (anchor #stack-permission-sets) listing Stack Read/Write/Admin permission sets including stack:read, which…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L444 in content/docs/insights/discovery/search.md "- If an organization has no default permission, then users can only query resources they have access to via [Stack](/docs/administration/concepts/rbac/permissi…" → ✅ verified (evidence: The permission-sets.md doc contains a "### Stack permission sets" heading (slug #stack-permission-sets) describing Stack Read/Write/Admin sets, confirming the linked anchor exists and is topically correct for the claim about stack-level…; source: repo:content/docs/administration/concepts/rbac/permission-sets.md)
  • L107 in content/docs/integrations/clouds/kubernetes/pulumi-kubernetes-operator/installation.md "To avoid storing long-lived Pulumi access tokens in your cluster, you can register the cluster as a Pulumi Cloud OIDC Issuer and have workspace pods exchange…" → ❌ contradicted (framing: Same target topic (EKS OIDC issuer setup) but wrong URL path segment ("guides" vs "access-identity"), making the cited link a 404.; evidence: The linked path in this file, /docs/administration/guides/oidc-issuers/kubernetes-eks/, does not match the actual repo path for this page. Sibling docs (content/docs/administration/access-identity/oidc-issuers/_index.md…; source: repo:pulumi/docs content/docs/administration/access-identity/oidc-issuers/_index.md and content/docs/iac/operations/continuous-delivery/argocd.md (gh search code))
  • L110 in content/docs/integrations/clouds/kubernetes/pulumi-kubernetes-operator/installation.md "[tokens]: https://www.pulumi.com/docs/administration/concepts/access-tokens/" → ❌ contradicted (evidence: The cited URL https://www.pulumi.com/docs/administration/concepts/access-tokens/ returns HTTP 404 Not Found, so the "tokens" reference link is broken.; source: https://www.pulumi.com/docs/administration/concepts/access-tokens/)
  • L128 in content/docs/integrations/version-control/bitbucket.md "Use Bitbucket Pipelines' built-in OIDC tokens to authenticate with Pulumi Cloud without storing long-lived credentials as pipeline variables. See…" → ✅ verified (framing: Source describes OIDC Issuers generically for "outside services"/CI systems; claim narrows this to Bitbucket Pipelines specifically, which is a valid special…; evidence: The target page content/docs/administration/guides/oidc-issuers/_index.md exists, is titled "OIDC Issuers", and states: "OIDC Issuers let outside services securely obtain Pulumi Cloud access tokens via OIDC. Instead of provisioning a…; source: repo:content/docs/administration/guides/oidc-issuers/_index.md)
  • L131 in content/docs/integrations/version-control/gitlab.md "Use GitLab CI's built-in OIDC tokens to authenticate with Pulumi Cloud without storing long-lived credentials as CI variables. See [Configuring OpenID…" → ✅ verified (evidence: The target page at content/docs/administration/guides/oidc-issuers/gitlab.md is titled "Configuring OpenID Connect for GitLab" (h1 matches exactly) and describes how to "configure Pulumi Cloud to accept GitLab id_tokens and exchange them…; source: content/docs/administration/guides/oidc-issuers/gitlab.md)
  • L33 in content/docs/reference/cloud-rest-api/_index.md "* Directly over HTTPS — pair an access token with the standard Accept and Content-Type headers and…" → 🤷 unverifiable (evidence: [source-discipline gate: this page is generated from data/, so a disagreement with the cited external framework is upstream product feedback, not a doc contradiction — contradicted downgraded to unverifiable. Surface as an author…; source: gh api repos/pulumi/docs/contents/content/docs/administration (no 'concepts' subdirectory); gh search code --owner pulumi "access-tokens" -R pulumi/docs)
  • L81 in content/docs/support/faq/pulumi-cloud.md "The Pulumi documentation page about Organizations is located at /docs/administration/concepts/organizations/." → ❌ contradicted (evidence: (escalated from pass1 after exhausting its 12-turn cap) The live Pulumi Organizations documentation page is located at /docs/administration/organizations-teams/organizations/, titled "Pulumi Cloud Organizations" — there is no…; source: https://www.pulumi.com/docs/administration/organizations-teams/organizations/)
  • L100 in content/docs/support/faq/pulumi-cloud.md "The Pulumi documentation section on Transferring stacks is located at /docs/administration/concepts/organizations/#transferring-stacks." → ❌ contradicted (evidence: The pulumi/docs repo has no content/docs/administration/concepts/ directory at all (404 on lookup). The "Transferring stacks" heading actually lives in content/docs/administration/organizations-teams/organizations.md, whose…; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts (404); gh api repos/pulumi/docs/contents/content/docs/administration/organizations-teams/organizations.md)
  • L108 in content/docs/support/faq/pulumi-cloud.md "If the option to delete a Pulumi organization is not visible, this confirms the user is not an organization admin." → 🌀 framing-drift (framing: shifted — source's imperative "confirm you're an organization admin" (a suggestion to check) is recast as a declarative certainty "this confirms the user is…; evidence: Source text reads: "If you don't see this option, confirm you're an organization admin." This is an instruction telling the user to check/verify their admin status, not a definitive statement that absence of the option "confirms"…; source: repo:content/docs/support/faq/pulumi-cloud.md (line 108))
  • L110 in content/docs/support/faq/pulumi-cloud.md "The Pulumi documentation section on Deleting an organization is located at /docs/administration/concepts/organizations/#deleting-an-organization." → ✅ verified (evidence: content/docs/administration/concepts/organizations.md contains a "## Deleting an organization" heading (line 150), which generates the anchor #deleting-an-organization at /docs/administration/concepts/organizations/, matching the claim…; source: repo:content/docs/administration/concepts/organizations.md)
  • L121-122 in content/docs/support/faq/pulumi-cloud.md "Deleting a user's Pulumi account removes access to any stacks and environments still under that account." → 🤝 matches (evidence: The claim paraphrases the file's own warning box ("deleting your account will remove access to any stacks and environments still under the account. Transfer any stacks you want to keep before proceeding.") and is consistent with the…; source: content/docs/support/faq/pulumi-cloud.md L121-122; content/docs/administration/concepts/organizations.md L163-169)
  • L124 in content/docs/support/faq/pulumi-cloud.md "The Pulumi documentation section on Joining an organization is located at /docs/administration/concepts/organizations/#joining-an-organization." → ✅ verified (evidence: content/docs/administration/concepts/organizations.md contains a heading "## Joining an organization" (line 50), which renders as anchor #joining-an-organization, matching the linked path…; source: repo:content/docs/administration/concepts/organizations.md)
  • L132 in content/docs/support/faq/pulumi-cloud.md "Before deleting an account, the user must have transferred any stacks they want to keep and must not be required as an admin in any organization." → 🤝 matches (evidence: The sibling page content/docs/administration/concepts/organizations.md, section "Deleting your account," states verbatim: "Before deleting your account, make sure you have transferred any stacks you want to keep and that you are no…; source: repo:content/docs/administration/concepts/organizations.md (Deleting your account section))
  • L134 in content/docs/support/faq/pulumi-cloud.md "The Pulumi documentation section on Deleting your account is located at /docs/administration/concepts/organizations/#deleting-your-account." → ❌ contradicted (framing: Anchor fragment and heading text are correct, but the path segment is wrong — claim points to a non-existent page path.; evidence: The "Deleting your account" section (with anchor #deleting-your-account) does exist, but it lives in content/docs/administration/organizations-teams/organizations.md — which serves at…; source: repos/pulumi/docs/contents/content/docs/administration/organizations-teams/organizations.md (front matter aliases + "## Deleting your account" heading))
  • L147-149 in content/docs/support/faq/pulumi-cloud.md "The Individual edition of Pulumi Cloud covers a single user." → ✅ verified (evidence: The same doc file states directly (line 147): "No. The Individual edition covers a single user, which suits private projects but not a team," and line 185 of content/pricing/_index.md confirms "Individual is free forever for one user."…; source: content/pricing/_index.md L185; content/docs/support/faq/pulumi-cloud.md L147)
  • L147-151 in content/docs/support/faq/pulumi-cloud.md "Enterprise and Business Critical Pulumi Cloud editions add role-based access control and SAML/SSO on top of the Team edition." → ✅ verified (framing: Source specifies advanced/configurable RBAC (custom roles, permission sets, ABAC) is Enterprise/Business Critical-only while basic RBAC exists in Team…; evidence: The linked RBAC docs page states: "Pulumi Cloud's configurable RBAC features — custom roles, custom permission sets, teams, and tag-based (ABAC) rules — are only available in the Pulumi Enterprise or Business Critical editions. The…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L148-149 in content/docs/support/faq/pulumi-cloud.md "Organizations in Pulumi Cloud start with the Team edition." → ✅ verified (evidence: The same FAQ doc states: "Organizations — the shared workspace where several engineers work on the same projects — start with the Team edition. Enterprise and Business Critical add role-based access control and SAML/SSO on top of that,"…; source: content/docs/support/faq/pulumi-cloud.md L145-151; content/pricing/_index.md)
  • L151 in content/docs/support/faq/pulumi-cloud.md "SAML/SSO on top of that." → ✅ verified (evidence: The linked file content/docs/administration/guides/saml/_index.md exists in the repo and is titled "SAML(SSO)" / "Pulumi Cloud SAML(SSO)", confirming the link target is valid and matches the anchor text "SAML/SSO" used in the FAQ page.; source: repo:content/docs/administration/guides/saml/_index.md)
  • L195-198 in content/docs/support/faq/pulumi-cloud.md "The Business Critical edition of Pulumi Cloud adds self-hosting, built-in compliance frameworks, SCIM user and group sync, audit log export, and 24x7 support." → ✅ verified (evidence: The same file's edition comparison explicitly states: "Business Critical adds self-hosting, built-in compliance frameworks, SCIM user and group sync, audit log export, and 24x7 support." This is corroborated by the self-hosting page…; source: repo:content/docs/support/faq/pulumi-cloud.md (L195-198); repo:content/docs/administration/self-hosting/_index.md; repo:content/pricing/_index.md)
  • L200 in content/docs/support/faq/pulumi-cloud.md "A feature-by-feature comparison of Pulumi Cloud editions is available at the pricing page (/pricing/)." → ✅ verified (evidence: content/pricing/_index.md uses layout: pricing and contains a full feature/tier comparison matrix (Individual, Team, Enterprise, Business Critical editions with detailed feature breakdowns), matching the FAQ's claim that a…; source: repo:content/pricing/_index.md)
  • L204 in content/docs/support/faq/pulumi-cloud.md "Self-serve organization admins and Billing Managers can update payment details from the organization's Billing & usage settings in Pulumi Cloud under Payment…" → ✅ verified (evidence: The Billing Managers doc states Billing Managers permission table includes "View and Update credit card" and "View and Update subscription", accessed via Settings > Billing & usage; Organization Admins can also access/manage all billing…; source: repo:content/docs/administration/organizations-teams/billing-managers.md)
  • L206 in content/docs/support/faq/pulumi-cloud.md "The Pulumi documentation page about Billing Managers is located at /docs/administration/concepts/billing-managers/." → ✅ verified (evidence: The Concepts index (content/docs/administration/concepts/_index.md) explicitly lists "- Billing managers — the role that delegates billing access without granting admin rights,"…; source: repo:content/docs/administration/concepts/_index.md)
  • L65 in content/releases/agentic-infrastructure-era.md "link: /docs/administration/concepts/agent-accounts/" → ❌ contradicted (evidence: The Agent accounts page actually lives at content/docs/administration/organizations-teams/agent-accounts.md (URL /docs/administration/organizations-teams/agent-accounts/), confirmed via the repo directory listing and other pages…; source: gh api repos/pulumi/docs/contents/content/docs/administration/organizations-teams (agent-accounts.md present); gh search code --owner pulumi agent-accounts)
  • L391 in content/tutorials/esc-managed-chatapp/index.md "In order to use the Pulumi ESC SDK from within our Python code, we will need to create an ESC client, and call the open_and_read_environment method. The…" → ❌ contradicted (evidence: The linked path /docs/administration/concepts/access-tokens/ does not exist in pulumi/docs. The actual access tokens doc lives at content/docs/administration/access-identity/access-tokens.md (canonical path…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/access-tokens.md (front matter aliases); gh api repos/pulumi/docs/contents/content/docs/administration (no "concepts" dir); intuition: Link path uses a "concepts" segment that doesn't match the site's actual admin doc taxonomy (access-identity)…)
  • L434 in content/tutorials/esc-managed-chatapp/index.md "If this returns nothing, you'll need to create an access token:" → ✅ verified (evidence: The sibling concepts index page (content/docs/administration/concepts/_index.md) lists: "Access tokens — personal, team, and organization tokens for authenticating the CLI, CI/CD, and the…; source: repo:content/docs/administration/concepts/_index.md)
  • L43 in content/tutorials/esc-setup-psp-creds/index.md "Next, you'll also need a Pulumi Cloud personal access token. Create a short-lived…" → ✅ verified (evidence: The target page content/docs/administration/concepts/access-tokens.md contains a "## Personal access tokens" section (anchor #personal-access-tokens) that documents creating personal access tokens ("Personal access tokens carry the same…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L40 in content/tutorials/esc-version-tagging/index.md "To complete the application-configuration portion of the tutorial, you'll also need a Pulumi Cloud [personal access token](/docs/administration/concepts/access…" → ✅ verified (evidence: The target page content/docs/administration/concepts/access-tokens.md contains a "## Personal access tokens" section (line 38), which resolves to the anchor #personal-access-tokens referenced in the claim's link, and it documents…; source: repo:content/docs/administration/concepts/access-tokens.md)
  • L55 in content/what-is/what-is-agentic-infrastructure.md "Your coding agent and Pulumi IaC. The agent edits Pulumi code, runs pulumi preview to check the plan against its intent, and deploys. The verification…" → ✅ verified (framing: Source shows CLI is explicitly built with scripting/agent use cases (stable exit codes, JSON error envelope) in mind; claim that it's "designed for exactly…; evidence: The /docs/iac/cli/ page documents pulumi preview and pulumi up as core commands, lists pulumi api with "stable exit codes and a JSON error envelope for scripts and agents," and links to CLI exit codes designed for automation …; source: repo:content/docs/iac/cli/_index.md)
  • L12 in data/glossary.toml "link = '/docs/administration/concepts/audit-logs/'" → ❌ contradicted (evidence: The glossary entry links to "/docs/administration/concepts/audit-logs/", but no such path exists in the docs repo. The actual Audit Log page lives at content/docs/administration/security-compliance/audit-logs/_index.md (identifier…; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts (404); gh search code --repo pulumi/docs audit-logs)
  • L112 in data/glossary.toml "link = '/docs/administration/guides/oidc-issuers/'" → ❌ contradicted (evidence: The actual docs page lives at content/docs/administration/access-identity/oidc-issuers/_index.md, resolving to URL /docs/administration/access-identity/oidc-issuers/ (confirmed by dozens of cross-references across pulumi/docs, e.g.…; source: gh search code --repo pulumi/docs oidc-issuers)
  • L117 in data/glossary.toml "link = '/docs/administration/concepts/organizations/'" → ❌ contradicted (evidence: The pulumi/docs repo has no content/docs/administration/concepts/ directory. The actual organizations page lives at content/docs/administration/organizations-teams/organizations.md, which resolves to…; source: gh api repos/pulumi/docs/contents/content/docs/administration (returns organizations-teams, not concepts))
  • L207 in data/glossary.toml "link = '/docs/administration/concepts/rbac/'" → ✅ verified (evidence: The page content/docs/administration/concepts/rbac/_index.md exists in the repo with title "Role-Based Access Control (RBAC)", confirming the glossary link path "/docs/administration/concepts/rbac/" resolves to a real, matching docs page.; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L297 in data/glossary.toml "link = '/docs/administration/concepts/rbac/teams/'" → ✅ verified (evidence: content/docs/administration/concepts/rbac/teams.md exists with menu parent "administration-concepts-rbac", which Hugo renders at /docs/administration/concepts/rbac/teams/ — matching the glossary link exactly. The sibling rbac/_index.md…; source: repo:content/docs/administration/concepts/rbac/teams.md)
  • L302 in data/glossary.toml "link = '/docs/administration/concepts/access-tokens/'" → ❌ contradicted (evidence: The actual access-tokens doc lives at content/docs/administration/access-identity/access-tokens.md (URL /docs/administration/access-identity/access-tokens/); there is no content/docs/administration/concepts/ directory at all in…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity (shows access-tokens.md); gh api repos/pulumi/docs/contents/content/docs/administration/concepts returns 404)
  • L727 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/organizations/" → ❌ contradicted (evidence: The pulumi/docs repo has no content/docs/administration/concepts directory at all; the actual "Organizations" page lives at content/docs/administration/organizations-teams/organizations.md (i.e. URL…; source: gh api repos/pulumi/docs/contents/content/docs/administration (shows organizations-teams, not concepts, as the directory) and gh search code --repo pulumi/docs "concepts/organizations" (no results))
  • L735 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/accounts/" → ❌ contradicted (evidence: Searching pulumi/docs repo tree shows content/docs/administration/ contains only access-identity, onboarding-guide, organizations-teams, security-compliance, and self-hosting subdirectories — there is no "concepts" directory and no…; source: gh api repos/pulumi/docs/contents/content/docs/administration (and subpaths) on pulumi/docs master branch; intuition: Broken/dangling internal link path in a generated pricing data file — likely a stale or mistyped route.)
  • L744 in data/pulumi_pricing.yaml "link: /docs/administration/guides/saml/" → ✅ verified (evidence: The page content/docs/administration/guides/saml/_index.md exists with front matter matching this path (title "SAML(SSO)", menu identifier administration-guides-saml), confirming /docs/administration/guides/saml/ is a valid, resolvable…; source: repo:content/docs/administration/guides/saml/_index.md)
  • L756 in data/pulumi_pricing.yaml "link: /docs/administration/guides/scim/" → ✅ verified (evidence: The file content/docs/administration/guides/scim/_index.md exists and renders at the path /docs/administration/guides/scim/, matching the link target exactly; title "SCIM 2.0 Integration Guides" with h1 "Pulumi Cloud & SCIM".; source: repo:content/docs/administration/guides/scim/_index.md)
  • L766 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/rbac/teams/" → ✅ verified (evidence: The rbac/_index.md file (current canonical location content/docs/administration/concepts/rbac/_index.md) itself links to teams via /docs/administration/concepts/rbac/teams/ multiple times (e.g.…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L775 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/rbac/" → ✅ verified (evidence: The page content/docs/administration/concepts/rbac/_index.md exists at the URL /docs/administration/concepts/rbac/ and covers Role-Based Access Control, confirming the link target in the pricing data file is valid.; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L780 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/rbac/roles" → ✅ verified (evidence: The page content/docs/administration/concepts/rbac/roles.md exists locally and contains a "Custom roles" section stating "Pulumi Enterprise allows up to 25 custom roles; Pulumi Business Critical allows unlimited custom roles," matching…; source: repo:content/docs/administration/concepts/rbac/roles.md)
  • L798 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/access-tokens/" → ❌ contradicted (evidence: The actual docs page lives at content/docs/administration/access-identity/access-tokens.md (URL /docs/administration/access-identity/access-tokens/), not /docs/administration/concepts/access-tokens/. There is no "concepts" directory…; source: gh api repos/pulumi/docs/contents/content/docs/administration/access-identity/access-tokens.md)
  • L808 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/audit-logs/" → ✅ verified (evidence: The docs page exists at content/docs/administration/concepts/audit-logs.md with title "Audit Logs" and content about Pulumi Cloud audit logs, confirming the link target /docs/administration/concepts/audit-logs/ resolves to a valid…; source: repo:content/docs/administration/concepts/audit-logs.md)
  • L813 in data/pulumi_pricing.yaml "link: /docs/administration/guides/export-audit-logs/aws-s3/" → ❌ contradicted (evidence: The pulumi/docs repo has no content/docs/administration/guides/ directory at all. The actual AWS S3 audit-log export page lives at content/docs/administration/security-compliance/audit-logs/aws-s3.md, i.e. URL…; source: gh api repos/pulumi/docs/contents/content/docs/administration/security-compliance/audit-logs)
  • L70 in layouts/index.llms.txt "- Doing infrastructure work as an agent — the Pulumi CLI is designed for agents: run any command with npx pulumi, perform one-shot resource operations…" → ✅ verified (evidence: The docs page at the cited URL states: "The pulumi do command provides direct operations on cloud resources through the Pulumi CLI without requiring a project, program, or state file," supporting operations like…; source: repo:content/docs/iac/cli/direct-resource-operations.md)
  • L18 in layouts/shortcodes/identities.html "<a class='block rounded transition-all my-2 py-4 text-center px-6 hover:bg-gray-200 dark:hover:bg-white/10' href='{{ relref .…" → ✅ verified (evidence: The relref target content/docs/administration/guides/saml/_index.md exists in the repo ("SAML(SSO)" / "Pulumi Cloud SAML(SSO)" page), so the link in identities.html resolves to a valid, existing docs page.; source: repo:content/docs/administration/guides/saml/_index.md)
  • L1-3 in scripts/redirects/esc-redirects.txt "docs/esc/access-management/access-control/index.html|https://www.pulumi.com/docs/administration/concepts/rbac/" → ✅ verified (evidence: The redirect line maps the old ESC access-control page to https://www.pulumi.com/docs/administration/concepts/rbac/, which resolves to content/docs/administration/concepts/rbac/_index.md — a live, substantive "Role-Based Access Control…; source: repo:content/docs/administration/concepts/rbac/_index.md)
  • L15 in scripts/redirects/general-broken-links-redirects.txt "docs/pulumi-cloud/access-management/saml/aad/index.html|/docs/administration/guides/saml/entra/" → ✅ verified (evidence: The target page content/docs/administration/guides/saml/entra.md exists and its frontmatter aliases list includes /docs/pulumi-cloud/access-management/saml/aad/ verbatim, confirming this redirect entry maps the legacy AAD path to the…; source: repo:content/docs/administration/guides/saml/entra.md (aliases: - /docs/pulumi-cloud/access-management/saml/aad/))
  • L19 in scripts/redirects/general-broken-links-redirects.txt "docs/pulumi-cloud/access-management/scim/azuread/index.html|/docs/administration/guides/scim/entra/" → ✅ verified (evidence: The parent SCIM guide page (content/docs/administration/guides/scim/_index.md) explicitly links to '/docs/administration/guides/scim/entra/' as the current Microsoft Entra ID (formerly Azure AD) guide: "- [Microsoft Entra ID (formerly…; source: repo:content/docs/administration/guides/scim/_index.md)
  • L21-22 in scripts/redirects/general-broken-links-redirects.txt "docs/pulumi-cloud/access-management/oidc/client/index.html|/docs/administration/guides/oidc-issuers/" → ❌ contradicted (evidence: The redirect target /docs/administration/guides/oidc-issuers/ does not correspond to any existing content path in pulumi/docs. A repo search for "guides/oidc-issuers" returns zero hits, while the actual current OIDC issuers page lives…; source: gh search code --repo pulumi/docs "guides/oidc-issuers" (no results); gh search code --repo pulumi/docs "oidc-issuers" (shows content/docs/administration/access-identity/oidc-issuers/_index.md))
  • L1 in content/docs/administration/access-identity/_index.md "frontmatter URL ? collides with ?" → 🚩 flagged (frontmatter: url-collision)
  • L1 in content/docs/administration/access-identity/rbac/scopes.md "frontmatter URL ? collides with ?" → 🚩 flagged (frontmatter: url-collision)
  • L1 in content/docs/administration/access-identity/stack-permissions.md "frontmatter URL ? collides with ?" → 🚩 flagged (frontmatter: url-collision)
  • L1 in content/docs/administration/guides/oidc-issuers/_index.md "frontmatter alias /docs/pulumi-cloud/oidc/ collides with content/docs/deployments/guides/oidc/_index.md" → 🚩 flagged (frontmatter: alias-collision)
  • L1 in content/docs/administration/guides/oidc-issuers/_index.md "frontmatter alias /docs/administration/access-identity/oidc/ collides with content/docs/deployments/guides/oidc/_index.md" → 🚩 flagged (frontmatter: alias-collision)
  • L1 in content/docs/administration/organizations-teams/_index.md "frontmatter URL ? collides with ?" → 🚩 flagged (frontmatter: url-collision)
  • L1 in content/docs/administration/organizations-teams/teams.md "frontmatter URL ? collides with ?" → 🚩 flagged (frontmatter: url-collision)
  • L1 in content/docs/administration/security-compliance/_index.md "frontmatter URL ? collides with ?" → 🚩 flagged (frontmatter: url-collision)
  • L1 in content/docs/deployments/guides/oidc/_index.md "frontmatter alias /docs/administration/access-identity/oidc/ collides with content/docs/administration/guides/oidc-issuers/_index.md" → 🚩 flagged (frontmatter: alias-collision)
  • L1 in content/docs/deployments/guides/oidc/_index.md "frontmatter alias /docs/pulumi-cloud/oidc/ collides with content/docs/administration/guides/oidc-issuers/_index.md" → 🚩 flagged (frontmatter: alias-collision)
  • L50-53 in content/docs/administration/concepts/rbac/scopes.md "The 'Available scopes' list links to the four per-entity scope pages with relative link targets (stacks, environments, insights-accounts, org-settings)" → ⚔️ mismatch (evidence: relative targets resolve against this page's new URL, giving /docs/administration/concepts/rbac/scopes/stacks/ etc.; the four scope pages moved in this PR to /docs/administration/reference/rbac-scopes/*/, and the concepts/rbac/scopes/<name>/ URLs appear nowhere in the head sitemap; source: repo:content/docs/administration/reference/rbac-scopes/_index.md and .hugo-build.json sitemap_diff at d7c015f)
  • L21 in content/docs/administration/concepts/rbac/scopes.md "H2 headings 'How Scopes Work' (L21) and 'Default Role Assignments' (L38) are written in Title Case" → ⚔️ mismatch (evidence: AGENTS.md §Code & Content Rules requires H2+ headings in sentence case; sibling pages in the same directory use sentence case — ## Custom roles, ## Role assignment, ## Best practices in roles.md; source: repo:AGENTS.md and repo:content/docs/administration/concepts/rbac/roles.md)

🚨 Outstanding in this PR

These must be resolved or refuted before merging.

No outstanding findings in this PR.

⚠️ Low-confidence

Review each and resolve as appropriate — these don't block the PR.

  • [L33] content/docs/reference/cloud-rest-api/_index.md"Directly over HTTPS — pair an access token with the standard Accept and Content-Type headers and…" — verdict: unverifiable; the specific header requirements weren't confirmable from a public API reference. The access-token link itself is correct. Low stakes, but flagging since reference/_index.md now routes readers here as the programmatic-administration entry point.

📋 Triaged verifier findings

I double-checked these and realized they weren't real findings — click to expand (48 items)

Root cause for nearly all of these: the automated link check resolved each /docs/administration/… path against master, where the old tree still stands. Because this PR is the move, every destination it creates read as missing. Each path below was re-checked against the PR head tree (9ab16ba) and the head sitemap, and all of them exist. No action needed on any of them.

  • [L60] content/docs/administration/concepts/audit-logs.mdSpurious: content/docs/administration/guides/export-audit-logs/aws-s3.md exists at head and /docs/administration/guides/export-audit-logs/aws-s3/ is in the added-URLs list.
  • [L142] content/docs/administration/get-started/ways-of-working.mdSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L26] content/docs/administration/guides/_index.mdSpurious: /docs/administration/guides/least-privilege/ exists at head; only the description was being checked against the old location.
  • [L30] content/docs/administration/guides/_index.mdSpurious: the "Organization management" section carrying this Billing managers link was removed in an earlier commit on the branch; the file is 26 lines at head and the link is gone.
  • [L15] content/docs/administration/guides/customer-managed-keys/_index.mdSpurious: /docs/administration/concepts/customer-managed-keys/ exists at head.
  • [L143-144] content/docs/administration/guides/least-privilege.mdSpurious: /docs/administration/guides/oidc-issuers/github/ exists at head; the auth-actions behavior itself was read as accurate.
  • [L112] content/docs/administration/guides/scim/_index.mdSpurious: the Entra ID, Okta, and OneLogin SCIM guides all exist at head under guides/scim/.
  • [L46] content/docs/ai/_index.mdSpurious: /docs/administration/concepts/agent-accounts/ exists at head.
  • [L69] content/docs/ai/cli-for-agents/index.mdSpurious: same agent-accounts path; correct at head.
  • [L430] content/docs/ai/mcp-server/index.mdSpurious: same agent-accounts path; correct at head.
  • [L34] content/docs/ai/neo/code-reviews/_index.mdSpurious: /docs/administration/concepts/accounts/ exists at head; the diff on this line is a path rewrite only.
  • [L135-136] content/docs/ai/neo/permissions/_index.mdSpurious: /docs/administration/guides/least-privilege/ exists at head.
  • [L73] content/docs/ai/neo/usage-limits/_index.mdSpurious: billing managers moved to concepts/ on this branch and /docs/administration/concepts/billing-managers/ exists at head.
  • [L222] content/docs/ai/skills/index.mdSpurious: same agent-accounts path; correct at head.
  • [L84-85] content/docs/deployments/guides/customer-managed-workflow-runners.mdSpurious: /docs/administration/guides/oidc-issuers/kubernetes-gke/ exists at head.
  • [L25] content/docs/esc/administration/_index.mdSpurious: /docs/administration/reference/rbac-scopes/environments/ exists at head.
  • [L172] content/docs/esc/guides/environment-composition-patterns.mdSpurious: the reference/rbac-scopes/ segment is exactly the structure this PR introduces; the path exists at head.
  • [L33] content/docs/esc/guides/integrate-with/github-actions.mdSpurious: /docs/administration/guides/oidc-issuers/github/ exists at head.
  • [L117] content/docs/iac/_index.mdSpurious: /docs/administration/guides/least-privilege/ exists at head.
  • [L909] content/docs/iac/guides/basics/organizing-projects-stacks/_index.mdSpurious: roles.md carries an explicit anchor override, ##### Tag-based rules (ABAC) {#tag-based-abac-rules}, so #tag-based-abac-rules resolves.
  • [L66] content/docs/iac/guides/basics/pulumi-cloud-vs-oss.mdSpurious: /docs/administration/concepts/rbac/teams/ exists at head.
  • [L32] content/docs/iac/operations/_index.mdSpurious: /docs/administration/guides/least-privilege/ exists at head.
  • [L55] content/docs/iac/operations/continuous-delivery/_index.mdSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L68] content/docs/iac/operations/continuous-delivery/argocd.mdSpurious: both oidc-issuers/kubernetes-eks/ and oidc-issuers/kubernetes-gke/ exist at head.
  • [L72] content/docs/iac/operations/continuous-delivery/argocd.mdSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L164] content/docs/iac/operations/continuous-delivery/aws-code-services.mdSpurious: /docs/administration/guides/oidc-issuers/ exists at head; the description text was read as accurate.
  • [L56] content/docs/iac/operations/continuous-delivery/circleci.mdSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L146] content/docs/iac/operations/continuous-delivery/codefresh.mdSpurious: /docs/administration/guides/oidc-issuers/ exists at head.
  • [L60] content/docs/iac/operations/continuous-delivery/github-actions.mdSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L138] content/docs/iac/operations/continuous-delivery/octopus-deploy.mdSpurious: /docs/administration/guides/oidc-issuers/ exists at head.
  • [L26] content/docs/iac/operations/continuous-delivery/troubleshooting.mdSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L72] content/docs/insights/discovery/_index.mdSpurious: /docs/administration/concepts/rbac/ exists at head.
  • [L107] content/docs/integrations/clouds/kubernetes/pulumi-kubernetes-operator/installation.mdSpurious: the OIDC-issuer path referenced exists at head.
  • [L110] content/docs/integrations/clouds/kubernetes/pulumi-kubernetes-operator/installation.mdSpurious: the absolute https://www.pulumi.com/docs/administration/concepts/access-tokens/ reference-style link matches a page that exists at head; it will resolve once this PR ships.
  • [L81] content/docs/support/faq/pulumi-cloud.mdSpurious: /docs/administration/concepts/organizations/ exists at head.
  • [L100] content/docs/support/faq/pulumi-cloud.mdSpurious: path exists at head and organizations.md L117 is ## Transferring stacks, so #transferring-stacks resolves.
  • [L134] content/docs/support/faq/pulumi-cloud.mdSpurious: path exists at head and organizations.md L163 is ## Deleting your account, so #deleting-your-account resolves.
  • [L65] content/releases/agentic-infrastructure-era.mdSpurious: /docs/administration/concepts/agent-accounts/ exists at head.
  • [L391] content/tutorials/esc-managed-chatapp/index.mdSpurious: the only change on this line is the access-token link rewrite, and the new path exists at head; the ESC SDK open_and_read_environment description is untouched.
  • [L12] data/glossary.tomlSpurious: /docs/administration/concepts/audit-logs/ exists at head.
  • [L112] data/glossary.tomlSpurious: /docs/administration/guides/oidc-issuers/ exists at head.
  • [L117] data/glossary.tomlSpurious: /docs/administration/concepts/organizations/ exists at head.
  • [L302] data/glossary.tomlSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L727] data/pulumi_pricing.yamlSpurious: /docs/administration/concepts/organizations/ exists at head.
  • [L735] data/pulumi_pricing.yamlSpurious: /docs/administration/concepts/accounts/ exists at head.
  • [L798] data/pulumi_pricing.yamlSpurious: /docs/administration/concepts/access-tokens/ exists at head.
  • [L813] data/pulumi_pricing.yamlSpurious: /docs/administration/guides/export-audit-logs/aws-s3/ exists at head.
  • [L21-22] scripts/redirects/general-broken-links-redirects.txtSpurious: the S3 redirect target /docs/administration/guides/oidc-issuers/ exists at head.

Separately, the frontmatter sweep reported six url collisions rendered as `?` collides with `?` on access-identity/_index.md, access-identity/rbac/scopes.md, access-identity/stack-permissions.md, organizations-teams/_index.md, organizations-teams/teams.md, and security-compliance/_index.md. All six are files this PR deletes, and the collision report has no actual URL values in it. Environment artifact of the sweep seeing both trees at once; not reproducible against the head tree, which builds clean.


  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

💡 Pre-existing issues in touched files (optional)

  • [L172] content/docs/administration/concepts/access-tokens.md"To perform operations that require elevated access, such as creating or deleting stacks, you must explicitly request the admin scope when exchanging the OIDC token."Pre-existing: this PR's only change to the line is the access-identity/oidc-issuersguides/oidc-issuers rewrite; the sentence itself is unchanged. It's worth a separate look, though: the OIDC issuers guide documents scope solely as a way to name a target team or user (team:{TEAM_NAME} / user:{USER_LOGIN}), and doesn't define an admin value anywhere. Either the guide is missing a documented parameter or this sentence describes something that no longer works. Not a merge blocker for a restructure PR.
  • [L50] content/docs/administration/concepts/rbac/roles.md"To change the default role, you select a role and choose Actions > Set as organization default role in Pulumi Cloud."Pre-existing: untouched by this PR (the file's diff is entirely link-path rewrites and a menu-parent change). Flagging only because it reads as inconsistent with L57 on the same page, which routes the reader to Settings → Roles for the same setting. Worth reconciling in a follow-up.
  • [L1] content/docs/administration/guides/oidc-issuers/_index.mdPre-existing: the aliases /docs/pulumi-cloud/oidc/ and /docs/administration/access-identity/oidc/ are claimed by both this page and content/docs/deployments/guides/oidc/_index.md. Both alias lists carry them on master already — this PR only adds /docs/administration/access-identity/oidc-issuers/ here. Hugo resolves the duplicate silently, so the build is clean and one of the two pages simply never wins those URLs. Worth deciding which page should own them, in a follow-up.
  • [L1] content/docs/administration/guides/oidc-issuers/_index.mdPre-existing: second half of the same duplicate-alias pair described above.
  • [L1] content/docs/deployments/guides/oidc/_index.mdPre-existing: the other side of the /docs/administration/access-identity/oidc/ duplicate; present on master, untouched by this PR (its diff is a single prose line).
  • [L1] content/docs/deployments/guides/oidc/_index.mdPre-existing: the other side of the /docs/pulumi-cloud/oidc/ duplicate; same situation.

✅ Resolved since last review

Fixed in 9ab16ba:

  • [L50-53] content/docs/administration/concepts/rbac/scopes.md — the four Available scopes links were relative, so from the page's new URL they resolved to /docs/administration/concepts/rbac/scopes/<name>/, which doesn't exist. Resolved in 9ab16ba: all four now use full canonical /docs/administration/reference/rbac-scopes/… paths, introduced by a link to the catalog index. Re-verified against the head tree — _index.md, stacks.md, environments.md, insights-accounts.md, and org-settings.md are all present under content/docs/administration/reference/rbac-scopes/.
  • [L40] content/docs/administration/concepts/rbac/scopes.md"Many scopes are automatically granted through default roles"roles.md has no #default-roles anchor, and the link text was stale in the same way. Resolved in 9ab16ba: now [Pulumi-defined roles](/docs/administration/concepts/rbac/roles#pulumi-defined-roles). roles.md:39 is ## Pulumi-defined roles, so the anchor resolves and the link text matches the heading it lands on. Agreed on provenance — this was already broken on master; the move surfaced it rather than caused it. A repo-wide sweep at head finds no remaining #default-roles reference.
  • [L5] content/docs/administration/guides/_index.md — the meta_desc dropped Least privilege, which the page body still lists. Resolved in 9ab16ba. The revised line also shortens "SCIM provisioning" to "SCIM", which matches the body's own bullet label — fine either way.
  • [L32] content/docs/administration/concepts/_index.md — the Customer managed keys card summarized CMK as protecting data at rest generally, where the target page scopes it to Pulumi ESC with AWS KMS. Resolved in 9ab16ba; the bullet now carries the "currently for Pulumi ESC with AWS KMS" qualifier.
  • [L21] content/docs/administration/concepts/rbac/scopes.md## How Scopes Work and ## Default Role Assignments were Title Case, against the AGENTS.md H2+ sentence-case rule. Resolved in 9ab16ba; both are sentence case at head.
  • Author-found, same class — the previous review missed this one. content/docs/administration/concepts/rbac/roles.md linked access-tokens/#organization-access-tokens, but that heading carries an explicit {#creating-an-organization-access-token} override, so the fragment never resolved. Fixed in 9ab16ba and verified: access-tokens.md:61 is ## Organization access tokens {#creating-an-organization-access-token}. Also pre-existing, as you say. Good catch — a sweep at head confirms the only surviving #organization-access-tokens reference is in content/blog/short-lived-access-tokens/index.md, which is historical and out of scope here.

Accepted as-is by @jkodroff — inherited text this PR only link-rewrote:

  • [L127] content/docs/administration/concepts/access-tokens.md — expiry-policy banner and Edit policy shortcut (unverifiable console UI). concede: author accepts as-is; out of scope for a re-shelving PR.
  • [L57] content/docs/administration/concepts/rbac/roles.mdSettings → Access management → Roles navigation path (unverifiable console UI). concede: author accepts as-is; out of scope for a re-shelving PR. The L50/L57 inconsistency stays flagged under 💡 for the follow-up.
  • [L60] content/docs/administration/concepts/rbac/roles.md — organization-wide role settings framed as a pre-RBAC "leftover". concede: author accepts as-is; out of scope for a re-shelving PR.
  • [L161] content/docs/administration/concepts/rbac/roles.md — hedging across "tag rules" / "tag-based access control rules". concede: author accepts as-is; out of scope for a re-shelving PR.
  • [L98] content/docs/administration/get-started/choose-edition.md — the signup identity-provider list (email/password, GitHub, GitLab, Atlassian). concede: author accepts as-is; out of scope for a re-shelving PR.
  • [L113] content/docs/administration/guides/saml/jumpcloud.md — the JumpCloud "Integrate with Pulumi" outbound link. concede: author accepts as-is; out of scope for a re-shelving PR.
  • [L22] content/docs/administration/reference/rbac-scopes/insights-accounts.md — the sentence promises list/restore scopes in the org-settings table, which documents only insights_account:create. concede: author accepts as-is; out of scope for a re-shelving PR.
  • [L55] content/docs/iac/operations/continuous-delivery/octopus-deploy.md — the Octopus Deploy 2025.1 version floor. concede: author accepts as-is; out of scope for a re-shelving PR.
  • [L108] content/docs/support/faq/pulumi-cloud.md — "this confirms the user is not an organization admin" read as proof rather than a thing to check. concede: author accepts as-is; out of scope for a re-shelving PR.

📜 Review history

  • 2026-08-21T19:55:47Z — Build and aliases are clean across the move; two real breaks in concepts/rbac/scopes.md (relative "Available scopes" links, #default-roles anchor), and ~48 reported missing paths were re-checked against the PR head and are fine. (d7c015f)
  • 2026-08-21T21:57:12Z — re-reviewed after fix push (2 new commits, 9ab16ba). Both outstanding findings verified fixed against the head tree; three low-confidence items taken and verified; nine accepted as-is by @jkodroff and conceded on scope. The author-found third anchor break (roles.mdaccess-tokens/#organization-access-tokens) was confirmed real, confirmed pre-existing, and confirmed fixed. Independently checked the deliberate omission: the seven relative links in guides/saml/_index.md (sso/, entra/, gsuite/, jumpcloud/, okta/, auth0/, onelogin/) all still resolve, because those pages are children of the directory and it moved intact — deferring the absolute-path conversion to Administration IA phase 3: Split the mixed concept/guide pages and write the landing pages #21054 is safe. The only other relative-link cluster left under content/docs/administration/ is in self-hosting/deployment-options/_index.md, and it resolves for the same reason. Outstanding: 0. (9ab16ba)

  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions github-actions Bot added review:outstanding-issues Claude review completed; outstanding has author-actionable findings and removed review:in-progress Claude review is currently running labels Aug 21, 2026
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@github-actions github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention and removed review:outstanding-issues Claude review completed; outstanding has author-actionable findings labels Aug 21, 2026
Mandatory:

- concepts/rbac/scopes.md used bare relative links ([Stacks](stacks)) for the
  four scope tables. Those resolved from the page's old URL but not its new
  one, and the tables moved to reference/rbac-scopes/ regardless. Now full
  canonical paths, per AGENTS.md.
- concepts/rbac/scopes.md linked roles#default-roles; that heading is
  "Pulumi-defined roles". Pre-existing on master, surfaced by the move.
  Fixed the anchor and the stale link text together.

Found while auditing the same class of problem:

- concepts/rbac/roles.md linked access-tokens#organization-access-tokens, but
  that heading carries an explicit {#creating-an-organization-access-token}
  override. Also pre-existing.

Low-confidence findings that were safe to take:

- Restored "and least privilege" to the guides meta_desc, dropped by mistake
  when billing managers moved to concepts.
- Scoped the concepts CMK bullet to "currently for Pulumi ESC with AWS KMS",
  matching what the target page actually says.
- concepts/rbac/scopes.md H2s to sentence case, per AGENTS.md. Nothing links
  to the old anchors.

All 128 links and anchors into /docs/administration/ verified against the
built site.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012VLSi7rdf7rrDaHm9rNd8c
@jkodroff

Copy link
Copy Markdown
Member Author

@claude #update-review

Both outstanding findings are fixed at 9ab16ba, plus a third of the same class that the review didn't catch.

Mandatory

  • concepts/rbac/scopes.md "Available scopes" — the four bare relative links now use full canonical paths under /docs/administration/reference/rbac-scopes/, with a link to the catalog index. Took the suggested fix as written.
  • concepts/rbac/scopes.md #default-roles — now [Pulumi-defined roles](…/roles#pulumi-defined-roles). Confirmed this was already broken on master; the move surfaced it rather than causing it.

Found by auditing the same class

  • concepts/rbac/roles.md linked access-tokens/#organization-access-tokens, but that heading carries an explicit {#creating-an-organization-access-token} override, so the fragment never resolved. Also pre-existing. Fixed.

I then validated every internal link and anchor into /docs/administration/ against the built site — 128 links, all resolving.

Low-confidence, taken

  • Restored "and least privilege" to the guides/_index.md meta_desc. Correct call — that was dropped by mistake when billing managers moved to concepts/.
  • Narrowed the CMK bullet on concepts/_index.md to "currently for Pulumi ESC with AWS KMS", matching what the target page states.
  • concepts/rbac/scopes.md H2s to sentence case per AGENTS.md, after confirming nothing links to the old anchors.

Low-confidence, not taken — accepted as-is by the author

The remaining items are all inherited text this PR only link-rewrote: the console UI claims in access-tokens.md L127 and roles.md L57/L161, the signup identity-provider list in choose-edition.md L98, the pre-RBAC "leftover" framing in roles.md L60, the JumpCloud vendor link, the insights-accounts.md L22 scope-table mismatch, the Octopus 2025.1 version floor, and support/faq/pulumi-cloud.md L108. Out of scope for a re-shelving PR; not blocking.

One deliberate omission: guides/saml/_index.md has seven relative links of the same shape that broke scopes.md. They still resolve because that directory moved intact. Folding the conversion into phase 3 (#21054) rather than widening this diff.

@github-actions github-actions Bot added review:in-progress Claude review is currently running and removed review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention labels Aug 21, 2026
@github-actions

Copy link
Copy Markdown
Contributor

🤖 Review updated on @jkodroff's request.

@github-actions github-actions Bot added review:no-blockers Claude review completed cleanly; outstanding is empty and removed review:in-progress Claude review is currently running labels Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain:docs PR touches technical docs review:no-blockers Claude review completed cleanly; outstanding is empty

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Administration IA phase 1: Re-shelve the SaaS side into get-started / concepts / guides / reference

2 participants