Glint

See what your AI agents are really told and allowed to do.

Glint is an offline security scanner for the files that steer AI coding agents: AGENTS.md, CLAUDE.md, Cursor, Windsurf, Cline and Copilot rules, Claude Code settings and hooks, skills, saved tool listings and MCP server configs.

A single poisoned instruction, leaked token, over-powered tool or quietly changed MCP server can turn an agent against the person using it. Glint finds these problems before you commit, explains each one with evidence and an attack story, and tells you how to fix it.

Why Glint

• Reasons across tools, not just files. The lethal-trifecta check (GL-011) finds agents that can read private data, take in untrusted content and send data out, and names the single change that breaks the chain.
• Catches rug pulls. glint lock records approved MCP servers and tool descriptions; later scans show exactly what changed (GL-012).
• Shows what humans miss. glint reveal puts the rendered view next to what the agent actually reads: HTML comments, bidirectional overrides and invisible Unicode "tag" text.
• Hard to dodge. Look-alike letters, leetspeak, zero-width characters, line breaks and base64 do not hide an injection. The selftest command measures this and publishes the numbers.
• Built for teams. SARIF for GitHub code scanning, a ready-made GitHub Action, a pre-commit hook, baselines for existing repos, diff mode for pull requests, custom rules and an HTML report.
• Safe to run on hostile input. Offline, read-only, no dependencies, strict types. Escape codes in scanned files cannot rewrite the report, and secrets are always masked.

Install

pip install git+https://github.com/Sanjeet3326/Glint

Requires Python 3.11 or newer. Or run it from a clone with python -m glint.

Quick start

glint scan .                 # scan the current repository
glint reveal CLAUDE.md       # see hidden content in one file
glint graph .                # what each server, tool and permission lets the agent do
glint explain GL-011         # the attack story behind a rule

Try it on the demo project, where every rule fires:

git clone https://github.com/Sanjeet3326/Glint && cd Glint
python -m glint scan demo/vulnerable-agent

What it checks

Every rule maps to the OWASP Top 10 for LLM Applications 2025. Details, with examples of what each rule does and does not flag: docs/rules.md.

See what the agent sees

Find dangerous combinations

Each tool can be reasonable on its own and still be dangerous in combination. glint graph tags every MCP server, saved tool and permission with what it lets the agent do, and checks for the lethal trifecta.

glint graph --format dot | dot -Tsvg > agents.svg draws it with Graphviz. Tags are inferred from names and commands; correct them for your own servers in .glint.toml:

[capabilities]
"internal-wiki" = ["reads-private"]

Lock approved tools

glint lock            # write glint.lock after reviewing your MCP setup; commit it
glint lock --check    # in CI: fail if the lockfile is missing or out of date

The lockfile stores hashes of server commands, arguments and URLs, env and header key names (never secret values) and the name, description and schema of every tool in saved listings (*.tools.json, the JSON a server returns for tools/list). Any later change becomes a GL-012 finding with a word-level diff.

All commands

Useful scan options:

--fail-on low|medium|high|critical   exit 1 at or above this severity (default: high)
--format terminal|json|sarif|html    report format; --output FILE to write it
--baseline FILE / --write-baseline FILE   accept today's findings, report only new ones
--diff GIT_REF                       report only findings in files changed since GIT_REF
--rules GL-001,GL-005                run selected rules
--strict                             also check examples inside code blocks and quotes
--min-confidence low|medium|high     hide less certain findings

Exit codes: 0 nothing at or above --fail-on, 1 findings found, 2 usage or configuration error. The JSON report follows schema/report.schema.json.

Use it in CI

GitHub Action

name: Glint
on: [push, pull_request]
permissions:
  contents: read
  security-events: write
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: Sanjeet3326/Glint@v0.2.0
        id: glint
        with:
          fail-on: high
      - uses: github/codeql-action/upload-sarif@v4
        if: always()
        with:
          sarif_file: ${{ steps.glint.outputs.sarif-file }}

Findings then appear in the Security tab and as annotations on pull requests. The action also writes a summary to the job page. Inputs: path, fail-on, sarif-file, args (for example --baseline .glint-baseline.json).

pre-commit

repos:
  - repo: https://github.com/Sanjeet3326/Glint
    rev: v0.2.0
    hooks:
      - id: glint

Adopting Glint in an existing repository

glint scan . --write-baseline .glint-baseline.json   # accept what is there today
glint scan . --baseline .glint-baseline.json         # from now on, fail only on new findings

Baseline fingerprints use the rule, file and normalised evidence, not the line number, so editing a file does not make old findings look new.

Configuration

Optional .glint.toml in the scanned folder:

fail_on = "medium"
exclude = ["vendor/", "examples/**"]
disable = ["GL-007"]

[capabilities]
"internal-wiki" = ["reads-private"]

[[rules]]
id = "ORG-001"
title = "Internal hostnames in prompts"
severity = "medium"
applies_to = ["instructions", "prompt"]
pattern = '\b[a-z0-9-]+\.corp\.example\.com\b'
fix = "Do not put internal hostnames in agent files."

Custom rules are checked before use: patterns with nested quantifiers such as (a+)+, or that are slow on simple input, are rejected so a config file cannot hang the scanner.

Silence findings with .glintignore (path-glob or GL-005 path-glob per line) or inline with <!-- glint: ignore GL-002 --> on the same line or on its own line just above. Suppressed findings do not count toward the score but are still listed in JSON output.

Files it reads

Glint skips .git, node_modules, virtual environments, binary files, files over 2 MB and symlinks that point outside the scanned folder.

Results

Measured on v0.2.0 (reproduce with the commands shown):

• glint scan demo/vulnerable-agent: all 15 rules fire (26 findings).
• glint scan demo/clean-agent: 0 findings.
• 1,000 agent files scanned in 1.4 seconds on a 4-core Linux container.
• glint selftest: 138/138 generated attack variants detected, 0/40 benign samples flagged.

The self-test samples are generated by Glint's own test suite, so a perfect score is a regression guarantee, not a claim about attacks in the wild. Real attackers will find phrasings that no pattern list covers.

Threat model and limits

Glint is static analysis. It catches known patterns, hidden content and risky configuration, and it reasons about tool combinations, but it cannot catch a novel, well-disguised injection and it does not run or sandbox agents. Capability tags are inferred from names and can be wrong; override them in .glint.toml. Treat a clean scan as a good sign, not a guarantee.

How it works

collect -> parse -> per-file rules -> project rules -> ignores and baseline -> score -> report

Each rule is one class in glint/rules/; the registry discovers it, so adding a rule never touches the core. Project rules (the trifecta and drift checks) see every parsed file at once.

Related tools

mcp-scan focuses on MCP servers and their live tool descriptions; gitleaks and TruffleHog find secrets in general. Glint focuses on the agent files a repository ships, works fully offline, and covers permissions, hooks and tool combinations as well as prompts and MCP configs.

Contributing

See CONTRIBUTING.md. Report a detection bypass privately through SECURITY.md.

License

MIT © 2026 Sanjeet Kumar