Secrets

Workflows need tokens and API keys; workflow files are committed and shared. loopkeep keeps the two apart: secret values live only in the OS keychain, files carry only names.

Storing a secret

Open Project Settings → Secrets, enter a name and value, and Add secret. The value goes straight to the OS keychain; the list shows names only, and each can be removed there.

Values go to the OS keychain (macOS Keychain today; Linux Secret Service and Windows Credential Manager are not yet wired up). .loopkeep/secrets records only the names — there is deliberately no file-based fallback for values; if the keychain refuses, the command fails rather than writing a value to disk.

Referencing a secret

In a workflow body:

Fetch the report using {{ secret:notion-token }} for authentication.

In MCP server configuration:

mcp-servers:
  notion:
    command: "npx -y @notionhq/notion-mcp-server"
    env: { NOTION_TOKEN: "secret:notion-token" }

At run time the value is injected into the agent or MCP server process as an environment variable. Writing a literal credential in a workflow or config file is rejected as a matter of policy — reference by name, always.

Redaction, and its honest limits

Before anything is written to the event log, registered secret values are redacted — exact matches, plus known encodings (base64, URL-encoding). That's the guarantee, and it's deliberately stated narrowly: arbitrary transformations of a secret cannot be reliably caught. The real protection is structural — keep secrets out of prompts and outputs, and let injection happen at the process boundary. Redaction is a net under the tightrope, not the act.