policy.default: role:admin in argocd-rbac-cm makes every account in your SSO directory an Argo CD admin, and a deny rule cannot take that back. A repository Secret with its password under stringData is readable by everyone who can read the Git repository. An ApplicationSet that takes its project from a tenant's config.json lets that tenant move its Applications into the platform project. This skill finds those and the other Argo CD mistakes below, and tells you how to fix each one.

Your agent runs a scanner on the YAML files of your GitOps repository: Application, ApplicationSet and AppProject manifests, argocd-cm, argocd-rbac-cm and argocd-cmd-params-cm (also as kustomize patches and configMapGenerator literals), argocd-secret, Notifications config, repository, credential-template and cluster Secrets, the argocd-server Service and Deployment, and values files of the argo-cd and argocd-apps Helm charts. It reads the YAML inside oidc.config and dex.config, Helm values blocks and cluster config JSON with their own line numbers, treats $key, $secret:key, ${VAR}, vault-plugin path placeholders and SOPS ENC values as references kept outside the file, checks the argo-cd chart's values.yaml even when its comments hold Helm template examples, and skips Helm chart templates and documents that have nothing to do with Argo CD. It never contacts a cluster, Argo CD or a Git server and never uses the network. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach. Secrets are never printed.

What it checks

BLOCK (fix before shipping)

• A01: passwords, tokens, private keys and client secrets written in Argo CD files (repository, credential-template and cluster Secrets, argocd-secret, SSO clientSecret or bindPW in argocd-cm, notification tokens, argo-cd Helm values, Helm parameters, values and plugin env inside an Application, a password in a repository URL)
• A02: anonymous access (users.anonymous.enabled: "true")
• A03: policy.default: role:admin
• A04: authentication turned off (server.disable.auth or --disable-auth)
• A05: repositories reached over http:// or git:// on a public host (a public IP or a public domain; in-cluster names such as gitea-http.gitea and private addresses are not reported)

REVIEW (check before release)

• A11: AppProjects that can deploy to any namespace on any cluster or on Argo CD's own cluster, or accept Applications from every namespace
• A12: AppProjects that allow every cluster-scoped kind (clusterResourceWhitelist group '*', kind '*')
• A13: production Applications (pre-prod and non-prod do not count) that track HEAD, a branch, no targetRevision, a semver range on Git tags, or a Helm chart version range
• A14: automated sync with prune and allowEmpty
• A15: TLS turned off: insecure repositories or clusters, internal TLS off, TLS 1.0 or 1.1, or server.insecure while a LoadBalancer, or a NodePort without a TLS ingress in front, exposes argocd-server directly
• A16: the web terminal turned on (exec.enabled)
• A17: the local admin left on next to SSO, or the admin password hash committed
• A18: ApplicationSets whose project comes from Git, SCM provider, pull request or plugin generator data

What's included

• The scanner (Python 3.9+, standard library only)
• A rules guide with the reason, safer approach and official Argo CD documentation link for each rule
• A risky and a safe example (a self-managed Argo CD with its config maps, a repository Secret, a project, a production Application and a tenant ApplicationSet), and the real report the scanner produces on the risky one

Limits

It reads each YAML file as written. Helm chart templates (files in a chart's templates/ folder or with unquoted Helm directives) are skipped; Jsonnet, JSON manifests and kustomize output are not rendered, and settings made outside the repository (the argocd CLI or UI, Secrets created by a secret operator, the live cluster) are not seen. server.insecure alone is not reported, because Argo CD's ingress docs use it behind a TLS-terminating ingress. "Production" in A13 is decided from names, so check those findings against your release process. Credentials in other Kubernetes objects are left to other checks. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 26 files: SKILL.md, the scanner in scripts/ (5 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (18 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.