Repository navigation
Isolate threat detection provider settings across engines - #66533
Conversation
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
@copilot automatically match the main agent provider if the agentic engine do not match (OpenAI/anthropic/copilot...). |
…model aliases Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Implemented in |
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Same-provider credentials and API targets still cross differing engine identities, contradicting the documented security contract.
Review effort: Balanced
Findings: 1
What changed in this PR
This PR isolates threat-detection provider configuration and surfaces missing security verdicts.
Changes:
- Restricts provider configuration inheritance and updates firewall/auth resolution.
- Warns when detection produces no verdict.
- Documents behavior and regenerates compiled workflows.
| File | Description |
|---|---|
pkg/workflow/compiler_validators.go |
Uses effective detector environment for auth validation. |
pkg/workflow/evals_steps.go |
Applies engine-aware firewall-domain resolution. |
pkg/workflow/threat_detection_firewall_test.go |
Updates firewall helper tests. |
docs/src/content/docs/reference/threat-detection.md |
Documents isolation and missing-verdict warnings. |
295 .github/workflows/*.lock.yml files |
Propagate the generated conclusion warning. |
|
|
||
| When the resolved detection engine matches the main engine, detection inherits `engine.env`, `api-target`, and model aliases. Detection-specific environment values take precedence, including empty values. | ||
|
|
||
| When the engines differ, detection does not inherit the main engine's environment, API target, or custom model aliases. This prevents provider URLs, API keys, and custom headers from reaching an unrelated engine. Configure any required provider settings under `safe-outputs.threat-detection.engine.env`; built-in model aliases remain available. |
There was a problem hiding this comment.
Fixed in 9329e85f: main-engine environment and API-target settings now inherit only when the resolved engine IDs match. Regression coverage confirms Pi/OpenAI settings do not reach Codex detection while provider-based detector selection and explicit detector overrides remain supported.
|
@copilot address the following outstanding work in one pass:
Push the necessary fixes, reply to each listed review thread and resolve it when addressed. Ignore feedback already answered or resolved. Use the pr-finisher skill and stop when only human review or CI remains; do not trigger CI. Sous-chef head: 9fd53c8
|
…tection-integration Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
|
🎉 This pull request is included in a new release. Release: |

Threat detection inherited the main engine’s provider environment even when using a different engine, leaking credentials and causing firewall health checks to fail before analysis. Missing verdicts could remain unnoticed while safe outputs were published.
engine.env, API targets, and custom model aliases only when engines match. Preserve explicit detector overrides and built-in aliases; use the detector’s default model when an inherited alias is discarded.continue-on-errorbehavior.This split-engine configuration no longer requires empty provider-env overrides: