Managed secrets and access keys

Use managed secrets for supported credential references instead of placing passwords, tokens or connection strings directly in Job text. Only use resources and actions authorized for your project.

Create and reference a secret

Open the available secret-management page, enter the required metadata/value and save. Use the supported secret picker or reference field in configuration. A metadata listing does not display the saved secret value.

Choose a name that explains the business purpose without including the credential itself. Use separate credentials for separate purposes when the external service supports that arrangement.

Update or revoke

Review which Jobs or configurations depend on a secret before replacing or removing it. An old accepted execution may still need the referenced resource. Confirm the resulting execution behavior with a small authorized test.

Revoking a credential is not proof that already accepted work has stopped. Use Session controls if interruption is required.

Personal keys and technical identities

Personal access keys and service-account keys serve different owners. Use the available customer key pages to create, inspect metadata and revoke keys within your authority. Record a newly issued value only through the intended secure workflow; do not assume it can be displayed again later.

Grant only the permissions needed for the integration. A technical identity is not an interactive user and must not be given credentials borrowed from a colleague.

Keep content safe

Do not place secret values in action names, URLs, variables intended for inspection, logs, exported Jobs or screenshots. Managed secret references do not automatically sanitize other content you author or data visible in the automated application.

Before sharing an export or capture, inspect it for customer information and credentials. Use synthetic examples when reporting a problem publicly.