Every integration has a credential behind it. An API key for a payment processor. A token for a shipping carrier. A password for a legacy system. An access key for a cloud storage backend. Without a dedicated place to put these credentials, they end up scattered — pasted into automation configuration fields, embedded in server-side scripts, typed into form inputs, emailed between implementers. Each of those places is a potential leak and each is a separate rotation headache when the credential has to change. A platform with first-class secrets management turns every credential into a named reference, stored once, controlled by role, rotated in one place, and never written directly into anything that gets stored elsewhere. That's the right shape, and it's what the secrets feature does.
Named secrets are stored once and referenced everywhere. An implementer creates a secret — giving it a meaningful name like Payment Processor API Key or Shipping Carrier Token — and enters the value. From then on, any automation, script, or integration that needs that credential references it by name. The value never appears in configuration fields, never gets copied into scripts, never travels through a form submission. The reference does the travelling; the value stays in the secrets store.
Scope is per-tenant, with isolation as strict as any other platform data: tenant A's secrets are invisible and inaccessible to tenant B, period. Within a tenant, access is controlled by role. Roles that need to use secrets don't automatically see their values; roles that administer secrets can create, update, and rotate them; roles that need to audit can read the audit trail without revealing values. That granular control is what lets a tenant give automations and scripts access to credentials they need without turning every developer into a potential credential holder.
Reference in automations is the most common use case. An automation action that sends a webhook, calls an external API, authenticates with a partner system, or uploads to a cloud bucket picks the secret by name from a dropdown — no pasted value, no copy-paste exposure. At runtime, the automation engine resolves the reference to the current value and uses it; the value is never persisted in the automation configuration itself. If someone later exports the automation's definition, the export carries the reference, not the value — which means configuration can be shared, reviewed, and version-controlled without leaking credentials.
Reference in scripts is the same mechanism for server-side code. A script that needs to make an authenticated HTTP request calls a small platform API to retrieve the secret by name; the code never contains the value. This matters because scripts often end up in version control, in code reviews, in shared libraries — all contexts where a hard-coded credential is a security incident waiting to happen. Referenced by name, the secret stays in the secrets store; the script stays safe to share.
Rotation is the real test of a secrets system, and it's where secrets management demonstrates its value most clearly. When a credential has to change — because it's scheduled for rotation, because it was leaked, because a third party invalidated it — the implementer updates the secret's value once. Every automation, every script, every reference that uses that secret by name picks up the new value automatically on its next execution. There's no hunting through configuration to update twelve different places; there's no list of places where the credential might have been embedded and needs to be checked. Rotation becomes a minutes-long operation rather than a day-long project.
Reveal vs. use is a deliberate distinction. A role can be granted permission to use a secret without being granted permission to reveal its value. That distinction matters in larger teams where many people need integrations to work (they need "use") but only a few people are trusted with the credentials themselves (they need "reveal"). A developer configuring an automation can pick the right secret from a list and test that the integration works, without ever seeing the underlying value. An admin rotating credentials can see and change the value directly. Each role has exactly the access their job requires.
Versioning retains previous values briefly so that a bad rotation can be recovered from. If the newly-issued credential turns out to be wrong — typed incorrectly, never activated by the upstream provider, accidentally pointed at the wrong environment — the previous version is still available for a limited window, and the rotation can be rolled back. For the unfortunate but real cases where rotation doesn't go perfectly, this versioning is what turns a potential outage into a small inconvenience.
Per-environment values let the same secret name resolve to different values in different environments. A Payment Processor API Key might map to a sandbox credential in the staging tenant and a production credential in the production tenant, even though the automations and scripts that reference it are identical between the two. That environment-awareness is what makes secrets interoperate cleanly with the staging-to-production promotion workflow: the same configuration moves between environments, and each environment resolves the names to the credentials it should actually use.
Audit trail captures every interaction with the secrets store. Every create, every update, every rotation, every reveal, every use — all logged in the event log with the actor, timestamp, and context. For compliance audits that need to demonstrate control over credential access, the audit trail is what backs the claim; for security investigations that need to understand whether a credential was misused, the same trail provides the answer. The event log article covers the broader log mechanism; the secrets-specific events integrate into it naturally.
Credentials don't belong in configuration fields. That's the principle the feature is built around. A configuration field accepts values that should be visible to anyone who can view the configuration — property names, descriptions, threshold values, display labels. Credentials aren't those values; they're specifically the values that should remain hidden even from people who legitimately configure the rest of the system. The secrets feature gives those values a proper home: named, referenced, rotated centrally, audited, and invisible to anyone without explicit permission to see them.
For implementers integrating with external systems — which is most of them — the secrets feature is one of those foundational capabilities that removes a whole class of mistakes before they can be made. For the surrounding topics, the automations article covers the integration points where secrets get referenced, the server-side scripting article covers programmatic access, the event log article covers the audit trail, and the roles and permissions article covers the access control that governs secret visibility. Credentials that never end up in code, or in configuration fields, or in export bundles — that's the outcome this feature is designed to produce.