TL;DR: n8n’s credential model can let project members and instance administrators use credentials created by someone else, even when those credentials were never explicitly shared, according to Linx Security’s experimentation in n8n Cloud. The key governance issue is that ownership, visibility, and effective control do not always align, which weakens attribution and auditability.
At a glance
What this is: This analysis examines n8n credential sharing behaviour and finds that credential ownership, storage location and effective control can diverge in multi-user instances.
Why it matters: IAM and NHI teams need to understand this control gap because downstream actions may be attributed to the credential owner even when another user or admin executed them.
Context
In n8n, a credential is not just a stored secret. It is an access decision that can determine whose identity downstream systems believe is acting, which means the governance question is not only who created it, but who can use it and under what conditions.
Linx Security’s testing in n8n Cloud shows that personal-project storage does not guarantee exclusive control. In multi-user environments, implicit availability can override user intent, so teams that rely on project boundaries alone may overestimate separation of duties.
That matters most where workflow execution is treated as delegated identity use, not just automation plumbing. The article’s core finding is that the platform’s trust model can conflict with organisations that expect admins to manage the system without being able to act as other users.
Key questions
Q: What breaks when personal-project credentials can be used by other users or admins?
A: The break is in separation of ownership from control. A credential may be created by one user, but if another actor can select and run it, the platform no longer preserves exclusive operational authority. That weakens non-repudiation, complicates audit trails, and can make downstream actions look like they came from the owner even when they did not.
Q: Why does admin access to another user’s credential create accountability risk?
A: Because downstream systems usually trust the token, not the person who clicked run. If an admin can execute workflows with another user’s OAuth credentials, the application layer may record legitimate identity use while obscuring the true operator. That makes incident investigation, approval tracing and separation of duties much harder.
Q: How should IAM teams evaluate credential sharing inside workflow platforms?
A: They should evaluate who can create a credential, who can see it, who can select it in a workflow, and who can execute it independently. Those are different permission questions. If the platform collapses them, governance needs compensating controls such as tighter admin boundaries, clearer ownership records and stronger review processes.
Q: What should organisations document when workflow tools allow implicit credential reuse?
A: They should document the trust model in plain language: whether credential storage is personal, whether project members can reuse it, whether instance admins can invoke it, and how those actions are attributed. Without that documentation, users can assume exclusivity that the platform does not actually enforce.
Technical breakdown
Explicit sharing versus implicit credential availability
n8n supports explicit credential sharing to specific users or projects, which is the expected governance model: the owner grants use rights intentionally and those rights are visible. The problem described by Linx Security is that explicit sharing is not the only path to use. Credentials created inside a project can become available to other project members even when they were never individually shared, so the operational boundary is broader than the ownership record suggests. That creates a governance mismatch between consent and use, especially when downstream systems only see a valid token for a user, not the pathway by which the token was selected.
Practical implication: treat credential-use scope as separate from credential-creation scope when reviewing access boundaries.
Administrative impersonation through unshared personal-project credentials
The more concerning mechanism is instance-admin access to credentials stored in another user’s personal project. In the described behaviour, an admin can create a workflow in the admin’s own project, select another user’s unshared credentials, and execute actions without re-consent or notification to the credential owner. That is not a mere visibility issue; it is administrative impersonation at the application layer. The downstream service sees the token holder as the actor, while the actual operator is the admin who initiated the workflow. Audit logs can therefore preserve technical legitimacy while obscuring human accountability.
Practical implication: validate whether admin execution rights can cross personal-project boundaries before relying on project isolation.
Why OAuth consent does not bound later control
OAuth consent proves that a user authorised a token at a point in time, but it does not necessarily preserve exclusive control over later use inside the orchestration platform. In this case, the token remains technically valid while another actor can operationalise it through the platform’s execution layer. That is why the article frames the issue as ownership versus control, not as token theft. The trust boundary has moved from user intent to instance authority, and that shift is what changes the governance model for delegated access in automation platforms.
Practical implication: align OAuth governance with instance-level authority, not just with the initial consent event.
Threat narrative
Attacker objective: The objective is to execute actions under another user’s identity while preserving token validity and blurring accountability in downstream systems.
- Entry occurs when a legitimate user creates OAuth-backed credentials in a personal or project context and those credentials become selectable within the n8n execution environment.
- Credential access is exercised when an instance administrator or project member selects credentials created by someone else and uses them without additional consent or notification.
- Impact follows when downstream applications attribute the workflow actions to the credential owner, obscuring who actually initiated the activity and weakening auditability.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Credential ownership is not the same as control authority: This article shows that identity governance based on who created a credential can fail when the platform lets other actors use it later. The control plane and the audit plane separate, so ownership records no longer describe operational authority. Practitioners should treat credential lifecycle and execution authority as distinct governance objects, not as one record with one owner.
Administrative impersonation is a governance problem, not just a visibility problem: If an instance admin can operationalise another user’s OAuth token, the issue is not merely that the admin can see secrets. It is that the platform allows identity substitution inside downstream systems, which breaks separation of duties and weakens non-repudiation. That means audit models built for direct user action do not survive delegated execution without additional governance checks.
Personal-project storage creates a false boundary when instance authority is broader: The word personal suggests exclusivity, but the article demonstrates that storage location does not guarantee exclusive use. That assumption was designed for user-owned assets with limited admin reach. It fails when platform administrators can invoke the credential through a separate workflow context, so practitioners must reframe personal-project boundaries as organisational trust constructs, not privacy guarantees.
Effective control is the concept that matters for n8n governance: Linx Security’s finding sharpens a useful term for the market: effective control. A credential can be owned by one user, stored in one project, and still be operationally controlled by another actor. IAM and NHI programmes need to account for that split because governance models that stop at storage, ownership, or consent leave the real control point unexamined.
This pattern sits at the intersection of IAM, NHI, and workflow governance: The article is not just about one platform quirk. It shows how delegated credentials in automation platforms create identity risk that spans human administration, non-human execution, and downstream application trust. That cross-domain overlap is where current access review and ownership models are most likely to misstate who can actually act.
What this signals
Effective control is the governance gap to watch: when a credential can be owned by one person, stored in one project and executed by another actor, the control that matters is not ownership but effective use. Access reviews that only confirm who created a secret will miss the party that can actually operationalise it.
n8n-style delegation models show why workflow platforms should be governed as identity systems, not just automation tools. Once a platform can run actions under another user’s identity, the audit question shifts from who authorised the token to who can cause it to act.
For practitioners
- Review instance-admin execution rights Test whether administrators can create workflows that use credentials owned by other users, including credentials stored in personal projects and not explicitly shared.
- Separate ownership from operational authority Record who created each credential, who can select it in a workflow, and who can cause it to execute, then reconcile those three views during access review.
- Reclassify personal projects as shared trust zones Assume personal-project storage does not guarantee exclusive use and update governance language so users understand that storage location is not the same as access isolation.
- Validate downstream attribution logs Check whether application logs and SIEM records show only the credential owner, then decide whether that level of attribution is acceptable for regulated or separated-duty workflows.
Key takeaways
- This article shows that credential ownership, storage location and operational control can diverge inside workflow platforms, creating an accountability gap.
- The observed behaviour matters because downstream systems may attribute actions to the token owner even when an administrator triggered the workflow.
- Organisations should review who can select and execute other users’ credentials, then document whether that is acceptable in their trust model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Persistent access paths matter when credentials remain usable beyond the creator's intent. |
| NHI-10 — Human Use of NHI | Admins using another user's token is a human acting through an NHI credential. | |
| Recommendation — Review credential lifecycle boundaries so access does not outlive the intended owner or context. Detect and restrict cases where humans can operationalise credentials owned by someone else. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Admins selecting unshared credentials indicates privilege broader than necessary. |
| IA-5 — Authenticator Management | OAuth tokens are authenticators whose use and lifecycle need explicit governance. | |
| Recommendation — Apply least-privilege limits to prevent administrative workflows from crossing user credential boundaries. Govern authenticator use so token storage, selection and execution cannot diverge without review. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is an authorization boundary between ownership and operational access. |
| Recommendation — Map credential selection and execution rights to PR.AA-05 and verify that entitlements match intent. | ||
Key terms
- Credential Ownership Check: A credential ownership check verifies that the authenticated caller is allowed to act on a specific credential before the system reads or modifies it. This control is essential in multi-user platforms because identifier knowledge alone should never be enough to authorize sensitive actions such as revoke, authorize, or rebind.
- Effective Control: Effective control is the real ability to exercise a credential, token, or account, regardless of who originally created it or where it is stored. In identity governance, this is the boundary that matters for auditability, accountability, and separation of duties because downstream systems only see valid authority.
- Administrative Impersonation: Administrative impersonation is when a privileged operator can act in downstream systems under another user’s identity by using that user’s credential or token. It is a governance problem because logs and application context show legitimate identity use while the initiating operator remains hidden from normal attribution.
- Delegated Credential: A token, key, or other secret that allows one system to act on behalf of another identity. For agentic environments, delegated credentials matter because they extend trust into runtime, where the agent can use them to reach tools, data, or services without a fresh human approval.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.
Published by the NHIMG editorial team on July 5, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org