GPT Review — G8B-Token Provisioning Prompt v0.1

Date: 2026-04-29

Verdict

NOT READY — patch to v0.2 required before User GO.

The re-verify report is PASS and G8B-RP can now be treated as evidence-hardened. However, G8B-Token v0.1 is too risky to execute as written because it handles secrets and proposes live TAC data mutation for access tests.

Confirmed input

Read-only reverify log checked:

knowledge/dev/laws/dieu38-trien-khai/reports/p9-g8b-rp-readonly-reverify-2026-04-29.md

Accepted:

• 2 roles exist.
• 2 policies exist with admin_access=false, app_access=false, enforce_tfa=false.
• 2 access bindings exist.
• 84 permission tuples match full matrix with missing=0 and extra=0.
• Gate A/B/C unchanged.
• Secret scan PASS.

Law / constitutional check

G8B-Token is allowed in principle, but v0.1 has blockers.

• Hiến pháp / Zero Trust: v0.1 still assumes some user/token creation payload behavior and safe storage fallback.
• Điều 33 / PG SSOT: v0.1 proposes test writes into tac_lu_lifecycle_vocab; this mutates governed seed data even if later deleted.
• Điều 38 / LSL-01: token provisioning supports governed access, but must not dirty information-unit/vocab/config data.
• Secret hygiene: v0.1 risks token/password exposure via inline curl -d payloads and fallback plaintext VPS files.
• Gate separation: token gate must not perform TAC data mutation or broaden roles/permissions.

Required v0.2 patches

Patch 1 — No TAC data mutation for tests

Remove admin CRUD test that creates/deletes a row in tac_lu_lifecycle_vocab.

Gate C seeded vocab/config rows are controlled governance data. Even temporary API writes are not acceptable in this token gate.

Use safer verification:

• token authenticates via /users/me or another safe self endpoint;
• token can read allowed TAC collection, e.g. GET /items/tac_lu_lifecycle_vocab;
• negative tests remain allowed if they are denied before mutation, e.g. agent create vocab expected 403;
• do not require admin positive write test against TAC data in this gate.

If a future end-to-end write test is required, design a separate test-data gate with explicit cleanup/rollback and User approval.

Patch 2 — GSM must be primary; VPS file fallback cannot be automatic

G8A/Tier3 expects GSM token provisioning. v0.1 allows automatic fallback to /opt/incomex/secrets/ plaintext files.

v0.2 must:

• probe GSM/gcloud availability first;
• if GSM available, store tokens there using approved secret names;
• if GSM unavailable, STOP and report unless User explicitly authorizes VPS-file fallback;
• do not silently downgrade to VPS file storage.

Patch 3 — Secret handling must avoid command-line leakage

v0.1 passes token/password inside inline curl JSON. This can expose secrets through process args, shell logs, debug output, or captured command traces.

v0.2 should:

• build JSON payloads in mktemp files with chmod 600, or use a node script reading secrets from environment and not printing them;
• never echo full token/password;
• never log response bodies that may contain token values;
• delete temp payload files after use;
• action log should include only masked token suffix and user IDs.

Patch 4 — Stronger API/payload discovery before POST

v0.1 checks keys from /users?limit=1, but that does not prove POST-required fields or whether token can be set at creation.

v0.2 should add explicit discovery:

• verify /users POST behavior from current Directus version using documented/reference pattern or inspect existing agent registry pattern;
• verify whether static token is settable at create or requires PATCH after user creation;
• if Directus response rejects token at create, do not improvise beyond pre-defined fallback: create user then PATCH token only if user was created by this run and payload shape is verified;
• if shape remains uncertain, STOP.

Patch 5 — Existing users/idempotency must be exact and safe

v0.1 uses _starts_with=tac-. v0.2 should classify exact target emails:

• tac-agent@incomex.local
• tac-admin@incomex.local

Rules:

• exact existing and role/token status matches target → skip or rotate only if explicitly authorized;
• partial existing user → STOP;
• unknown tac-* users → report but do not touch unless target conflict;
• no blanket delete.

Patch 6 — Token test expectations should be auth-focused, not full permission-suite

Since G8B-RP already verified the 84-permission matrix, token gate should prove the users/tokens bind to correct roles/policies.

Required tests:

• each token authenticates as intended user via safe endpoint;
• each user has correct role;
• agent token can read vocab;
• agent token cannot create vocab;
• agent token cannot delete core;
• admin token can read all 14 TAC collections or at least a deterministic subset/all read test.

Do not test admin create/update/delete against production TAC tables in v0.2.

Index update assessment

Index update to mark G8B-RP PASS and G8B-Token/G11 pending is acceptable if it reflects:

• G8B-RP PASS;
• G8B-Token pending;
• full G8 pending;
• G11 pending.

Do not mark full G8 PASS yet.

Directive to Opus 4.6

Patch G8B-Token v0.1 → v0.2 with the six required patches above.

Do not request Agent execution yet. Return v0.2 for GPT final review.

No TAC data mutation, no automatic VPS plaintext fallback, no G11, no Nuxt, no corpus migration.