# Security Best Practices for Storing ZHIPU_API_KEY in GLM-5

> Learn secure methods for storing your ZHIPU_API_KEY for GLM-5. Avoid committing credentials to source control and follow best practices for environment variable security.

- Repository: [Z.ai/GLM-5](https://github.com/zai-org/GLM-5)
- Tags: best-practices
- Published: 2026-06-19

---

**The GLM-5 repository requires the ZHIPU_API_KEY environment variable to be set at runtime and explicitly warns against committing credentials to source control.**

The zai-org/GLM-5 repository treats API credentials as sensitive secrets that must never be hard-coded. According to the project documentation in [`skills/glm-master-skill/SKILL.md`](https://github.com/zai-org/GLM-5/blob/main/skills/glm-master-skill/SKILL.md), all GLM skills that interface with the ZHIPU service expect the key to be provided via the environment variable `ZHIPU_API_KEY` at runtime, loading it through `os.getenv()` or equivalent methods.

## Use Environment Variables Exclusively

All GLM-5 skills read the API key from the runtime environment rather than configuration files or source code. In [`skills/glm-master-skill/SKILL.md`](https://github.com/zai-org/GLM-5/blob/main/skills/glm-master-skill/SKILL.md) at line 117, the documentation specifies that the skill expects `ZHIPU_API_KEY` to be available in the environment. This approach keeps the secret out of the codebase and allows different values per deployment environment—local development, CI testing, and production.

## Local Development with .env Files

For local development, store the key in a `.env` file that remains uncommitted. The repository explicitly recommends this pattern in [`SKILL.md`](https://github.com/zai-org/GLM-5/blob/main/SKILL.md) at line 122, reminding developers to add the `.env` file or the variable name to `.gitignore` to prevent accidental commits.

Load the variable using `python-dotenv`:

```python

# load_env.py

from dotenv import load_dotenv
import os

load_dotenv()                       # reads .env in the current directory

zhipu_key = os.getenv("ZHIPU_API_KEY")
if not zhipu_key:
    raise RuntimeError("ZHIPU_API_KEY not set")

# use zhipu_key to initialise the ZHIPU client …

```

Run your skill without a `.env` file by exporting the variable directly:

```bash
export ZHIPU_API_KEY="sk-xxxxxxxxxxxxxxxx"
python -m glm_master_skill.run   # the skill reads the variable at start‑up

```

## Repository Security Measures

Securing the `ZHIPU_API_KEY` requires proactive repository hygiene beyond environment variables.

**Add `.env` to `.gitignore`** – Create a pattern in your `.gitignore` file to exclude secret files:

```gitignore

# .gitignore

# Prevent accidental commit of API credentials

.env

```

**Never log or print the key** – Ensure log statements never interpolate the variable. Use placeholders or redact the value when debugging authentication issues.

**Audit repository history** – If a key ever slips into the Git history, purge it immediately using tools like `git filter-repo` or `BFG Repo-Cleaner`, then rotate the key. The repository's `.gitignore` provides patterns for ignoring sensitive directories like `profile_default/`, which you should extend to cover credential files.

## Production and CI/CD Deployment

Production deployments require additional safeguards beyond local development practices.

**Leverage CI secret management** – For automated pipelines (GitHub Actions, GitLab CI, etc.), store `ZHIPU_API_KEY` as a protected secret in the CI platform. Inject it as an environment variable at runtime rather than baking it into container images or deployment scripts.

**Rotate keys regularly** – When rotating credentials, update the value in your secret management system (or `.env` file for local development) and redeploy all services that depend on it. The GLM-5 architecture allows seamless rotation since the key is read at startup from the environment.

**Restrict permissions** – Configure the API key with minimal scope required by your GLM skills. If ZHIPU offers scoped keys, generate credentials limited to specific endpoints rather than using unrestricted master keys.

## Summary

- **Read from environment**: The repository expects `ZHIPU_API_KEY` via `os.getenv()` at runtime, as documented in [`skills/glm-master-skill/SKILL.md`](https://github.com/zai-org/GLM-5/blob/main/skills/glm-master-skill/SKILL.md).
- **Use `.env` files locally**: Store credentials in `.env` files for development, but never commit them.
- **Update `.gitignore`**: Explicitly exclude `.env` and credential files from version control (line 122 reference).
- **Secure CI/CD**: Use platform-specific secret management and inject values as environment variables.
- **Rotate and audit**: Regularly rotate keys and purge accidental commits from history using `git filter-repo`.

## Frequently Asked Questions

### What should I do if I accidentally commit ZHIPU_API_KEY to the repository?

Immediately rotate the key through the ZHIPU platform to invalidate the exposed credential. Then purge the secret from your Git history using `git filter-repo` or similar tools to remove the key from all commits. Update the `.gitignore` file to prevent future accidents, as recommended in the GLM-5 [`SKILL.md`](https://github.com/zai-org/GLM-5/blob/main/SKILL.md) documentation.

### Can I hardcode the API key for quick testing?

No. The GLM-5 source code explicitly expects the key via the `ZHIPU_API_KEY` environment variable. Hardcoding violates the repository's security model and risks committing credentials to version control. Use a local `.env` file and `python-dotenv` for testing instead.

### How does GLM-5 handle missing or invalid API keys?

The skills typically raise a runtime error or fail to initialize the ZHIPU client when `ZHIPU_API_KEY` is unset or invalid. Your application code should validate the presence of the key using `os.getenv()` and raise a descriptive error before attempting to initialize the client, as shown in the repository's loading examples.

### Is it safe to store ZHIPU_API_KEY in Docker environment files?

Only if the Docker `.env` file is excluded from version control and the container runtime has appropriate access controls. Follow the same `.gitignore` rules used for the main repository. For production containers, prefer runtime secret injection via orchestration platforms (Kubernetes secrets, Docker Swarm secrets) rather than build-time environment files.