Informal sharing creates poor auditability, unclear ownership, and higher exposure to accidental leakage. Credentials passed through chat, email, notes, or screenshots are easy to reuse after the session ends. That weakens accountability and makes it harder to revoke access quickly when a token, key, or account is no longer needed.
Why This Matters for Security Teams
Informal credential sharing seems harmless in a workshop, but it breaks the identity controls that make access review, revocation, and incident response work. A secret sent in chat or a screenshot has no durable owner, no reliable expiry, and no clear purpose once the session ends. That creates a shadow access path that can be reused later, often long after the original business need disappears.
NHIMG research shows this is not a rare edge case: in The 2024 Non-Human Identity Security Report, 23.7% of organisations said they share secrets through insecure methods such as email or messaging applications. That pattern aligns with the broader Guide to the Secret Sprawl Challenge, where access becomes difficult to trace because the original handoff was never formalised. Security teams also miss that identity proof and secret distribution are different problems, and both need controls.
Practitioners usually discover the weakness after a workshop token is reused in production, not when the credential is first passed around.
How It Works in Practice
The control failure starts with speed. During a prototype or incident exercise, teams often prioritise momentum over governance, so credentials are copied into chat, notes, or a shared document. That may help the session proceed, but it bypasses lifecycle controls: no issuance record, no scoped assignment, no expiry, and no enforced revocation. The result is a credential that behaves like a permanent exception.
Best practice is to replace ad hoc sharing with time-bound access and traceable issuance. For human users, that means temporary access requests with strong authentication, and for non-human workloads it usually means short-lived secrets, workload identity, or just-in-time provisioning. The general direction is supported by the OWASP Non-Human Identity Top 10 and by the identity assurance principles in NIST SP 800-63 Digital Identity Guidelines.
In practical terms, teams should:
- issue per-session or per-task credentials with clear TTLs instead of reusing shared keys;
- store secrets in a vault or broker, not in chat threads or slide decks;
- assign an owner to every credential and log each handoff;
- revoke access immediately when the workshop ends or the prototype is retired;
- prefer workload identity and policy-based access over copied static secrets.
When this discipline is missing, informal sharing becomes a persistence mechanism for secrets, not just a convenience. These controls tend to break down in cross-functional labs with mixed human and agent access because nobody owns the revocation step once the session ends.
Common Variations and Edge Cases
Tighter credential handling often slows down collaboration, so organisations have to balance speed against auditability. That tradeoff is real during hackathons, red-team exercises, customer demos, and proof-of-concept builds, where people want immediate access and the business may tolerate temporary exceptions.
The guidance is clearest for production-adjacent environments: do not let temporary sharing become the default. For purely disposable sandboxes, current guidance suggests using isolated accounts, synthetic data, and short-lived secrets so the risk stays contained. For regulated workloads, informal sharing is especially dangerous because a single forwarded token can undermine logging, attribution, and segregation-of-duties expectations.
There is also a difference between sharing a document and sharing a live credential. A non-sensitive reference file can be acceptable, but a token, API key, certificate, or account password should never be passed around informally. If a team needs recurring access, that is a sign to design a proper access path rather than extend the life of a secret. The Cisco Active Directory credentials breach and Reviewdog GitHub Action supply chain attack both show how quickly exposed secrets can be abused once they leave controlled channels.
In practice, informal sharing is most damaging when a temporary prototype quietly graduates into a long-lived dependency without anyone reissuing the access properly.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF 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-03 | Addresses secret lifecycle weakness caused by informal sharing. |
| OWASP Agentic AI Top 10 | A-02 | Shared credentials often become uncontrolled tool access for agents and prototypes. |
| CSA MAESTRO | ID-02 | Supports workload identity and traceable access for ephemeral prototype use. |
| NIST AI RMF | GOV-1 | Requires accountable governance for access decisions around AI-supported work. |
| NIST CSF 2.0 | PR.AC-1 | Directly maps to managing identities and access for shared credentials. |
Enforce identity-managed access and remove informal secret sharing from normal practice.
Related resources from NHI Mgmt Group
- What breaks when teams rely on static credentials for workload federation?
- What breaks when identity teams rely on manual response during an attack?
- What breaks when SOC 2 teams rely on ad hoc evidence collection during the observation period?
- What breaks when security teams rely only on native Microsoft 365 controls for file sharing?
