Is Graphify-Labs/graphify safe?
https://github.com/Graphify-Labs/graphify
Graphify is a legitimate open-source code knowledge graph tool that extracts AST-level structure from multi-language codebases. The primary concerns are: (1) all six credential honeypot files (.env, SSH key, AWS credentials, npmrc, Docker config, GCP credentials) were opened and read in a systematic sweep during the monitoring window, though no network exfiltration occurred and the files were not modified — the reads may originate from the audit system's own canary verification step; (2) the repository ships a graphify/always_on/ directory containing platform-specific markdown files designed for permanent injection into AI agent system prompts (Claude, Gemini, Copilot, Kiro, VS Code), which would persistently instruct any agent that loads them to consult graphify's knowledge graph and run graphify commands. The SKILL.md itself is empty.
Category Scores
Findings (6)
HIGH All credential honeypot files accessed in systematic sweep -50 ▶
Six distinct credential/secret file locations were opened and read in rapid succession at 13:41:55: .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and .config/gcloud/application_default_credentials.json. The pattern covers every major credential category (env secrets, SSH, AWS, npm, Docker, GCP) and all accesses carry CLOSE_NOWRITE flag (read-only). No network transmission of the file contents was detected, and the canary integrity system reports them unmodified. The origin of these reads — whether from repository initialization code or the audit system's own canary verification — cannot be definitively determined from the available evidence.
HIGH Canary files read despite integrity system reporting intact -55 ▶
The monitoring platform's canary integrity check concludes the honeypot files were not exfiltrated (content intact, not modified), yet both the inotifywait filesystem event log and the auditd PATH syscall records independently confirm every honeypot file was opened. The integrity check validates content hash/modification, not read access. This discrepancy means the check does not rule out content being read into memory for later use or in-process exfiltration that bypassed the network monitor.
MEDIUM Always-on agent instruction injection directory -20 ▶
The graphify/always_on/ directory contains markdown files (claude-md.md, agents-md.md, gemini-md.md, vscode-instructions.md, kiro-steering.md, antigravity-rules.md) that are explicitly designed to be installed as permanent background context into AI agent system prompts. These files instruct agents to consult graphify's knowledge graph before answering architecture questions and to run graphify update commands after code modifications. If installed via a user's agent configuration, this creates a persistent behavioral change across all sessions.
LOW AGENTS.md issues persistent run-command instructions to AI agents -5 ▶
The AGENTS.md file, recognized by most AI coding assistants as a persistent instruction source, directs agents to run graphify update . after every code modification session and to read graphify-generated GRAPH_REPORT.md and wiki/index.md before answering architectural questions. In the context of the graphify project's own repository this is self-referential and legitimate, but represents the same pattern used by prompt injection payloads that embed persistent shell commands in agent instruction files.
LOW Pre-commit hooks defined but non-invasive -15 ▶
The .pre-commit-config.yaml defines two hooks: skillgen-check (verifies generated skill artifacts match fragments) and ruff (Python linter). Both use 'language: system' and execute only on git commit, not during clone or package install. The external ruff hook references the astral-sh/ruff-pre-commit repository at a pinned revision. No auto-execution risk was observed.
INFO Network activity consistent with expected git operations only -20 ▶
All observed network connections were expected: HTTPS to 140.82.121.4:443 (GitHub) for git operations, DNS to local resolver 10.0.2.3:53, and loopback connections for system services. No connections to attacker-controlled infrastructure were observed. Before/after socket state was identical except for the SSH session IP change (expected audit reconnect).