> ## Documentation Index > Fetch the complete documentation index at: https://www.c1.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Use case: Secrets management > See how C1 gives visibility into secrets across connected systems, stores and shares them securely, and issues short-lived scoped credentials instead of static ones — and where the gaps still are. A static API key handed to a person, a script, or an agent is a standing risk: no expiry, easy to leak, hard to revoke cleanly — and leaked credentials remain one of the most common root causes behind breach disclosures. This page covers what C1 does about that today — which is a few distinct, narrower mechanisms rather than one unified secrets vault, so this page is precise about what each one actually covers rather than describing them as a single system. This page assumes you've already [added and configured connectors](/docs/baton/intro) for the systems whose secrets you want visibility into. ## Find secrets across connected systems The [Secrets tab](/docs/product/admin/inventory#track-unused-secrets) 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](/docs/product/admin/account-provisioning) 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](/docs/product/admin/vaults). 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 `.env` block — 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](/docs/product/admin/secret-sharing#how-it-works). 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](/docs/product/use-cases/agent-sso-runtime-governance): 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](/docs/product/admin/service-principals/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. Neither of these is a general-purpose vending machine that hands any agent a scoped credential for any downstream system yet — each covers a specific target (an MCP server, or C1 itself). For everything else, provisioning and access requests still govern who gets an account and what it can do, per the [identity governance use case](/docs/product/use-cases/identity-governance). ## Catch credential misuse [Decoys](/docs/product/admin/decoys#plant-a-decoy) 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](/docs/product/admin/findings) automatically. Decoys and Findings are both early-access capabilities — check current coverage before relying on either for a specific scenario. ## Related resources