fix(auth): accept canonical TrustSignal API key in production

[chrismaz11]

Summary

• accept TRUSTSIGNAL_API_KEY as a canonical production auth source without duplicating it in API_KEYS
• add optional TRUSTSIGNAL_API_KEY_SCOPES with safe verify|read defaults for the single-key path
• document the production env contract and add regression coverage for security config resolution

Security Review

• auth logic changed in apps/api/src/security.ts
• the new path reduces secret drift between GitHub Actions and backend allowlists for the common single-key deployment
• default canonical scopes are constrained to verify|read; broader scopes still require explicit configuration
• no new runtime dependencies were added

Dependencies

• none

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
trustsignal	Ready	Preview, Comment	Mar 24, 2026 5:28am

[Copilot]

Pull request overview

This PR updates the API security configuration to support a canonical production API key env var (TRUSTSIGNAL_API_KEY) without requiring duplication in API_KEYS, with constrained default scopes and regression coverage to prevent misconfiguration.

Changes:

• Extend buildSecurityConfig to accept TRUSTSIGNAL_API_KEY, with default canonical scopes of verify|read and optional override via TRUSTSIGNAL_API_KEY_SCOPES.
• Add Vitest coverage for production auth env resolution (canonical key path, scope overrides, and fail-fast behavior).
• Document the new production env contract in .env.example and README.md.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
apps/api/src/security.ts	Adds canonical key env support and pipe-delimited scope parsing with safe defaults.
tests/api/security-config.test.ts	Adds regression tests for production security config resolution with the canonical key.
apps/api/.env.example	Documents canonical single-key env configuration and scope defaults.
README.md	Documents recommended production configuration for the public verification surface.
.github/workflows/main.yml	Adds a new workflow file (currently a push-triggered placeholder job).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This workflow appears unrelated to the PR’s stated auth/env changes and currently only runs an echo placeholder on every push to master. If it’s not meant to provide real CI/verification yet, consider removing it from this PR (or switching it to workflow_dispatch only) to avoid adding a permanently-noop job that still consumes Actions capacity and can confuse release/CI signals.

[Copilot]

Workflow name is set to the file path (.github/workflows/main.yml), which is inconsistent with the descriptive names used in other workflows (e.g., "TrustSignal CI", "AI PR Review Gate"). Consider renaming it to a short human-readable label so it’s clear in the GitHub Actions UI what this workflow represents.

Suggested change

	name: .github/workflows/main.yml
	name: TrustSignal Artifact Verification

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1ad6d2d3cf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Run real artifact verification in verify-artifact job

The verify-artifact workflow step currently only echoes a placeholder string, so this job will pass even when artifact verification is broken or missing. On push to master, that creates a false-positive CI signal for a security-sensitive control and weakens the auditability this workflow name implies.

Useful? React with 👍 / 👎.