API credentials hygiene

Audits and hardens API credential handling (env vars, separation, rotation plan, least privilege, auditability). Use when integrating services or preparing production deployments where secrets must be managed safely.

Security Scan

The skill's stated purpose (auditing/hardening API credential handling) matches its instructions and requirements; it's an instruction-only skill that asks for documentation and templates but does not request credentials or install code.

Purpose & Capability

Name, description, inputs, and outputs are consistent: the SKILL.md asks for lists of integrations/config snippets and produces credential maps, rotation runbooks, and templates — all coherent with an 'API credentials hygiene' auditor.

Instruction Scope

Instructions stay within the claimed scope: inventory credentials, propose env var mappings, rotation plans, and audit logs. It accepts optional config snippets and explicitly warns not to output real secrets and to be read-only by default. There are no instructions to read arbitrary system paths or send data to external endpoints.

Install Mechanism

No install spec and no codefiles — instruction-only. This minimizes disk and execution risk (lowest-risk category).

Credentials

Skill does not request any environment variables or credentials in its metadata. However, many of its recommended actions (moving secrets to a secret manager, updating deployment configs) could require credentials or elevated access if the user asks the agent to perform changes. The skill itself does not ask for those secrets — exercise caution if you provide secret-manager/API credentials to the agent later.

Persistence & Privilege

always is false and the skill is user-invocable. It does not request persistent presence or to modify other skills or system-wide settings.

Assessment

This skill appears coherent and low-risk as distributed: it only provides auditing guidance and templates and does not request credentials or install software. Before using it, do not paste real secrets — provide redacted or placeholder config snippets. If you ask the agent to apply changes (e.g., update deployment files or call your secret manager), do not hand over secret-manager/API keys unless you trust the agent runtime and have scoped credentials (least privilege, short-lived tokens). Prefer manual review/approval of any runbook or file modifications, and ensure outputs contain placeholders (as the skill requires) rather than real tokens. If you need legal/compliance sign-off, obtain that outside this tool — the skill explicitly says it is technical guidance only.

API credentials hygiene: env vars, rotation, least privilege, auditability

PURPOSE

Audits and hardens API credential handling (env vars, separation, rotation plan, least privilege, auditability).

WHEN TO USE

• TRIGGERS:
  • Harden the credentials setup for this integration and move secrets into env vars.
  • Design a key rotation plan for these APIs with minimal downtime.
  • Audit this service for least-privilege access and document what each key can do.
  • Create an environment variable map and a secure .env template for this project.
  • Set up credential separation for dev versus prod with clear audit trails.
• DO NOT USE WHEN…
  • You want to obtain keys without authorization or bypass security controls.
  • You need legal/compliance sign-off (this outputs technical documentation, not legal advice).

INPUTS

• REQUIRED:
  • List of integrations/APIs and where credentials are currently stored/used.
  • Deployment context (local dev, server, container, n8n, etc.).
• OPTIONAL:
  • Current config files/redacted snippets (.env, compose, systemd, n8n creds list).
  • Org rules (rotation intervals, secret manager preference).
• EXAMPLES:
  • “Keys are hard-coded in a Node script and an n8n HTTP Request node.”
  • “We have dev and prod n8n instances and need separation.”

OUTPUTS

• Credential map (service → env vars → scopes/permissions → owner → rotation cadence).
• Rotation runbook (steps + rollback).
• Least-privilege checklist and audit log plan.
• Optional: .env template (placeholders only). Success = no secrets committed or embedded, permissions minimized, rotation steps documented, and auditability defined.

WORKFLOW

1. Inventory credentials:
   • where stored, where used, and who owns them.
2. Define separation:
   • dev vs prod; human vs service accounts; per-integration boundaries.
3. Move secrets to env vars / secret manager references:
   • create an env var map and update config plan (no raw keys in code/workflows).
4. Least privilege:
   • for each API, enumerate required actions and reduce scopes/roles accordingly.
5. Rotation plan:
   • dual-key overlap if supported; steps to rotate with minimal downtime; rollback.
6. Auditability:
   • define what events are logged (auth failures, token refresh, key use where available).
7. STOP AND ASK THE USER if:
   • required operations are unknown,
   • secret injection method is unclear,
   • rotation cadence/owners are unspecified.

OUTPUT FORMAT

Credential map template:

CREDENTIAL MAP
- Integration: <name>
  - Env vars:
    - <VAR_NAME>: <purpose> (secret/non-secret)
  - Permissions/scopes: <list>
  - Used by: <service/workflow>
  - Storage: <secret manager/env var>
  - Rotation: <cadence> | <owner> | <procedure>
  - Audit: <what is logged and where>

If providing a template, output assets/dotenv-template.example with placeholders only.

SAFETY & EDGE CASES

• Never output real secrets, tokens, or private keys. Use placeholders.
• Read-only by default; propose changes as a plan unless explicitly asked to modify files.
• Avoid over-broad scopes/roles unless justified by a documented requirement.

EXAMPLES

• Input: “n8n HTTP nodes contain API keys.”
  Output: Env var map + plan to move to n8n credentials/env vars + rotation runbook.

• Input: “Need dev vs prod separation.”
  Output: Two env maps + naming scheme + access boundary checklist.