This page assumes you’ve already added and configured connectors for the systems whose secrets you want visibility into.
Find secrets across connected systems
The Secrets tab on the Inventory dashboard tracks API tokens and service account keys across your connected cloud and SaaS systems — Okta, GitHub, AWS, Snowflake, Datadog, and Google Cloud Platform sync secrets data directly. Each secret is attributed to the identity that holds it, and C1 alerts on ones that haven’t been used recently, so an unrotated or orphaned key doesn’t sit unnoticed.This is cloud- and SaaS-system visibility through connectors, not endpoint scanning — C1 doesn’t currently discover credentials sitting in files or config on an individual device. That’s the same gap the (not-yet-shipped) Shadow AI Discovery capability is meant to close.
Store and share secrets securely
Two distinct mechanisms cover this today, each with a different job:- Credential stores hold the initial passwords C1 generates when it provisions a new account through a connector. Store owners can decrypt any credential in the store to hand it off; the account’s own recipient can always decrypt their own. See Set up credential stores. This covers provisioning-generated passwords specifically — not arbitrary secrets you already hold elsewhere.
- Secret sharing is a zero-knowledge, one-time delivery mechanism for sending any secret — a password, an API key, a JSON service-account file, a
.envblock — to a specific person, inside or outside your org. Encryption happens in the sender’s browser before upload; C1 stores only the encrypted result and never sees the plaintext. Access expires after a set time or a set number of views, whichever comes first. See Secret sharing. Because C1 never holds the plaintext, this isn’t something a system can pull from programmatically — it’s built for a person handing a secret to another person.
Issue short-lived, scoped credentials instead of static ones
For agents and workloads specifically, C1 replaces a standing secret with a token issued at the moment of use, scoped narrowly and expiring quickly — but the mechanism depends on what’s asking for access:- An AI agent reaching an MCP server gets this through enterprise-managed authorization: C1 exchanges the signed-in user’s identity for a short-lived token addressed to that one server, checked against their entitlements at issuance.
- A CI/CD pipeline or other workload calling C1’s own API gets this through workload federation: your platform’s OIDC token (GitHub Actions, GitLab CI, HCP Terraform, SPIFFE, or any custom OIDC issuer) is exchanged for a short-lived C1 access token scoped to a service principal’s roles — no client secret stored anywhere.
Catch credential misuse
Decoys are tripwire credentials — shaped like a real human, service principal, connector, or workload federation credential, or a long-lived access token — planted where an attacker would look. Using one grants no access, but it’s a high-confidence signal that something’s compromised, and can be configured to raise a Critical finding automatically.Decoys and Findings are both early-access capabilities — check current coverage before relying on either for a specific scenario.