What happened
On PR #4574, the code agent added security-sensitive fields (caData, skipTLSVerify, apiKey) to the ogx-entity-provider plugin but omitted @visibility backend annotations in its config.d.ts. The review agent flagged this as a medium-severity secrets-exposure finding (review run 34520203260). The fix agent addressed it in commit 03280e5, adding the missing annotations.
The boost workspace AGENTS.md has a detailed "Adding new config fields" section (lines 136–160) that explicitly requires @visibility annotations, but it is scoped to plugins/boost-backend/config.d.ts and the centralized Zod schema system. Independent entity provider packages (ogx-entity-provider, kagenti-entity-provider) maintain their own config.d.ts files outside this system, so the code agent did not apply the guidance when working on ogx-entity-provider.
The review agent also noted that the ogx-entity-provider config.d.ts only declared 4 of the ~9 fields that readOgxEntityProviderConfig actually reads, and flagged isValidPem as duplicated from boost-connector-utils/src/ca-bundle.ts rather than reused.
What could go better
The code agent could have gotten the config.d.ts right on the first attempt if the AGENTS.md guidance covered all packages that declare config fields, not just boost-backend. This would have avoided the review finding, the fix agent iteration to add annotations, and the subsequent re-review — saving approximately one review-fix cycle (~$10–12 in agent costs).
Confidence: high. The code agent demonstrably reads and follows the boost AGENTS.md "Adding new config fields" section (the initial PR included a changeset, config examples, and API report updates as that section instructs for boost-backend). Extending its scope to entity provider packages is straightforward and directly addresses the gap.
Proposed change
In workspaces/boost/AGENTS.md, below the existing "Adding new config fields" section (after line 160), add a subsection:
### Config declarations in entity provider packages
The `ogx-entity-provider` and `kagenti-entity-provider` packages each
maintain their own `config.d.ts` (they do not use the centralized Zod
schema system in `boost-backend`). When adding or modifying config
fields in these packages:
1. Declare **every** field that the package's config reader function
reads (e.g., `readOgxEntityProviderConfig`) in the package's
`config.d.ts`. Backstage uses `config.d.ts` for config validation
and visibility enforcement — undeclared fields bypass both.
2. Add `@visibility backend` to any field that holds secrets or
security-sensitive data (API keys, certificates, TLS bypass flags).
Add `@visibility secret` to fields that must never appear in
frontend config (e.g., `apiKey`).
3. Check `boost-connector-utils` for reusable TLS and HTTP utilities
(`isValidPem`, `createHttpsAgent`, `safeGetOptionalString`) before
implementing equivalents locally.
Validation criteria
The next code agent PR that adds or modifies config fields in ogx-entity-provider or kagenti-entity-provider should include complete config.d.ts declarations with appropriate @visibility annotations for all security-sensitive fields on the initial commit, without requiring a review-fix cycle to add them.
Generated by retro agent from #4574
What happened
On PR #4574, the code agent added security-sensitive fields (
caData,skipTLSVerify,apiKey) to the ogx-entity-provider plugin but omitted@visibility backendannotations in itsconfig.d.ts. The review agent flagged this as a medium-severity secrets-exposure finding (review run 34520203260). The fix agent addressed it in commit03280e5, adding the missing annotations.The boost workspace AGENTS.md has a detailed "Adding new config fields" section (lines 136–160) that explicitly requires
@visibilityannotations, but it is scoped toplugins/boost-backend/config.d.tsand the centralized Zod schema system. Independent entity provider packages (ogx-entity-provider,kagenti-entity-provider) maintain their ownconfig.d.tsfiles outside this system, so the code agent did not apply the guidance when working on ogx-entity-provider.The review agent also noted that the ogx-entity-provider
config.d.tsonly declared 4 of the ~9 fields thatreadOgxEntityProviderConfigactually reads, and flaggedisValidPemas duplicated fromboost-connector-utils/src/ca-bundle.tsrather than reused.What could go better
The code agent could have gotten the
config.d.tsright on the first attempt if the AGENTS.md guidance covered all packages that declare config fields, not justboost-backend. This would have avoided the review finding, the fix agent iteration to add annotations, and the subsequent re-review — saving approximately one review-fix cycle (~$10–12 in agent costs).Confidence: high. The code agent demonstrably reads and follows the boost AGENTS.md "Adding new config fields" section (the initial PR included a changeset, config examples, and API report updates as that section instructs for boost-backend). Extending its scope to entity provider packages is straightforward and directly addresses the gap.
Proposed change
In
workspaces/boost/AGENTS.md, below the existing "Adding new config fields" section (after line 160), add a subsection:Validation criteria
The next code agent PR that adds or modifies config fields in
ogx-entity-providerorkagenti-entity-providershould include completeconfig.d.tsdeclarations with appropriate@visibilityannotations for all security-sensitive fields on the initial commit, without requiring a review-fix cycle to add them.Generated by retro agent from #4574