Replies: 1 comment
-
|
To jest dużo poważniejszy issue niż tamten z reset.
Wprost:
Co tu jest problemem
Jeśli credentials z config YAML są:
wstrzykiwane do prompta,
a potem wysyłane do providera LLM,
to masz:
secret exposure do third-party API
potencjalne logowanie tych danych po stronie providera / proxy / telemetry
ryzyko pojawienia się sekretów w:
trace’ach,
debug logs,
prompt history,
crash reports
To nie jest kosmetyka.
To jest realny security bug / secret handling flaw.
Dlaczego sdkEnv ma sens
To, co opisano, brzmi poprawnie architektonicznie:
model dostaje placeholder
lokalny runtime robi substitution dopiero przy wykonaniu
provider LLM nigdy nie widzi prawdziwej wartości
Czyli:
prompt zawiera np. ${API_KEY_NAME}
wykonawca lokalnie mapuje to na env
do modelu nie leci sekret
To jest dokładnie właściwy kierunek.
Jak ja bym to nazwał
Nie „mały bug”, tylko raczej:
Credentials from config are being exfiltrated to the LLM provider via
prompt construction.
Albo łagodniej: Sensitive config values are unnecessarily included in
provider-bound prompt text.
Co powinno się zmienić
Minimum
1. Nigdy nie interpolować sekretów do prompt text
2. Trzymać je wyłącznie:
w env,
local secret store,
runtime substitution layer
Dobrze
3. Dodać redaction w logach
4. Dodać guard, który wykrywa próbę wysłania secretów do modelu
5. Dodać testy:
config z fake secret
assert, że secret nie pojawia się w prompt payload
assert, że pojawia się dopiero lokalnie przy wykonaniu
Najważniejsza różnica
Są dwa poziomy podstawienia:
zły
password: super-secret
→ budujesz prompt z super-secret → wysyłasz do API
dobry
password: ${TARGET_PASSWORD}
→ model widzi tylko ${TARGET_PASSWORD} → local executor bierze wartość z
sdkEnv → provider nie zna sekretu
Ryzyko praktyczne
Największy problem nie jest nawet w samym modelu, tylko w całym łańcuchu:
provider logs
observability
retries
vendor retention
prompt inspection tools
Sekret raz wypchnięty poza lokalny runtime = straciłeś pełną kontrolę.
Mój werdykt
To jest:
valid issue
security-relevant
prawdopodobnie coś, co powinno dostać wysoki priorytet
Nie wygląda na RCE czy coś takiego, ale jako secret leakage to external LLM
provider jest to poważne.
Krótka odpowiedź maintainerska po angielsku
Możesz odpisać tak:
This looks like a legitimate security issue, not just a configuration quirk.
If credentials from the YAML config are interpolated directly into prompt
text, they are being transmitted to the LLM provider unnecessarily. That
creates obvious secret-handling risks through provider-side logging,
tracing, retries, and prompt retention.
I agree the safer design is to keep secrets out of prompt construction
entirely and rely on local runtime substitution via "sdkEnv" (or an
equivalent mechanism), so the model only ever sees placeholders and never
the real credential values.
At minimum, I think the fix should:
- prevent direct interpolation of config secrets into prompt text
- resolve secrets locally at execution time only
- redact them from logs/traces
- add a regression test asserting that configured credentials never appear
in the provider-bound payloadJeśli chcesz, mogę Ci też napisać krótszą,
ostrzejszą wersję pod GitHub comment albo security triage.
wt., 31 mar 2026, 10:50 użytkownik Joel Saß ***@***.***>
napisał:
… Credentials provided via the config YAML file are currently embedded into
the LLM prompt text, such that the credentials are transmitted to the LLM
API.
The sdkEnv mechanism should be utilized in order to include envvars and
replace them locally rather than sending the credentials plainly to the
provider.
—
Reply to this email directly, view it on GitHub
<#264?email_source=notifications&email_token=BUHB4E6PBF7GJ3V7PTKRB3L4TOBEDA5CNFSNUABAM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPHE3TSNJQGY32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BUHB4E6CLPPIXAHFWGUYN5T4TOBEDAVCNFSM6AAAAACXHMU3IGVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZG44TKMBWG4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Credentials provided via the config YAML file are currently embedded into the LLM prompt text, such that the credentials are transmitted to the LLM API.
The sdkEnv mechanism should be utilized in order to include envvars and replace them locally rather than sending the credentials plainly to the provider.
Beta Was this translation helpful? Give feedback.
All reactions