How Secret Injection Works

Secret injection resolves selected server credentials separately from the agent's ordinary tool arguments. Required values still cross the cloud execution boundary. Local storage, runtime injection and persisted AP Connections have different trust and retention properties.

The Supported Boundary

Normal credential elicitation avoids asking the model to author raw credentials in run_tool arguments. This is not proof that sensitive data can never enter a prompt, log or third-party response. Keep secrets out of these user-controlled surfaces:

The system prompt sent to the LLM.
The user message or any conversation turn visible to the LLM.
The tool definitions and schemas sent to the LLM.
The arguments inside a tool call generated by the LLM.

When the LLM decides to call a tool, it emits a tool call object that contains only the logical parameters for that tool — for example, {"repo": "acme/backend", "title": "Fix bug"} for a GitHub issue_write call (which also needs method/owner/repo). The client resolves required credentials and sends them to execution services. Agent-built flows upsert encrypted cloud AP Connections and use {{connections.<externalId>.secret_text}} in nodes. Manual blocks expose credential properties; the browser does not automatically read a local Vault.

Per-Execution Scoping

The client has a default 15-minute credential cache and invalidates it when the index changes. Workflow/session memory and cloud persistence have separate lifetimes:

Execution secrets use Redis hashes with a default 1,800-second TTL, refreshed on insertion.
Compose enables Redis AOF persistence; key expiry does not immediately erase earlier AOF records.
Workflow state/final results remain in orchestrator memory with default one-hour cleanup age.
AP Connections persist encrypted credentials for flows; local rotation/deletion does not automatically prove their values changed.

Cross-Server Isolation

Plaintext mcp.json credential values can be read by processes with access to that file. Individual MCP servers need not share one process environment; protect filesystem and process access rather than assuming either configuration style prevents every compromise.

Steroid uses per-entry encrypted storage with namespaced keys. Each server's credential lives under its own key and is only resolved when a tool from that specific server is being called. The vault proxy uses the selected server's requirements. Namespacing is not a guarantee against arbitrary same-user processes, compromised clients or every gateway configuration.

Server-scoped lookup keys

github-official.secrets.github.personal_access_token
slack.secrets.slack.bot_token
postgres.secrets.postgres.url

Config map key: <server_name>.config
Protect ~/.steroid/.cryptfile_key with the encrypted store.
Namespace scoping does not replace OS/process access control.

Model Visibility and Exceptions

Data	In LLM Context?
Tool schemas and parameter definitions	Yes — LLM needs these to call tools correctly
Tool call arguments (repo name, issue title, etc.)	Yes — LLM generates these
Credential values	Handled through separate elicitation/injection by default; avoid copying into chat or arguments
Vault secret values	Required values are sent to runtime injection or encrypted AP Connections
Tool results, user prompts and configuration examples	May contain sensitive data; review before sharing with a provider

TIP

Use encrypted storage and connection references to reduce accidental exposure, then apply ordinary least-privilege, endpoint, logging and backup controls. Exact cipher/mode and platform permissions require independent verification; there is no unconditional no-model/no-log/no-exfiltration promise.