AI agent skills turn repository files into a hidden execution path

At a glance

What this is: AI agent skills can introduce hidden executable files into repositories, and the key finding is that test runners may execute them automatically.

Why it matters: This matters because identity and access controls around NHI and agentic tooling are undermined if repository artifacts can trigger code execution outside the intended agent boundary.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Gecko Security's analysis of AI agent skills and hidden test execution

Context

AI agent skills are reusable instructions and helper files that developers can install into a project, but the governance problem starts when those files are treated as harmless content instead of executable supply-chain material. In this case, the primary identity concern is not the skill author alone, but the repository boundary that determines what later gets trusted and run.

The article shows that the installation path, not just the agent runtime, creates exposure. Once a skill is copied into the repo, common test runners may discover files inside hidden directories and execute them with the same local permissions as any other project code, which turns a packaging decision into an access-control problem for NHI and agentic workflows.

Key questions

Q: How should security teams handle AI agent skills that land in a repository?

A: They should treat them as repository supply-chain inputs, not just agent instructions. Review the full directory tree, not only the markdown file, because bundled tests and configs can execute through normal developer tooling. The safest pattern is allowlisting approved file types at installation time and excluding imported skill directories from test discovery in both local and CI environments.

Q: What breaks when hidden directories are included in test discovery?

A: Hidden directories become part of the execution boundary, which means untrusted files can run with the same privileges as trusted project tests. That creates a path for credential theft, data exfiltration, or malicious side effects during routine development and CI runs. The failure is not in the agent itself, but in the toolchain's assumption about where executable code may live.

Q: Why do skills create a bigger risk than prompt injection alone?

A: Because the risk extends beyond what the agent reads and into what the repository tools execute automatically. A skill can carry hidden payloads that never touch the prompt path, then trigger through test runners, linters, or config loaders. That means scanning only the agent-facing instructions leaves the broader repository execution surface ungoverned.

Q: What should teams do immediately to reduce skill-based supply-chain risk?

A: They should block auto-execution of imported skill directories, enforce a strict file allowlist during installation, and add CI guardrails that ignore hidden skill paths. Those three changes cut off the easiest route from packaged content to secrets exposure and reduce the chance that a malicious or careless skill can persist in source control.

Technical breakdown

How skill installers expand the execution boundary

Skill installers do more than place prompt instructions on disk. They copy an entire directory tree into the repository, which can include tests, scripts, configs, and reference files. That matters because the trust boundary shifts from the marketplace listing to whatever landed in the repo after installation. If the toolchain assumes only SKILL.md is relevant, it misses the real execution surface. In practice, repo-level artefacts inherit the privileges of the local development environment, including secrets present in CI and developer shells.

Practical implication: treat skill installation as code ingestion and apply file-type allowlists before content reaches the repo.

Why Jest and Vitest turn hidden directories into execution targets

Modern JavaScript test runners search recursively and, in current versions, include dot-directories in discovery. That means files under hidden paths such as .agents/ can still match default test patterns if they look like spec or test files. This is not an agent problem in isolation. It is a toolchain discovery problem. Once the runner sees a plausible test file, it executes it with the same privileges as any other test, regardless of where the file originated or why it was added.

Practical implication: add explicit ignore rules for hidden skill directories in every test and CI configuration.

Why a malicious test file is a high-value secrets-extraction path

A test file can look legitimate while running side effects in setup hooks such as beforeAll. That is powerful because test execution commonly occurs in local development and CI, where process environment variables, cloud tokens, SSH keys, and registry credentials are often present. The result is a repo-resident secrets exfiltration path that bypasses agent prompt scanners entirely. The danger is not that the agent read a bad instruction, but that the developer toolchain trusted a file it had no reason to distrust.

Practical implication: classify tests inside imported skill content as untrusted until they are manually reviewed and explicitly approved.

Threat narrative

Attacker objective: The attacker wants to convert a trusted repository workflow into silent secrets extraction from developer and CI environments.

1. Entry occurs when an attacker publishes a skill with a clean SKILL.md file but bundles a malicious test file inside the package. The victim installs it into the repository through the normal skill add workflow.
2. Escalation happens when the repository's test runner recursively discovers the hidden test file and executes it with full local permissions, including environment variables and filesystem access.
3. Impact occurs when the payload silently reads credentials, tokens, and local secrets, then exfiltrates them to an attacker-controlled endpoint without raising visible test failures.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Hidden repo artifacts create an identity boundary failure: The core issue is not that AI agent skills are inherently dangerous, but that repository ingestion expands trust from a named skill package into everything the package carries. That breaks the assumption that only agent-invoked instructions matter. Security teams need to treat the repository as the actual execution domain, because that is where developer tools decide what to trust.

Test discovery is the overlooked execution plane for NHI and agentic supply chains: Modern test runners are part of the identity path because they execute code with real credentials and real filesystem access. Once hidden directories are included in recursive discovery, a skill can become an execution trigger without any agent interaction. The implication is that governance must cover toolchain behaviour, not just the content reviewed by AI scanners.

Repository trust should be allowlisted, not assumed: The article exposes a simple but durable governance model failure: files bundled for convenience are being treated as if they are safe by default. That assumption fails when installed content can include tests, configs, and other auto-executing artefacts. The relevant control concept is a file-type allowlist for imported NHI and agentic assets, because trust should be granted by policy, not by package layout.

Skills marketplaces are becoming identity supply chains: Public skill registries now behave like distribution layers for executable repository content, which means their integrity matters in the same way package registries do. That does not make the marketplace the threat by itself. It means practitioners should re-evaluate intake, review, and revocation processes for every external artefact that can alter the developer runtime. The practitioner conclusion is straightforward: manage skill content as governed supply chain input, not as documentation.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• For identity teams, the Ultimate Guide to NHIs , 2025 Outlook and Predictions helps connect secrets governance to the wider machine identity lifecycle.

What this signals

Repository-installed skills should now be treated as governed identity supply chain objects. If a file can be copied into a repo and later discovered by routine tooling, it belongs in the same risk conversation as other non-human execution paths. Teams that already struggle with secrets hygiene should expect skill packaging to amplify that exposure unless installation boundaries are tightened.

Hidden directory execution is the practical weak point, not the AI model itself. The governance gap sits in development tooling that trusts file paths more than provenance. That means IAM, PAM, and NHI teams need to work with platform engineering on exclusion rules, file allowlists, and CI guardrails before these artefacts become normalised in production pipelines.

Skills packaging behaves like a small-scale supply chain, which makes lifecycle controls relevant. Import, review, revoke, and revalidate should apply to skill artefacts just as they do to other repository-adjacent assets. If the file lands in source control, it can outlive the original trust decision and keep executing long after the source package looks harmless.

For practitioners

• Add hidden skill directories to test exclusions Exclude .agents/ and similar paths in Jest, Vitest, and CI so repository-resident skill files cannot be auto-discovered and executed.
• Apply a file-type allowlist at skill install time Permit only SKILL.md, approved scripts, references, and assets when importing a skill into a repo, and block test, config, and build files by default.
• Review imported skills as repository content Treat every installed skill as untrusted code-adjacent material until the full directory tree has been inspected, not just the markdown instructions.
• Harden CI independently of project defaults Set CI-level ignore patterns for hidden skill directories so pipeline execution does not depend on developer-local configuration.

Key takeaways

• AI agent skills can turn ordinary repository files into hidden execution paths that bypass agent-centric security scanning.
• The material risk is secrets exposure through test discovery, because developer and CI environments often contain credentials when imported files are executed.
• The control response is to govern the repository boundary directly with file allowlists, hidden-directory exclusions, and CI guardrails.

Key terms

• Skill Package: A skill package is a bundled set of instructions and supporting files that extends an AI agent or developer tool with a specific task. In practice, it becomes part of the repository after installation, so its security posture depends on both provenance and everything else the package contains.
• Test Discovery: Test discovery is the process used by build tools to locate files that should run as tests. In this context, it matters because recursive discovery can include hidden directories and execute files that were never meant to be trusted as first-class project code.
• Repository Execution Surface: The repository execution surface is the set of files and paths that developer tools may read or run automatically. It includes tests, configs, hooks, and any imported artefacts that a runner, linter, or loader treats as trusted input.
• File Allowlist: A file allowlist is a policy that permits only specific file types or directories to enter a trusted environment. For imported skills and other NHI-adjacent artefacts, it is stronger than blacklist thinking because it blocks unexpected executable content before it reaches the repo.

What's in the full article

Gecko Security's full article covers the operational detail this post intentionally leaves for the source:

• The exact installer behaviour that copies skill directories into .agents/skills/ and leaves most files intact.
• The test runner discovery patterns for Jest and Vitest that make hidden directories eligible for execution.
• The proposed installer-side file allowlist and registry-side screening checks that this article only summarises.
• The concrete example configurations for excluding .agents/ paths from local and CI test runs.

👉 Gecko Security's full post covers the attack chain, test runner behaviour, and mitigation steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.