Should duplicating a project copy its members and sharing permissions?

Duplicating a project should usually create a new resource with its own access policy, not silently inherit every member and share from the original. Copy the content structure users expect, but make collaborator access, external shares, and integrations an explicit template decision. That approach matches least-privilege and default-deny guidance from OWASP’s Authorization Cheat Sheet and avoids accidental data exposure when a “copy” contains sensitive history, comments, or linked systems.

Why treat a duplicate as a new resource identity?

A duplicate is not the same object moved to a new location. It is a fresh resource that happens to start with copied data. That distinction matters because authorization should answer who can access this specific resource, not who could access its ancestor. OWASP recommends to “Enforce Least Privileges” and “Deny by Default”. In practice, start private and authorize every selected access template. The caller must be allowed to copy each source object, create in the destination, and disclose that content to the chosen audience; selecting a template grants no authority.

This is also the cleaner model for auditability. Engineers can explain the rule as: cloning copies project data; access comes from the new project’s own relationships.

What should copy, and what should stay separate?

Copy the parts users perceive as project content: documents, task structure, settings that shape the workflow, and optionally embedded comments or metadata if those are not sensitive.

Do not automatically copy everything that grants reach into other systems or people. Collaborators, public links, API tokens, webhooks, SCM connections, billing associations, and environment secrets should be reevaluated. A duplicate often starts life as an experiment, a customer-specific fork, or a pre-release branch. Those cases are exactly where inherited access becomes dangerous.

A useful product rule is to separate four buckets:

• cloned content
• collaborator ACL template
• integrations and secrets
• child-object inheritance exceptions

How should the initial access policy work?

Use an explicit choice at duplication time. For example:

1. Private copy owned by me
2. Copy members from original
3. Share with destination workspace or team
4. Copy content only; reconnect integrations manually

Worked example:

Project A is shared with Product, Support, and an external agency. It contains a private child folder called “Q4 pricing” and a GitHub integration used for release automation. A user duplicates Project A into a new customer workspace.

Good behavior:

• New Project B gets a new resource ID.
• Owner defaults to the duplicating user, or the destination workspace if your app is workspace-owned.
• Core content copies.
• An unreadable private child is omitted. Copyable sensitive children retain explicitly authorized audiences; making the caller the new project owner must not expose them.
• The GitHub integration is not carried over automatically; the user must reconnect it.
• Original external agency access is not copied unless the user explicitly selects that template.

That policy is predictable and safer than inheriting every relation.

Where does Ory fit?

We recommend Ory Network when you need this kind of explicit, application-defined sharing model in production. Ory Network provides managed services based on Ory’s open-source projects, and those deployment choices should be evaluated separately. Ory Keto documentation describes fine-grained permissions based on Zanzibar design principles, with relationship-based models and inheritance. That is a strong fit for modeling rules like project:B#owner@user:alice and deciding which relations a duplicate should create versus skip.

The design pattern is simple: duplication creates a new object and then writes a deliberate set of relationships for that object. Use inheritance where you want durable team access, but do not confuse inheritance with “copy every share from the source.”

Who should own the duplicate?

Usually the duplicating user, unless your product treats projects as workspace-owned resources. Pick one rule and document it.

Which child objects should the copy omit?

Omit children the caller cannot read or copy. For authorized sensitive content, preserve its audience constraints or omit it; a private copy owned by the caller is still disclosure to that caller. Reconnect integrations through a separate authorized flow.

Next step: write a duplication matrix listing each child object type and whether it is copied, omitted, privatized, or reauthorized on the new project, then encode those relationships in Ory Permissions on Ory Network.

Reviewed: 2026-09-05.