Remove API Keys and Credentials Before Sharing

Remove API Keys and Credentials Before Sharing

An exposed API key is an open backdoor. A single leaked Stripe key enables unauthorized charges. An exposed AWS access key can rack up thousands in compute bills within hours¹. GitHub tokens grant full repository access. Yet these credentials appear routinely in code snippets, config files, and log output that developers paste into AI tools, share in Slack, or include in support tickets.

The scrubber detects all major credential formats, including generic API keys, cloud provider tokens, payment keys, and authentication tokens, and replaces each with a numbered placeholder before the text leaves your machine. Your debugging partner, AI tool, or vendor gets the structural context they need without any of the access-granting values.

Credential formats the scrubber detects

The scrubber detects 14 specific credential types: generic API keys with the sk- prefix, AWS access keys (AKIA prefix), GitHub personal access tokens (ghp_), GitLab personal access tokens (glpat-), Stripe live and test keys (sk_live_, sk_test_, pk_live_, pk_test_, rk_live_), Google API keys (AIza prefix), SendGrid keys (SG. prefix), Twilio Account SIDs (AC prefix + 32 hex characters)², NPM auth tokens (npm_ prefix), Slack tokens (xoxb-, xoxp-, xoxa-, xoxr-), JWT tokens (three base64url segments with eyJ header)³, database connection strings (postgres://, mysql://, mongodb://, redis:// with credentials), and PEM private key blocks. Each format receives its own token prefix so the variables file clearly identifies what was replaced.

Vendor-specific patterns versus generic detection

The vendor-specific patterns (AKIA for AWS, ghp_ for GitHub, AIza for Google) are highly precise and rarely produce false positives. The generic sk- prefix pattern casts a wider net, catching any key that follows the common secret-key convention. For tokens that do not match any vendor pattern, the scrubber falls back to a generic long-token pattern that flags strings with high entropy and minimum length. Custom internal tokens that do not follow common formats may require manual review after scrubbing.

Why API keys appear in shared text

Config files are the most common source: .env files, docker-compose.yml environment sections, deployment scripts, and CI/CD configuration all accumulate credentials over time. Stack traces and error messages are the second source, and a database connection failure often includes the connection string in the error message. Furthermore, code review and debugging sessions regularly involve pasting config context alongside the code under review. Each of these scenarios creates a moment when credentials travel outside your controlled environment. Scrubbing before each paste eliminates that moment.

You should pay special attention to credentials that have been committed to version control, even if they were later removed. Git history preserves every committed file, and tools like truffleHog and git-secrets exist specifically because committed credentials are one of the most common leak vectors. When you paste a git diff or a log file that references a previously committed credential, the scrubber detects the credential pattern in the text. This catches the exposure even when the credential is no longer present in the current codebase but is still visible in historical context.

The cost of a leaked credential

AWS access key exposure is the canonical credential leak example: automated scanners on GitHub can find and exploit a committed AKIA key within minutes of a push⁴, resulting in thousands of dollars in charges and a compromised cloud account. Stripe key exposure enables unauthorized API calls and refunds. GitHub token exposure gives an attacker full read and write access to your repositories, including the ability to modify code in transit. Building on this, even "test" keys from staging environments often have broader permissions than intended. Scrubbing before sharing is the low-friction prevention step that avoids all downstream remediation.

You should treat credential exposure through AI tools with the same severity as a public GitHub commit. When you paste a credential into an AI tool, that credential has left your controlled environment and now exists on the AI provider's infrastructure. The provider's data retention policy determines how long it persists. For high-value credentials (AWS root keys, production Stripe keys, GitHub organization tokens), exposure through an AI prompt should trigger the same incident response as a public leak: rotate the credential immediately, audit access logs for unauthorized use, and document the incident for your security team.

Infrastructure-as-code files and CI/CD configurations that accumulate credentials

Terraform configuration files carry the highest credential density of any non-application file type in a developer's project. Variable files (.tfvars) store provider credentials, database passwords, and API tokens as plain-text key-value pairs. Terraform state files (terraform.tfstate) contain the applied values of every resource Terraform manages, including computed connection strings and resource IDs that may include embedded credentials. Developers paste both file types into AI tools when debugging Terraform plan failures, resource drift, or provider authentication errors.

Kubernetes Secret manifests store base64-encoded credential values that many developers mistake for encryption. A Secret manifest containing data.DB_PASSWORD: aGVsbG8= looks obfuscated but is simply "hello" base64-decoded. When developers paste Kubernetes YAML into AI tools for review or debugging, these encoded values travel to the AI provider in decodable form. Scrubbing before pasting detects the credential pattern in the decoded value and tokenizes it, regardless of whether the YAML stores the credential as raw text or base64.

Scrubbing GitHub Actions workflow files before AI review

GitHub Actions workflow files in .github/workflows/ accumulate env: blocks and with: parameters that reference secrets via ${{ secrets.MY_SECRET }} syntax. The secrets references themselves are safe to share because they are variable names, not values. However, developers sometimes hardcode credential values during testing and commit them by mistake, leaving real credentials in workflow files. When requesting AI review of a workflow file, catch hardcoded values before AI review by pasting it through the scrubber first, before any of it reaches the AI provider's context window.

Responding to an API key exposure incident

Rotation begins the moment you confirm exposure. Every second a compromised key remains active, an attacker with the key can make authorized API calls on your behalf. For AWS IAM access keys, rotation means creating a new key pair in IAM, updating every system that uses the old key (EC2 instance roles, ECS task definitions, Lambda environment variables, CI/CD pipeline secrets), verifying the new key works across all dependent systems, and then deactivating and deleting the old key pair. AWS provides the key last-used timestamp in the IAM console, which confirms which services were actively using the key before rotation.

For GitHub personal access tokens, revoke the exposed token immediately at github.com/settings/tokens, then generate a new token with the minimum required scopes for each use case. For Stripe live keys, log in to the Stripe Dashboard, navigate to Developers → API Keys, roll the live secret key, and update your payment processor integration. Stripe live key rotation is instant: the old key is revoked the moment you click roll, with no grace period during which both keys remain valid⁵.

Pre-commit hooks as a permanent credential detection layer

Tools such as git-secrets (by AWS Labs), gitleaks, and detect-secrets (by Yelp) intercept the git commit command, scan staged file changes for credential patterns, and block the commit if credentials are detected. Installing gitleaks as a pre-commit hook requires adding it to .pre-commit-config.yaml and running pre-commit install⁶. For teams using GitHub, the GitHub secret scanning feature automatically blocks pushes containing known credential formats and notifies the repository admin. These tools address the accidental commit path; the scrubber addresses the paste-to-AI path. Both controls together close the two most common credential exposure vectors in developer workflows.

The scrubber adds the missing paste-time layer, because pre-commit hooks cannot see credentials as they enter an AI prompt. CapyToolkit processes the text locally in your browser with no transmission, so the leaked key is tokenized before it reaches any provider, and the variables file is the only artifact that maps back to the original secret.

When to use this

Use this before pasting any config file, .env file, stack trace, CI/CD log, or code snippet that might contain API keys, service tokens, or database connection strings into any tool or channel outside your local environment.

Examples

OPENAI_KEY=sk-proj-abcdef123456
AWS_KEY=AKIAIOSFODNN7EXAMPLE
GH_TOKEN=ghp_abc123def456ghi789jkl

OPENAI_KEY=[API_1]
AWS_KEY=[AWS_1]
GH_TOKEN=[GH_1]

Error: Connection refused to postgres://admin:[email protected]:5432/myapp at startup

Error: Connection refused to [DBURL_1] at startup