/security-secrets

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select security-secrets from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv security-secrets, /just-vibe security-secrets and /jv:security-secrets in Claude. See shortcut setup and context examples.

What the agent does

1. Run approved scanners with redacted output over the requested sources, copying no values into reports.
2. Distinguish placeholders from plausible secrets, and map exposure surfaces.
3. Propose owner- and provider-specific remediation.

Inputs

• repository/history/log scope and approved scanner capability.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Locate likely exposed secrets and identify containment needs; no implicit credential rotation or history rewrite.

Writes

No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.

Mode

Inspect; repository/history/log scope and approved scanner capability.

Prerequisites

Defined application boundary, authorized code/environment, relevant trust/access rules, and evidence sources. Default to defensive inspection; active tests use owned or explicitly authorized isolated targets. Minimize sensitive evidence and never print usable credentials.

Expected output

• Redacted locations and types with confidence, exposure context and scope, uncertainty, and a containment and remediation sequence.

How the work is checked

• A committed credential is reported without its value; test placeholders do not inflate findings blindly.

When to stop or clarify

• Never test suspected credentials against live providers without authorization. Do not copy secrets into reports, shell history, or external scanners.

Handling missing context

Infer

Resolve the requested surface, source/runtime version, reachable callers and actual trust/access boundaries.

Assume

Start with source analysis and bounded owned fixtures; treat scanner output as leads and preserve legitimate controls.

Ask

Ask when target authorization or necessary trust semantics are unresolved before active probing; source inspection need not wait for production access.

Technical guidance

Evidence

Inspect scoped source, tracked history when requested, build outputs and redacted scanner locations.

Method

Distinguish placeholders/public identifiers from secret material; report type/location without value and separate remediation from rotation/history changes.

Pitfall

Testing a suspected credential against its provider exposes it and exceeds source review; deletion does not revoke an exposed credential.

Check

Use fake canaries and benign placeholders to validate redaction and detection; identify unknown rotation status without trying live keys.

Situational decisions

When a plausible credential is found: Record location/type and rotation owner/provider steps; do not test it against a live service by default.

When the user asks to contain a confirmed exposure: Plan the order: revoke or rotate first, because a pushed secret is already exposed; then remove it from the tree and move it to a secret store through security-fix; only then, if requested, purge history, coordinate the force-push and ask the Git host to drop cached views, and verify with a re-scan and the provider key-usage log. Revocation, rotation, force-push and host purge are separate external or destructive actions that each need an exact target.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring