Securing API Keys

An API key is basically a password that lets an AI tool access a service on your behalf. When you build an AI project, you often connect to external models or platforms, and each connection uses a unique API key. If that key leaks, anyone can use your account, run up your bill, or steal your data.

Securing API keys means never storing them directly in your code or in places like GitHub, where they could be exposed. Instead, use secrets files (files hidden from version control) or a secrets manager to store them safely. You can also set different permissions for each key, so one AI agent might have read-only access while another can spend credits. This way, if a key is compromised, the damage is limited.

For professional AI projects, the rule is simple: the client should own their own API keys and pay for their own usage. This keeps billing transparent and prevents you from being on the hook for someone else’s costs. Before handing over any automation, run a security review to double-check that no keys are visible in logs, workflows, or conversation history. A clean handoff means the client knows exactly where to put their keys and how to set them up.

Ultimately, securing API keys protects your wallet, your data, and your client’s trust. Treat each key like a password—because in the world of AI development, it is.

Securing API keys is like protecting passwords—you never embed them directly into your source code. If you hard-code a key into a script and later push that code to a public GitHub repo, your key is exposed to anyone who views the file. Instead, always store keys in environment variables (settings stored outside your code). On your local machine, add your key to a `.env` file; on a deployment platform, paste the key into its environment variables section.

To get started, first locate your API key on the platform you are using. Typically, you find keys in the account settings under an "API Keys" section. When you generate a new key, immediately copy it and save it somewhere secure—many platforms show the full key only once. Never paste that key directly into a chat message or into your code logic. If you are working with a tool like Claude Code, explicitly tell it: "I will not give you my API key. I will put it in a local file myself." This keeps the key out of conversation history.

Before delivering a project, run a security review on your entire codebase to check that no keys or tokens are sitting in workflows or tool definitions. The clean handoff to a client should include a note that says: "Your API key belongs only in the `.env` file—not in the code or the workflow diagram." The client should always own and pay for their own keys, which keeps billing and responsibility transparent.

Securing API keys is critical because an API key (a password-like token that grants access to a service) accidentally exposed in code can let anyone use your account and run up bills. The most common mistake beginners make is embedding keys directly into source code. If that code gets pushed to a public repository or shared online, the key is immediately compromised. Instead, always store secrets (sensitive values like keys) in environment variable files, often called `.env` files. This keeps the key local to your machine and out of the code logic.

Before deploying any project, run a security review. Ask an AI tool to check for exposed keys, open webhooks, and other vulnerabilities. For client projects, the best practice is having the client create their own API key on their own account and paste it directly into the project. This way the key never travels over the internet to you, and the client retains full control and billing responsibility. When handing over a workflow, double-check that no keys or tokens remain in the files — provide clear instructions for where the client should place their own keys.

A related precaution: in some tools, an agent running automated tasks might be tricked into sending data to an external server. Using trusted execution modes can block those outbound requests, reducing risk. For private repositories where you control all inputs, this risk is very low, but it is still worth acknowledging.