Run GLM and Kimi Security Scans with Bex Security

Want to run a GLM security scan or Kimi Code security scan against a real codebase? Pointing a model at the repository is the easy part. The hard part is knowing whether its findings were scoped, validated, and preserved well enough for another engineer to trust. Bex Security now also supports a dedicated Muse Code security scan through its bundled community ACP adapter.

GLM and Kimi give developers more choice in model, price, context window, and agent runtime. That choice should not force a different definition of a complete security review. Whether the reasoning comes from GLM through Claude Code or Kimi through Claude Code or native Kimi ACP, the process should still scope the repository, collect evidence, challenge the finding, validate the fix, and preserve an artifact another engineer can inspect.

Today we are announcing Bex Security, an Apache-2.0, upstream-first fork of OpenAI Codex Security. It keeps that project's evidence-driven scan workflow while opening the agent boundary through the Agent Client Protocol. Codex remains the default, while GLM and Kimi security scans are available through alpha agent integrations; the workflow contract stays in one place.

Here is the concrete shape of the release before the philosophy:

After building Bex Security, a GLM security scan looks like this:

export ZAI_API_KEY="<your-zai-api-key>"
bex-security scan . --agent claude --provider zai --model glm-5.3

A Kimi security scan through Claude Code looks like this:

export KIMI_API_KEY="<your-kimi-api-key>"
bex-security scan . --agent claude --provider kimi --model kimi-for-coding

The rest of this post explains why both commands retain the same security contract, how to set them up safely, and when to choose native Kimi ACP instead.

Security Review Is a Workflow, Not a Clever Prompt​

A useful security finding is more than a model saying, "this looks vulnerable."

It needs a boundary: which repository, component, revision, and attacker capability are in scope? It needs evidence: which input reaches which sensitive operation, and which control fails along the way? It needs adversarial validation so a plausible explanation does not get promoted into a false positive. And if a patch is proposed, that patch needs to be tested against the same security property that produced the finding.

Codex Security already encodes much of this process. Its CLI and SDK support standard and deep scans, path and diff scopes, sealed scan artifacts, saved history, comparison across scans, SARIF/JSON/CSV exports, optional verified patches, and severity gates for CI. Bex Security preserves those capabilities instead of replacing them with a thinner "send the repo to a model" wrapper.

That is the first design decision behind the fork: the workflow is the product boundary. The model contributes reasoning, but Bex owns the repeatable steps around it:

1. Scope the repository, paths, or committed diff and establish the effective permissions.
2. Discover likely attack paths with the selected agent and model.
3. Validate candidate findings and reject unsupported claims.
4. Seal the report and its coverage data as reviewable local artifacts.
5. Remediate only when asked, then verify the changed files.
6. Compare or publish the result without pretending an incomplete scan is clean.

If two agents cannot execute that same contract, swapping between them is not portability. It is two different scanners sharing a command name.

Why Fork Codex Security Instead of Starting Over?​

Forks have a real cost. Every upstream release can introduce conflicts, change a schema, or alter a runtime assumption. Bex Security does not wave that away. Its public roadmap puts "stay current" first, and the repository deliberately retains the upstream @openai/codex-security package name and compatible codex-security command while the Bex package path matures.

The alternative cost is worse: reimplementing a security workflow means re-learning every edge case upstream already solved. Target selection, scan state, authentication, incomplete-coverage semantics, result validation, credential boundaries, patch verification, and machine-readable exports are not glamorous features. They are exactly the parts that decide whether a scan result can be trusted in CI or handed to another engineer.

So Bex Security is upstream-first by design:

• Improvements from Codex Security remain mergeable instead of being translated into a parallel architecture.
• Existing CLI habits and SDK code have a compatibility path.
• The open-agent work stays concentrated at a defined runtime boundary rather than spreading agent-specific conditions through the scanner.
• Divergence remains visible. Users can inspect the fork, compare it with upstream, and decide whether the tradeoff fits their environment.

This matters because the upstream public repository is a one-way projection: its contribution guide says outside pull requests cannot be imported into OpenAI's canonical source. Bex gives the community a place to develop portable agent support in public while continuing to consume upstream security work.

ACP Opens the Agent Layer Without Weakening the Contract​

ACP standardizes communication between a client and a coding agent over JSON-RPC. In Bex Security, the scanner is the ACP client. It starts an agent process, negotiates a session, streams progress, forwards cancellation, and exposes the scoped security workbench the agent needs.

ACP is not a universal model API, and it does not make agents equivalent. That distinction is important. Bex still has to verify that an integration can respect the scan scope, use the required tools, report progress, survive interruption, and produce artifacts that pass the same validation rules.

The current agent paths reflect that standard:

• Codex remains the default and the most compatible path.
• Codex over codex-acp proves the workflow can cross an ACP v1 boundary without becoming Codex-shaped internally.
• Claude Code over claude-agent-acp is available in alpha, including provider-scoped paths for Z.AI/GLM and Kimi models.
• Kimi Code over its native kimi acp server is also alpha and uses Kimi's saved authentication and provider settings.
• Muse Code over Bex's bundled muse-code-acp adapter is alpha. Because Muse does not expose delegated workers over ACP, Bex runs bounded host-managed review assignments and counts only completed, non-truncated file reads toward coverage.

The status label is intentional. "Alpha" means the vertical slice works, not that every agent/model combination has passed a mature compatibility matrix. The next work is full-scan fixtures, structured-output conformance, cancellation and interruption tests, then admitting more agents only when they satisfy the same artifact contract.

How to Run a GLM Security Scan or Kimi Security Scan​

Bex Security is published as @bex-co/bex-security. You need Node.js 22.13 or later in the Node 22 line (Node 24 and 26 are also supported) and Python 3.10 or later.

Install the CLI from npm:

npm install --global @bex-co/bex-security
bex-security --help

For the default Codex path, authenticate and scan a repository you own or are authorized to assess:

bex-security login
bex-security scan /path/to/repository

To run a GLM security scan, authenticate Claude Code locally, provide a scoped Z.AI API key, and select both the provider and model explicitly:

export ZAI_API_KEY="<your-zai-api-key>"
bex-security scan /path/to/repository \
  --agent claude \
  --provider zai \
  --model glm-5.3

Bex applies the Z.AI configuration only to the Claude ACP subprocess. It does not rewrite your Claude Code settings or store ZAI_API_KEY.

To run a Kimi security scan through Claude Code, use the Kimi provider path. It defaults to kimi-for-coding, or you can select another available Kimi model:

export KIMI_API_KEY="<your-kimi-api-key>"
bex-security scan /path/to/repository \
  --agent claude \
  --provider kimi \
  --model kimi-for-coding

For a native Kimi Code security scan, install Kimi Code, log in once, and select its ACP agent:

kimi login
bex-security scan /path/to/repository \
  --agent kimi \
  --model kimi-code/k3-256k \
  --effort high

The provider route and native route solve different setup needs. The Claude path lets teams keep Claude Code as the agent shell while changing the model provider. The native path lets Kimi Code own authentication, model selection, and the ACP session. In both cases Bex continues to own scan scope, workbench tools, validation, and final artifacts.

An ordinary scan is report-only. It writes scan state and results, not patches to the target repository. When you are ready to act on confirmed findings, opt in explicitly:

bex-security scan . --patch --patch-severity high

That command selects high and critical findings for remediation. Add --create-pr only when you want the tool to commit verified patch files and open a draft pull request. Keeping scan and mutation as separate decisions is a small interface choice with a large safety payoff.

Three Useful Ways to Put It to Work​

The quickstart proves the tool runs. These patterns make it useful in an engineering loop.

1. Review the change, not the entire history​

For a pull request or release branch, scan the committed diff against your base:

bex-security scan . --diff origin/main --json

This narrows the review to newly introduced attack paths and returns structured output for automation. It is not a substitute for periodic full scans; it is the faster gate you can run on every meaningful change.

2. Fail CI on serious findings without calling an incomplete scan clean​

Keep results outside the checked-out worktree and set a severity threshold:

BEX_SCAN_ROOT="$(mktemp -d)"
bex-security scan . \
  --diff origin/main \
  --output-dir "$BEX_SCAN_ROOT/results" \
  --json \
  --fail-on-severity high > "$BEX_SCAN_ROOT/findings.json"

A completed scan with a finding at or above the chosen threshold exits 1. Incomplete coverage or a runtime failure exits 2. That second state matters: "the scanner could not finish" must never collapse into "the scanner found nothing."

In CI, use OPENAI_API_KEY or CODEX_API_KEY for the Codex path rather than an interactive login. Supply only the credentials the scan needs.

3. Use a deeper scan when attack-path discovery matters more than speed​

For a release candidate or a security-sensitive subsystem, bound a deep scan explicitly:

bex-security scan . \
  --mode deep \
  --workers 2 \
  --subagents 0 \
  --stop-after-no-new 3 \
  --max-discovery-runs 10 \
  --max-time-hours 1.5

The limits make the tradeoff legible: more discovery breadth costs more time and model usage. Deep scans preserve completed findings when a time limit is reached and report incomplete coverage rather than silently presenting a partial search as exhaustive.

Run It Like a Security Tool, Not a Toy​

An AI security scanner reads valuable source code, invokes local processes, and may have access to credentials already present in its environment. Treat that operational boundary as seriously as the findings it produces.

The Bex Security policy is explicit about the current trust model:

• Scan only repositories you trust, own, or have permission to assess. Repository content can still be hostile data even when the assessment is authorized.
• Pass only necessary environment variables. Scan and workbench subprocesses can inherit variables beyond the OpenAI keys they deliberately remove, including credentials such as GITHUB_TOKEN or AWS keys.
• Keep credentials, Codex home, scan state, reports, logs, and SARIF outside the repository. Findings can contain source snippets and vulnerability details.
• Review patches before applying or merging them. Agent-produced output is evidence to verify, not authority to broaden scope.
• Do not use the local CLI as a multi-user isolation boundary. Processes sharing an operating-system account also share a trust domain.

These are not footnotes. Portability is only valuable if agent choice does not quietly expand permissions or change what "complete" means. Bex owns that boundary; operators still own the host and the credentials they expose to it.

What Comes Next​

Bex Security is early-stage, and we would rather publish the boundary honestly than hide it behind a broad compatibility claim.

The stable value today is the inherited Codex Security workflow, published npm CLI, SDK, provider support, scan artifacts, and the Bex-branded command. The open agent layer is the active build: hardening GLM security scans through Claude Code, Kimi security scans through both Claude and native ACP, Muse Code security scans through the community adapter, and Codex over ACP; extracting runtime-neutral workflow packs; and publishing capability-based compatibility evidence.

That work needs real repositories and real feedback. Which agent should be next? Which language or framework exposes a gap in discovery? Where does an alpha integration lose progress, mishandle a permission, or produce an artifact that is technically valid but operationally unhelpful? Those reports are more valuable than a long list of logos.

The goal is not to make every model look the same. It is to make the security contract durable enough that teams can choose the right agent without renegotiating what a trustworthy review means.

Sources: the Bex Security repository and quickstart, OpenAI Codex Security, the ACP architecture, and the Bex Security threat model and safe-use guidance.

If you want GLM and Kimi security scans backed by an open, evidence-driven workflow, star Bex Security on GitHub.