Workflows accept the project secret API key, so CI pushes without a personal key

[Silthus]

Part of #68. Locked by Michael on 2026-09-22 after the research on #104: v1 pushes from CI with the project secret API key (PSAK) that already exists on the project, not with a personal API key.

What to build

HogFlowViewSet accepts a project secret API key (phs_..., Authorization: Bearer) for the actions a push needs: list (the ?key= resolve), retrieve, create, update and partial_update. Nothing else: no delete, no bulk delete, no publish or invocation actions. Follow the skill adding-project-secret-api-key-auth exactly: the hog_flow scope joins the PSAK scope allowlist, the viewset gets the PSAK authenticator, psak_allowed_actions, and a PSAK-aware throttle, in the shape products/feature_flags/backend/api/feature_flag.py and products/endpoints/backend/presentation/views/api.py already use.

A PSAK request carries a synthetic user (ProjectSecretAPIKeyUser). Find every place the create and update paths assume a real user and make them hold: created_by on HogFlow, created_by on HogFlowRevision, log_activity_from_viewset, _report_workflow_action, and the _emit_resource_edited call. Store None where the model allows it and say so in the activity detail; never crash and never invent a user.

Compatibility with the read-only PR (PostHog/posthog#103540): its guard is_code_managed_writer classifies by User-Agent event source, so a PSAK request from the CLI (posthog-workflows/<version>, event source api) passes unchanged. State this in the PR body; do not touch that branch.

Write scope

• products/workflows/backend/api/hog_flow.py
• The PSAK scope allowlist module the skill names
• products/workflows/backend/api/test/test_hog_flow_psak_auth.py (new)
• products/workflows/CONTRIBUTING.md (one paragraph on which key a CI push may use)

Proof gate

• Red: POST, PATCH and GET ?key= with a phs_ key return 401 or 403 before the change; green after, with the key echoed and the row created with created_by null
• A PSAK DELETE and a PSAK POST .../bulk_delete stay refused
• A PSAK for team A cannot read or write team B's workflow
• Revision 1 is written on a PSAK create with created_by null (depends on fix(workflows): write the first revision when a workflow is created PostHog/posthog#104156; if that is not on upstream/master yet, assert the update path's revision instead and say so)
• hogli test products/workflows/backend/api/test/ green, ruff, repo-wide mypy
• hogli build:openapi output in the diff if the schema changed
• hogli ci:preflight --strict on push

Blocked by

Nothing.

Stack base and ship target

• Branch feat/workflows-psak-auth cut from upstream/master.
• A draft PR against upstream PostHog/posthog, --head Silthus:feat/workflows-psak-auth. It stays a draft until Michael says otherwise. Nothing merges into the fork's master.
• Invoke adding-project-secret-api-key-auth, improving-drf-endpoints, writing-tests, writing-code-comments, reviewing-with-coderabbit and writing-pr-descriptions.

[Silthus]

Claimed by worker wf68-106-implement (Claude Fable 5.1), 2026-09-22.

[Silthus]

Proof bundle (worker wf68-106-implement)

Branch feat/workflows-psak-auth, cut from upstream/master at 17a27588b77. Head 80e19375bd7 (two commits: the feature 428f50c1f35, then the review fixes 80e19375bd7).

Gate	Result
Red	products/workflows/backend/api/test/test_hog_flow_psak_auth.py run before the viewset change: every phs_ request (POST, PATCH, GET list, GET detail) returned 401 authentication_failed; 12 of 13 cases failed, 1 errored on the same 401.
Green	Same file after the change: 14 passed (13 plus the AI task case added after review). Create returns 201 with created_by: null in the body and created_by_id null on the row.
PSAK DELETE and bulk_delete refused	Both 403 with "This action does not support project secret API key access", row still present. Same for publish, invocations and revisions/1/restore (parameterized). The adversarial pass hit all 32 other routes: 403 each.
Cross-team	A key minted for team B gets 403 on team A's list, retrieve, PATCH and POST; team A's row is unchanged and no row is created. A key on a second environment of the same project sees nothing (adversarial pass).
Revision with created_by null	PostHog#104156 (first revision on create) is not on upstream/master, so the update path is asserted instead: a PSAK PATCH of actions bumps version to 2 and writes HogFlowRevision v2 with created_by_id null.
GET ?key=	The key column is not on upstream/master (it lands with PostHog#103849), so list is asserted; the filter param is inert until that PR merges.
Scope	hog_flow:read key lists (200) but cannot create (403); a feature_flag:read key gets 403 on both. Write implies read, so one hog_flow:write key covers the push.
Activity log	PSAK create and update write an ActivityLog row with user null, is_system true, and detail.trigger = {job_type: "project_secret_api_key", job_id: <key id>, payload: {label}}. Without the change the shared helper raised on the synthetic user and swallowed it, so no row was written.
Throttle	With rate limiting enabled and rate patched to 1/minute: a second request with the same key is 429 (per key), and a second request with a different key of the same project is 429 (per project). Session and personal-key buckets unchanged (adversarial pass).
hogli test products/workflows/backend/api/test/	783 passed after the review fixes (782 before the added case).
posthog/test/test_scopes.py	145 passed (frontend and backend allowlists in sync).
ruff, repo-wide mypy	ruff clean; mypy --cache-fine-grained .: "No issues found".
oxfmt, oxlint on frontend/src/lib/scopes.tsx	Clean.
hogli build:openapi	Not run: no serializer field changed, so the schema is unchanged.
hogli ci:preflight --strict	Ran on the first push: 18 checks triggered, 0 failures, mode strict. Runs again on the second push.

What changed

• posthog/scopes.py and frontend/src/lib/scopes.tsx: hog_flow:read and hog_flow:write join the PSAK allowlist. Read alone serves a compare-only job.
• products/workflows/backend/api/hog_flow.py: ProjectSecretAPIKeyAuthentication, psak_allowed_actions = ["list", "retrieve", "create", "update", "partial_update"], four PSAK-aware throttles (same burst/sustained budgets as the defaults, plus per-project aggregates; the experiments viewset shape).
• Synthetic user made safe on the write paths: HogFlowSerializer.create and _append_revisions store a real User or None through one _actor(request) helper. A new _log_activity on the viewset writes a system audit row with the key in the trigger for PSAK requests and delegates to log_activity_from_viewset otherwise. _emit_resource_edited and _report_workflow_action were already safe.
• products/workflows/CONTRIBUTING.md: "Pushing a workflow from CI".

No migration.

Adversarial review (fresh general-purpose agent, Claude, 50 throwaway cases)

#	Finding	Severity	Disposition
1	Scope escalation: every route outside the five, including dual-method actions, mixin actions, non-detail PATCH/PUT and the /api/environments/ alias, returns 403.	no-issue	Accepted.
2	update lets the key activate, archive and replace the live graph of an active workflow (no stage_draft). Same as a personal key with hog_flow:write; new only in that the credential survives offboarding and skips per-object RBAC like every PSAK. CONTRIBUTING overclaimed what the key cannot do.	should-fix	Fixed: CONTRIBUTING and the PR body state it. Not blocked: minting a key needs project admin, and blocking status writes would break the CLI's status in source.
3	Cross-team: team binding, environment binding, ?token= swap and referenced-object lookups all hold. Generic integration ids have no ownership check at save, pre-existing and identical for personal keys.	no-issue	Accepted; pre-existing item noted for the workflows team.
4	A key-created workflow with a "Create AI task" step validated (skills check skipped because workflow_owner_id is None) and then failed on every fire with "no owner".	should-fix	Fixed: _validate_create_task_action now refuses the step with a 400 when the request has no user and the flow has no creator. New test case.
5	Throttles apply to every action, PSAK buckets are per key and per project, headers cannot pick a bucket, session and personal-key buckets unchanged.	no-issue	Accepted.
6a	changes_between in the PSAK audit branch ran outside a try; a raise there would 500 after the row saved.	nit	Fixed: the PSAK audit write is wrapped and logged, same contract as the shared helper.
6b	The activity feed labels every system row "PostHog" and no describer reads trigger.payload.label, so a key's push reads "PostHog updated the workflow".	nit	Accepted as a follow-up: rendering the label needs a describer change in the frontend, outside this ticket's write scope. Noted in the PR body.
7	List and retrieve return the same fields as a personal key; secrets masked.	no-issue	Accepted.
8	API_SCOPES already has the hog_flow row; the picker renders the two scopes.	no-issue	Accepted.

Pending for the human

The PR is a draft at PostHog#104202 (head 80e19375bd7, five files: frontend/src/lib/scopes.tsx, posthog/scopes.py, products/workflows/CONTRIBUTING.md, products/workflows/backend/api/hog_flow.py, products/workflows/backend/api/test/test_hog_flow_psak_auth.py). The assignee could not be set from the fork account (upstream permissions), so the DRI is named in the body only. Should the PR be marked ready for review?

[Silthus]

Modernizing PostHog#104202: old head 0344409ec1ede1dbe8521e40a958094785bbb628 (restore with git push --force-with-lease silthus 0344409ec1ede1dbe8521e40a958094785bbb628:feat/workflows-psak-auth).

[Silthus]

Modernized PostHog#104202

• Old head: 0344409ec1ede1dbe8521e40a958094785bbb628
• New head: 06b4757e7d47a063ce9c7cf81c74030b152dccfa
• Based on: origin/master 1c66a26fd9f969905a64bc564e302f70bee1736d, through fix(workflows): write the first revision when a workflow is created PostHog/posthog#104156's modernized head 417ffc559cd
• Mergeable: MERGEABLE (was CONFLICTING). The PR is still ready for review, not a draft.

Commit list

#	sha	commit
1	737e5eca946	fix(workflows): write the first revision when a workflow is created (PostHog#104156, unchanged)
2	afb379f23bb	fix(workflows): store null action defaults so a resave keeps one revision (PostHog#104156, unchanged)
3	5c6a44bf4f4	fix(workflows): resolve each template once when snapshotting a revision (PostHog#104156, unchanged)
4	417ffc559cd	chore(workflows): drop comments added in this pr (PostHog#104156, unchanged)
5	8cb3886b8fb	feat(workflows): accept the project secret api key on the workflows endpoint (was 6b4eceb2e18)
6	3bd410d545b	fix(workflows): refuse an ownerless ai task step on a project key create (was 9c83fe6f2aa)
7	06b4757e7d4	chore(workflows): drop comments added in this pr (was 0344409ec1e)

The old carried copies (ec72ce0786d, 28e309ad545, accd1747276) are dropped. No modernization fix-up commit was needed.

What conflicted and how it was adapted

• Viewset move (chore(workflows): add facade and route callers through it PostHog/posthog#107597): the edits moved from products/workflows/backend/api/hog_flow.py to products/workflows/backend/presentation/views/hog_flow.py. Rename detection applied most hunks. The two conflicts were in perform_create and around _revision_author. fix(workflows): write the first revision when a workflow is created PostHog/posthog#104156 had landed _revision_author() for the first revision, and this PR replaces it with module-level _actor(request). The resolution keeps _actor and drops _revision_author, as the old PR did.
• Test move: products/workflows/backend/api/test/test_hog_flow_psak_auth.py became products/workflows/backend/tests/api/test_hog_flow_psak_auth.py. Imports now point at presentation.views.hog_flow and tests.api.test_hog_flow, and the gated_template_enabled patch target moved with them. hash_key_value now comes from posthog.models.utils.
• Scope allow-list: still PROJECT_SECRET_API_KEY_ALLOWED_API_SCOPE_ACTION in posthog/scopes.py and frontend/src/lib/scopes.tsx. Both applied cleanly.
• Master's credential attribution (feat(activity-log): record the credential behind each change PostHog/posthog#105540, feat(activity-log): require a credential type on each auth class PostHog/posthog#107173): ProjectSecretAPIKeyAuthentication now records credential_type=project_secret_key and the key id on each activity row. This does not replace the PR's _log_activity, because log_activity_from_viewset still passes the synthetic user to the user column and swallows the error. The rows now carry both the PR's trigger (the key label, which users can see) and master's credential fields (internal). No change was made.
• There is no migration, so nothing was renumbered.

Tests and gates

Tests, preflight, semgrep, openapi, mypy

hogli test products/workflows/backend/tests/api/test_hog_flow_psak_auth.py
  14 passed in 54.00s
hogli test products/workflows/backend/tests/api/ posthog/test/test_scopes.py posthog/test/test_permissions.py -- -n 4
  1098 passed in 45.32s
hogli ci:preflight --strict   (also ran as the pre-push hook)
  summary {"changed_files": 6, "failures": 0, "mode": "strict"}   warnings only: complexity/size of hog_flow.py
uvx semgrep --config .semgrep/rules/devex/ --config .semgrep/rules/security/ --baseline-commit 1c66a26fd9f <4 changed files>
  Ran 96 rules on 4 files: 0 findings.
hogli build:openapi
  no diff
uv run mypy --cache-fine-grained .
  Success: no issues found in 22016 source files

End-to-end on the local stack (wfy_106, :8108, from wfy_kit)

Requests and responses (trimmed)

## GET /api/projects/7980001/hog_flows/   Authorization: Bearer phs_…   (this branch)
HTTP 200
{"count":2,"names":["wfy kit smoke 2","wfy kit smoke"]}
## POST /api/projects/7980001/hog_flows/   Authorization: Bearer phs_…   (this branch)
HTTP 201
{"id":"01a0f0ec-5bf2-…","name":"psak e2e 104202","status":"draft","version":1,"created_by":null}
## PATCH /api/projects/7980001/hog_flows/<id>/   {"name":"psak e2e 104202 renamed"}
HTTP 200
## DELETE /api/projects/7980001/hog_flows/<id>/   (not an allowed action)
HTTP 403 {"detail":"This action does not support project secret API key access"}
## Activity log rows (activity | user_id | is_system | credential_type | trigger.job_type)
created |  | t | project_secret_key | project_secret_api_key
updated |  | t | project_secret_key | project_secret_api_key

## GET /api/projects/7980001/hog_flows/   same phs_ key, master's viewset (read-only GET on another kit stack, :8105)
HTTP 401 {"detail":"Personal API key found in request Authorization header is invalid."}

The stack is down again (down.sh wfy_106). Its databases are kept.

Reviewer (fresh Opus sub-agent: range-diff plus final diff against master)

"No lost or duplicated behavior." Every hunk landed at the equivalent place in the moved viewset. None of the findings is a bug:

1. Risk, minor, from master: Loops' last_run lookup gets user_id=None for a key request. A key's list or retrieve can therefore show last_run: null where a person sees their own private run. This affects Loops-origin flows only. Accepted: it is the correct result for a principal with no user.
2. Nit: the trigger's job_id repeats master's credential_id. There is still one row per write, and the trigger label is the only attribution a user can see. No change.
3. Nit, predates the rebase: the PSAK trigger suppresses master's agent trigger on those rows. No change.

PR body change

• The test paths now read products/workflows/backend/tests/api/….
• The line "Not run: hogli build:openapi … and any manual test against a running stack" is replaced with the local stack result and the openapi result.
• One Agent-context bullet was added for this rebase.

For PostHog#103540

Take exactly the 7 commits above, ending at 06b4757e7d4. The PSAK edits live in products/workflows/backend/presentation/views/hog_flow.py, and _revision_author is gone in favor of module-level _actor(request).

Full logs: /home/coder/dev/wf-yaml-conductor/proof/modernize-104202/.

[Silthus]

Modernizing PostHog#104202: old head 06b4757e7d47a063ce9c7cf81c74030b152dccfa (restore with git push --force-with-lease silthus 06b4757e7d47a063ce9c7cf81c74030b152dccfa:feat/workflows-psak-auth).

[Silthus]

Modernized PostHog#104202

• Old head: 06b4757e7d47a063ce9c7cf81c74030b152dccfa (on master 1c66a26fd9f)
• New head: 44120afbee77eaf3cede1aac16e6b3790c39c133
• Based on origin/master ccf607f06fabbe0a79f45713a195d07bf02931a9
• GitHub now reports the PR MERGEABLE. It stays ready for review.

How it was rebuilt

• fix(workflows): write the first revision when a workflow is created PostHog/posthog#104156 was still MERGEABLE, so it was not touched. Its 4 commits (737e5eca946, afb379f23bb, 5c6a44bf4f4, 417ffc559cd) were cherry-picked onto master unchanged, then feat(workflows): accept the project secret api key on the workflows endpoint PostHog/posthog#104202's own 3 commits on top. Linear history, 7 commits.
• The conflict: master (feat(workflows): opt a single workflow in to suggestions PostHog/posthog#91795) already added User to from posthog.models import Team in presentation/views/hog_flow.py, which fix(workflows): write the first revision when a workflow is created PostHog/posthog#104156's first commit also added. The cherry-pick dropped that now-redundant import change. Master also added support_ticket:read to the project key scope lists (feat(conversations): accept project secret API key on ticket GET PostHog/posthog#107942), right next to the PR's hog_flow:read and hog_flow:write lines. Both auto-merged.
• No code adaptation was needed. The range-diff shows only context-line changes in commits 1 and 5. No migration. No PR body change.

Verification

Tests and gates

• pytest (own DB test_p1a_r3, --create-db): test_hog_flow_psak_auth.py + test_hog_flow_revisions.py: 33 passed.
• pytest products/workflows/backend/tests/api/: 856 passed.
• Diff-aware semgrep (devex + security, baseline ccf607f06fa): 0 findings.
• uv run mypy --cache-fine-grained .: no issues in 22191 source files.
• hogli build:openapi: no diff.
• hogli ci:preflight --strict: 0 failures (complexity and size warnings only, as on master). The pre-push hook passed too.
• Kit stack wfy_106 on :8108 (--from wfy_kit), with the phs_ key: list 200, create 201 (created_by: null), patch 200, delete 403 (This action does not support project secret API key access). The activity log shows system created and updated rows with trigger project_secret_api_key. One revision was written with a null author. The stack is down again.

Review

A fresh Opus reviewer read the range-diff and the final diff against master. It found nothing lost, duplicated or changed:

• New master code on create, update, list and retrieve does not read request.user in a way that breaks under the key.
• The new optimization and batch_jobs actions are outside psak_allowed_actions.
• HogFlowRevision is still written only through _append_revision.
• The backend and frontend scope lists match.

Logs: proof/modernize-104202/r3/.