secret-handling

Block agents from reading live .env credentials and writing secrets to committed files.

Updated Apr 14, 2026
One-click install
npx skills add https://github.com/robpitcher/eShopOnWeb --skill secret-handling-robpitcher
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: secret-handling
Source: https://github.com/robpitcher/eShopOnWeb/tree/main/.copilot/skills/secret-handling
Command: npx skills add https://github.com/robpitcher/eShopOnWeb --skill secret-handling-robpitcher

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Spawned agents have read access to the entire repository, including .env files containing live credentials. This skill codifies absolute prohibitions and safe alternatives to prevent credentials from being read or written to committed files.

Core Features & Use Cases

  • Prohibited File Reads: NEVER read these files:
    • .env (production secrets)
    • .env.local (local dev secrets)
    • .env.production (production environment)
    • .env.development (development environment)
    • .env.staging (staging environment)
    • .env.test (test environment with real credentials)
    • Any file matching .env.* UNLESS explicitly allowed (see below)
  • Allowed alternatives:
    • .env.example (safe — contains placeholder values, no real secrets)
    • .env.sample (safe — documentation template)
    • .env.template (safe — schema/structure reference)
  • If you need config info:
    1. Ask the user directly — "What's the database connection string?"
    2. Read .env.example — shows structure without exposing secrets
    3. Read documentation — check README.md, docs/, config guides
    • NEVER assume you can "just peek at .env to understand the schema." Use .env.example or ask.
  • NEVER write secrets to .squad/ files
    • See prohibited output patterns and examples
  • Scribe Pre-Commit Validation: Scan staged files for secret patterns before commit; block if detected, and report to user.
  • Remediation & Guardrails:
    • If a secret was already committed, stop, alert, rotate credentials, and clean history.

Quick Start

Configure the agent to never read live secrets and to reference safe placeholders (like .env.example) for configuration schema.

Frequently Asked Questions about secret-handling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent automated agents from reading live credentials in .env files?

Prevent reading live credentials by enforcing absolute prohibitions against accessing .env files and directing agents to read safe placeholders like .env.example or .env.template for configuration schema instead of exposing real secrets.

How do I stop secrets from being written to committed files in CI workflows?

To stop secrets from being written to committed files, implement pre-commit validation that scans staged files for secret patterns. If detected, block the commit, alert the user, and require credential rotation and history cleanup before proceeding.

What is the safe way to share environment configuration structure without exposing secrets?

The safe way to share environment configuration is using .env.example, .env.sample, or .env.template files. These contain placeholder values and document the schema without exposing real production, staging, or development credentials.

What should I do if a secret was accidentally committed to git history?

If a secret was accidentally committed, stop immediately, alert the team, rotate the compromised credentials, and clean the git history. Use remediation guardrails to detect leaked secrets and block further commits containing sensitive patterns.

Can I use .env.example files to understand database connection requirements without accessing real secrets?

Yes, you can use .env.example, .env.sample, and .env.template files to understand database connection requirements and configuration structure. These safe alternatives contain placeholder values instead of real credentials, preventing secret exposure during code analysis.

Why does my repository automation agent still try to read .env files despite security policies?

Repository automation agents may still read .env files if absolute prohibitions are not codified into their workflow. Enforce strict reading prohibitions for files matching .env.* and implement guardrails to detect and block unauthorized secret access attempts.