Notifications
Clear all
Topic starter
25/06/2026 5:09 pm
TL;DR: Insider threats are harder to detect than outsider threats because insiders already have authorized access, and Entro Security argues that secrets management reduces the blast radius of exposed API keys, access tokens, and encryption keys. The deeper issue is not just malicious behaviour, but governance blind spots around context, ownership, and overprivilege.
NHIMG editorial — based on content published by Entro Security: An insider threat vs. an outsider threat. Which is worse and why?
By the numbers:
- 133 Mailchimp user accounts were compromised after a, d after a phishing attack.
Questions worth separating out
Q: What breaks when secrets are stored in collaboration tools like Slack or Jira?
A: Secrets stored in collaboration tools bypass normal access governance because they can be copied, forwarded, or searched outside their intended lifecycle.
Q: Why do overprivileged secrets increase insider risk so much?
A: Overprivileged secrets increase insider risk because one credential can unlock more systems than the task requires.
Q: How do security teams know whether secrets management is actually working?
A: Secrets management is working when every active credential has an owner, a rotation record, a defined privilege scope, and a clear revocation path.
Practitioner guidance
- Inventory secrets by owner and privilege Build a live inventory that ties each API key, token, and certificate to an owner, last rotation date, and the systems it can reach.
- Remove secrets from collaboration tools Search Slack, Jira, GitHub, and file shares for active secrets, then block future posting through policy and detection.
- Reduce privilege scope before rotation Tighten the permissions behind each secret so the credential can only reach the minimum service or dataset required.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- How Entro enriches secrets with ownership, timestamp, creator, and cloud privilege context
- Examples of how exposed secrets can be tracked across repositories, Slack, and Jira
- The article's walkthrough of how context helps decide whether to rotate, investigate, or revoke a secret
- Why the vendor frames secrets scanning as insufficient without metadata and alerting
👉 Read Entro Security's analysis of insider threats, outsider threats, and secrets management →
Insider threat and overprivileged secrets: what IAM teams miss?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:40 pm
Insider threat is really a secrets governance problem when access outlives context. The article correctly points to overprivileged secrets as the mechanism that makes insider risk persist inside trusted workflows. Once API keys, access tokens, and connection strings are spread across collaboration tools and repositories, the control boundary shifts from authentication to governance. Practitioners should treat exposed secrets as identity assets whose risk is driven by scope, ownership, and reuse.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why secret handling remains a human and governance problem.
A question worth separating out:
Q: Who is accountable when an exposed secret causes a breach?
A: Accountability should sit with the system owner and the identity governance process, not only with the person who last touched the secret. If a credential remains active after a role change, a vendor offboarding event, or a workflow change, that is a lifecycle failure as much as an incident response failure.
👉 Read our full editorial: Insider threat risk is amplified by exposed secrets and overprivilege
