Hardened deployments

A hardened deployment is a deployment that restricts workflow registration to authorized users and service accounts. An authorization entry is called a pin. Use hardening to control which workers can register production workflows, especially on-behalf-of (OBO) workflows that act as the user who triggers an execution.

Hardening is an explicit setting, independent of how many pins exist. Removing the last pin leaves a hardened deployment closed: it does not reopen registration. This prevents removing access from accidentally granting access to everyone.

If workers in the same deployment register different implementations under the same workflow name, you cannot predict which implementation handles an execution. Accidental or unauthorized registration can therefore disrupt production workflows.

OBO workflows can use delegated access to the triggering user's resources, such as files and connectors. They require a hardened deployment so that only authorized principals can register those workflows.

Pins authorize an identity rather than a particular worker process:

• User: authorizes eligible API keys belonging to that user. Rotating a user's key does not require changing the user pin.
• Service account: authorizes workloads authenticating as that service account, including through workload identity federation. Its credentials can rotate without changing the pin.
• Existing user API-key pin: remains visible and removable for compatibility, but authorizes only that specific key. Other keys belonging to the same user do not match an API-key pin; use a user pin to avoid updates when keys rotate.

Service-account API keys cannot be selected as pins. Pin the service-account principal instead, so authorization follows the runtime identity rather than a replaceable credential.

Deployment owners and workspace administrators can manage hardening and pins in the deployment's Settings tab in Studio. Ownership lets the person operating a deployment make routine changes without administrator intervention; administrators retain recovery and ownership-reassignment capabilities. Ownership is distinct from a pin: being an owner does not by itself authorize worker registration.

A user must have the AccessWorkflows permission in the target workspace to own a deployment, be pinned, or auto-claim a local OBO deployment. A user who cannot use Workflows must not gain access indirectly through ownership or a pin. Ask a workspace administrator for a role with Workflows access if you lack this permission.

For an eligible user, the first local OBO registration under a new deployment name succeeds without an administrator preparing the deployment:

1. Use an API key belonging to a user with AccessWorkflows in the target workspace.
2. Configure an OBO workflow and start its worker with a new deployment name.
3. Registration atomically creates the deployment, assigns you as owner, pins your user principal, and enables hardening.
4. Open the deployment's Settings tab in Studio to review or add authorized principals before teammates join it.

The user principal is pinned, not the API key, so eligible keys for the same user continue to work after rotation. This automatic claim applies only to OBO user registrations: hardening every ordinary shared local deployment could let the first worker lock out teammates.

If the name already exists, registration does not take over an unowned deployment or one owned by another user. Automatic hardening can apply to an existing local deployment only if you already own it, it is unhardened with no pins, and no other worker is live. A second user cannot claim an existing hardened deployment; its owner or a workspace administrator must authorize them to join it.

Service-account callers are not auto-claimed and cannot become owners through this flow. A pinned service account can still run OBO workflows: the runtime's identity authorizes registration, while the triggering user's identity supplies the delegated access.

Initial hardening for managed deployments

New managed deployments created in Studio default to hardened, with an explicit opt-out during creation. The platform automatically pins the managed runtime's service account, so runtime credentials can rotate without changing registration authorization.

Studio's default does not change every client's default. If you opt out or create an unhardened managed deployment through another client, enable hardening before registering OBO workflows.

Open the deployment in Studio and select its Settings tab. You must be its owner or a workspace administrator to change hardening or manage pins.

Enable hardening

1. Stop the deployment's workers. For a managed deployment, stop the managed service as well.
2. Wait until the deployment is inactive.
3. Enable hardening in Settings.

The platform automatically selects the initial pin: the owner for a local deployment, or the managed runtime's service account for a managed deployment. If a local deployment has no owner, ask a workspace administrator to assign an eligible user first.

Hardening requires inactivity because changing registration authorization does not stop workers that are already active on the deployment.

Add or remove pins

Use Settings to authorize users or service accounts for a hardened deployment. Multiple pins let several authorized principals register workers on the same deployment. Removing a pin removes that authorization entry; removing the final pin leaves hardening enabled and registration closed.

Disable hardening

Disable hardening in Settings only when you intend to reopen registration. A successful request atomically disables hardening and deletes every pin, including the managed runtime's pin, so an open deployment retains no stale authorization state that might unexpectedly take effect later.

Disabling hardening is rejected while any OBO workflow is registered on the deployment. Those workflows require controlled registration to protect delegated user access. Stopping workers alone is not enough: remove the OBO registrations before retrying.

Automatic pin reconciliation

Invalid user and service-account pins are reconciled periodically. A pin is deleted only when validation conclusively shows that the principal is no longer eligible. Dependency failures or missing context preserve the pin for a later retry, so a temporary validation failure does not revoke working production access.

Hardening limits workflow registration to the principals you authorize. It does not validate the code submitted by an authorized principal, and it does not replace protecting that principal's credentials.

Troubleshoot registration

Deployment-authorization refusals include a direct link to the deployment's Settings tab in Studio. The link selects the relevant organization, workspace, and deployment so that the person fixing access reaches the right controls.

For workflow code and delegated credentials, continue with On-behalf-of workflows.