config create/update store #-prefixed secrets as plaintext (Encryption API only applied on sync/variables paths)

[soustruh]

Guys, I believe I just found quite a bug — please correct me if I'm completely missing something and this isn't actually a problem…

TL;DR

Secrets passed to the interactive config create / config update (and new-row / update-row) commands are written to Storage in plaintext, because those paths never call the Encryption API. The Storage API does not encrypt #-prefixed values server-side — the client must pre-encrypt. The UI does this; our own sync push and variables paths already do it via encrypt_secrets_in_config. The interactive config commands just skip it.

This is the AI-facing default path: an agent (or a human) doing config update … '#password=…' lands the secret readable in the project, in every config version, and re-exposed on the next read.

How I noticed it

I spotted the #password stored in cleartext directly (not KBC::…).

The job angle is worth stating precisely, because it cuts the other way: when the component actually runs, the runtime rejects the plaintext secret —

Invalid cipher text for key #password  Value "…" is not an encrypted value.

— so the job fails closed. That is not a safeguard. The plaintext value is readable straight out of Storage (API / UI / every config version), and a sync action (e.g. testConnection) executes with the live plaintext credential — so it can be pulled out of Keboola unencrypted even though the job won't run. Failing closed on the job just hides the leak.

Repro (verified live, dummy value)

Create a config with a #-prefixed param via config create (or raw Storage API), then read it back:

• stored value is the literal plaintext, not KBC::…
• the same value pushed via sync push comes back KBC::…

Storage stores whatever JSON it is handed; it does not encrypt. The responsibility is entirely client-side.

Where it is (current main)

Already correct (call services/_encryption.py::encrypt_secrets_in_config, fail-closed):

• sync push — sync_service.py (_push_create / _push_update / _push_*_row)
• variables — variables_service.py

Missing the call → writes plaintext:

• config_service.py — create_config / update_config / create_config_row / update_config_row ← the real exposure (extractor/writer credentials)
• routers/configs.py — the serve REST config routes (share config_service)
• flow_service.py, data_app_service.py — same unguarded call, but flows/data-apps hold references to other configs and don't normally carry #-secrets, so this is theoretical, not an active leak. Listing only for completeness — I don't want to overstate it.
• kbagent tool MCP passthrough — defers to the MCP server, which (separately) also doesn't encrypt.

All writes funnel through the Storage client in client.py, so there's a single chokepoint available if you want one.

Relationship to existing issues

• feat: kbagent encrypt command for MCP tool call workflows #116 added the kbagent encrypt primitive (the building block) — but the interactive config commands don't call it.
• Single-config sync: pull/push individual configuration by component+config ID #59 raised "should config push auto-encrypt #-values?" as an open question — this is concrete evidence that for config create/update it isn't just nice-to-have, it's an active plaintext write.
• Epic: Unified Write Protection + Single-Config Sync #63 (WriteGuard epic) looks like the natural home for a single enforcement point.
• Prior art: the same audit was already done for the old Go kbc push (Linear PSGO-85).

Fix options (your call — flagging, not prescribing)

1. Central chokepoint — encrypt #-keys in the Storage client write methods (create_config / update_config / *_row, or in _request for /configs* POST/PUT). One fix, also covers serve + the passthrough. Needs project/component context at that layer.
2. Service-layer — call encrypt_secrets_in_config in config_service (and flow/data-app) the way sync_service already does. Proven pattern, more call sites.
3. Hybrid — chokepoint as a safety net + explicit service calls.

Whatever the choice: reuse encrypt_secrets_in_config, keep its fail-closed default, and expose an escape hatch named consistently with sync's --allow-plaintext-on-encrypt-failure.

Open questions

• Should reads (get_config) redact #-values before handing them back to an LLM, to avoid context leakage? (Separate concern, same theme.)
• Should the kbagent tool MCP passthrough encrypt itself, or rely on the MCP server being fixed?

---

Verified on project 4214, component keboola.ex-pohoda-mserver. Happy to share the probe configs / full repro. Tracking in Linear: AI-3326. Sibling finding — the Keboola MCP server has the same behaviour: AI-3327.

[linear]

AI-3326

RISK-34

[padak]

Confirmed — reproduced independently end-to-end. The bug is real and the write-up is accurate.

What I verified

1. Static (current main, v0.53.0)

encrypt_secrets_in_config (services/_encryption.py) is called only from sync_service.py (4 sites) and variables_service.py (1 site). The string encrypt does not appear anywhere in config_service.py — create_config / update_config / create_config_row / update_config_row POST/PUT the configuration straight to the Storage client with no encryption step. Confirmed flow_service.py = 0 occurrences too.

2. Live (separate project, dummy canary values, then cleaned up)

Path	Wrote	Read-back from Storage (config detail)	Verdict
config new --push (→ create_config)	#password=CANARY-…	plaintext (not KBC::)	🔴 leak
config update --configuration (→ update_config)	#password=CANARY-…	plaintext	🔴 leak
kbagent encrypt values (Encryption API, same project+component scope)	#password=CANARY-…	KBC::ProjectSecure::eJwBRAG7…	✅ API works

The third row is the key point: the Encryption API is fully available for that project/component and returns ciphertext — config create/update simply don't call it. The asymmetry you describe is exactly right.

Two minor notes (don't change the verdict)

1. --set '#password=…' sets a top-level #password key, not parameters.#password (#password isn't a dot-path). To target a nested secret via --set you need --set 'parameters.#password=…' or a full --configuration. Separate UX sharp edge — and a top-level #-secret is stored in plaintext just the same, so the leak still applies.
2. data_app_service.py actually does have its own encryption (the secrets-set workflow), so I'd drop it from the "unguarded" list — flow_service.py is the only other service with zero encryption, and as you note that one is theoretical (flows hold references, not #-secrets).

Fix

Going with option 2 (service-layer): call encrypt_secrets_in_config in config_service (create_config / update_config / *_row), fail-closed by default, with an escape hatch named --allow-plaintext-on-encrypt-failure to match sync push. Since the serve REST routes and the MCP-passthrough both funnel through config_service, this single change covers them too (REST stays fail-closed with no opt-out). PR incoming.