How to use the Offensive CI/CD Secrets agent skill: install and scope

What the skill makes the agent do

An agent skill is a folder containing a SKILL.md file. When a skill is installed, the agent reads that file as guidance when a request matches its description. This skill is written from an attacker's point of view. Its SKILL.md describes a workflow: gain code execution in a pipeline, enumerate the runner environment, check environment variables and secrets managers, review build logs and caches, test OIDC trust where cloud integration exists, validate what is recovered, and then consider pivoting.

The source lists coverage areas including environment variable exposure in build contexts, misconfigured vault and secrets-manager integrations, runner and agent token abuse, OIDC federation trust between CI/CD providers and clouds, build log leakage, cache poisoning, platform credential stores, Azure DevOps and GCP service connections, and Docker registry credentials. The file's own description says each section covers enumeration, extraction and post-exploitation guidance.

This page does not reproduce the skill's commands or exfiltration techniques. Read the SKILL.md itself if you need the detail, and only use it on systems you are authorized to test.

Install the skill from the ZIP

Download the ZIP for the skill from this page. The skill has a single file, SKILL.md, so the archive is small. Unzip it so that the skill folder sits inside the skills directory that applies to you.

For a personal install across your projects, place the folder in your user skills directory. For a single project, place it in that project's own .claude folder so it is available only there. You can also upload the ZIP through the Claude apps under Settings, then Capabilities, then Skills.

• Personal install: unzip into ~/.claude/skills/
• Project install: unzip into the project's .claude/skills/ folder
• Claude apps: Settings, then Capabilities, then Skills, then upload the ZIP

Trigger the skill with natural requests

You do not need a special command. Describe the task in plain language that matches the skill's subject, such as reviewing secrets exposure in a CI/CD pipeline you have been authorized to test. Include the scope, the platform and the goal, so the agent can keep its work tied to the engagement.

Good requests name the authorization and the outcome. Vague requests about getting into someone's pipeline should be refused, and the agent should ask for scope before doing anything that touches a live environment.

• Under our signed statement of work, map which secrets in the GitHub Actions pipeline for the staging repo are exposed to untrusted pull requests, and report the findings.
• Review how our GitLab CI jobs read Vault secrets and flag over-permissioned tokens for the client report.
• Explain which T1552 sub-techniques apply to our Jenkins credential setup so we can write detection rules for them.

Keep use inside written authorization

The skill is a detailed attack playbook. Its own description states that it is not meant for systems you do not own or lack written authorization to test, and that using it against others is illegal. Treat written scope as a precondition, not a formality. Confirm which repositories, pipelines, runners and cloud accounts are in scope before the agent runs anything.

Avoid running recovered secrets against systems outside the agreed scope. Record what you touched and why, and stop when the engagement rules say to stop.

• Confirm written scope and rules of engagement before the first request
• Use test or staging pipelines where the client agrees to it
• Do not exfiltrate real credentials outside the engagement's agreed channels
• Report and rotate any real secrets you find

Requirements and runtime behaviour

The source lists no prerequisites. The skill does not run scripts and does not use the network by itself. It is a set of written instructions. Any commands the agent runs will execute in whatever environment you give it, so the real requirements depend on your own tools and access, and the blast radius depends on what you allow.

Because the file is guidance rather than code, the main safety question is what the agent is permitted to execute. Run it in a sandboxed, authorized test environment, and review each command before it runs.

• Listed requirements: none
• Runs scripts: no
• Uses network: no (the skill file itself)

Tips for defenders and detection engineers

If your goal is detection, use the skill to understand attacker paths, then build alerts around the observable events: unexpected reads of secret stores, unusual OIDC token requests, unexpected outbound traffic from build jobs, and secrets appearing in logs or caches. Test those alerts in a lab you own.

If your goal is remediation, the skill is a poor starting point. It focuses on exploitation and gives little guidance on fixing the weaknesses it describes. Look for platform hardening guides from the CI/CD vendor and your cloud provider instead.

• Map each attack path to a log source you can monitor
• Validate alerts in a lab you own
• Use vendor hardening guidance for fixes