Topic starter
06/06/2026 11:28 am
TL;DR: C1.ai shows that credential sharing through Slack, DMs and free one-off tools leaves secrets with persistent exposure, weak oversight and no clean expiry path. Embedding secret sharing in the identity platform pulls access control, audit logging and deletion into the same governance plane that already governs credentials.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “Introducing Secret Sharing in C1”.
Key questions
Q: What breaks when teams share secrets in Slack or DMs?
A: Secrets posted into collaboration tools inherit retention, search and export behaviour that was never intended for credential custody.
Q: Why do shared vaults sometimes create more risk than one-time secret sharing?
A: Shared vaults can reduce ad hoc sprawl, but they often leave credentials available long after the task is complete.
Q: How should IAM teams decide whether a secret-sharing tool is acceptable?
A: Evaluate whether the tool gives you recipient scoping, encryption, expiry, deletion and auditable access records in one governance flow.
Practitioner guidance
- Define approved secret-sharing channels Explicitly classify collaboration apps, DMs and consumer transfer tools as unapproved for credentials, API keys, certificates and config blobs.
- Require recipient-scoped expiry Set a default expiration and view limit for every shared secret so the disclosure window ends without manual cleanup.
- Tie secret sharing to audit records Ensure every share event produces a durable access record that can be reviewed alongside identity and entitlement history.
Bottom line: Secret sharing becomes a governance issue when the transport channel outlives the task and leaves credentials with uncontrolled retention.
What's in the full announcement
C1.ai's full blog covers the operational detail this post intentionally leaves for the source:
- Browser-side encryption model and what the service stores versus never sees
- Recipient verification flows for internal users and external one-time links
- Product-level handling for text, JSON, YAML, environment variables and files up to 1 GB
- Planned integrations between secret sharing and connector management
👉 Read C1.ai's blog on secret sharing in identity platforms →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
06/06/2026 12:17 pm
Secret sharing becomes an identity governance problem once the secret inherits the lifecycle of the platform that stores it. Chat tools, free transfer services and ad hoc vault sharing all create durable copies, retention artefacts and unclear ownership. That breaks the assumption that a credential can be treated as transient just because the task is transient. Practitioners should judge secret sharing by whether the secret has a governed lifecycle, not by how quickly it can be sent.
A question worth separating out:
Q: What is the difference between secret scanning and secret governance?
A: Secret scanning finds exposed credentials, while secret governance reduces the chance those credentials remain useful. Governance includes ownership, rotation, expiry, offboarding, and revocation. Without those controls, a detected secret may still be valid and exploitable even after it has been found.
👉 Read our full editorial: Secret sharing in identity platforms changes credential governance
This post was modified 3 days ago by NHI Mgmt Group