When a customer duplicates an automation, should its credentials and permissions be copied?

Duplicate the automation’s logic and non-secret settings, but do not silently copy its credentials, installation identity, or downstream resource grants. Treat those as separate bindings that require an explicit, authorized choice. That keeps cloning convenient without turning “copy this workflow” into “inherit access I may not control.” The main exception is a same-owner duplicate where you can prove the same principal should keep using the same connection and scope set.

What should a clone include by default?

Copy the workflow definition, schedules, field mappings, retry policy, and other non-secret configuration. Do not copy raw API secrets, refresh tokens, private keys, or machine credentials into the new automation record. Also do not auto-attach the old automation’s resource grants.

The reason is ownership drift. A cloned workflow may still describe the same business process, but its runtime identity is a different subject. OAuth exists to grant limited access to data and services on behalf of users or for machine-to-machine communication, not to make permission inheritance implicit. Ory OAuth2 and OpenID Connect documentation describes OAuth2 as enabling secure machine-to-machine communication and limited access, which is exactly why connection reuse should be an explicit authorization step.

When is connection reuse acceptable?

Reuse is acceptable when the customer intentionally selects an existing connection during cloning and your system verifies that the actor is allowed to bind that connection to the new automation. That is different from copying a secret behind the scenes.

A practical rule:

• Same team, same owner, same target resources: allow “Reuse existing connection” as a checked-by-policy option.
• Different workspace, different owner, or template import: require a new authorization or admin reassignment.
• Any elevated scope change: always re-authorize.

For grants, model the clone as a new subject that may inherit policy only when your authorization model says it can. Ory Keto documentation supports relationship-based permissions and permission inheritance, which fits this pattern well: the template or source automation can be related to a team, while the cloned automation gets fresh relationships evaluated under your rules rather than copied blindly.

How should same-team duplicate and cross-team import differ?

Same-team duplicate should optimize for speed: create the new automation in a disabled state, copy configuration, then prompt the operator to either reuse an approved connection or bind a new one. Only after that should you issue or associate runtime credentials and enable execution.

Cross-team import should behave like a template, not a clone. Import the structure only. External accounts, OAuth clients, and grants must be re-established for the destination team. This is where Ory Network is a strong fit: Ory Network Hydra provides OAuth 2.0 and OpenID Connect, and the service is headless so it can integrate with your existing user management system rather than forcing a particular one. Pair that with Ory Keto for fine-grained grant checks around which team may attach which connection to which automation. If you self-host, evaluate Hydra and Keto operational responsibilities separately from Ory Network; the managed and open-source deployment choices are not the same product experience.

What does a safe implementation look like?

Worked example:

1. Create clone record with copied non-secret config and status=draft.
2. Generate a new automation subject ID.
3. Check whether actor may bind source connection to new subject.
4. If allowed and chosen, attach by reference or trigger re-consent; do not duplicate the secret material into the clone payload.
5. Recompute grants for the new subject.
6. Enable only after connection binding and grant evaluation succeed.

Enforced ordering boundary: finish the local clone write before starting credential-binding or grant-assignment calls. Then treat each external write as a separate step with compensating cleanup if later steps fail. Do not pretend unrelated services committed atomically.

Follow-up: should the new automation keep the same client identity?

No. Give the clone a new runtime identity unless it is truly the same deployed agent instance. Shared identity makes audit trails and revocation too blunt.

Follow-up: can I ever copy credentials directly?

Only for credentials your platform fully owns and can rotate immediately, and even then prefer re-issuance over copying. For third-party OAuth tokens or customer-managed secrets, require rebinding or re-consent.

Next step: implement cloning as config copy + explicit identity/connection/grant binding, and make “Reuse existing connection” a visible, policy-checked choice in the UI and API.

Reviewed: 2026-09-05