Ask It Simply
Build With AI · Advanced · Lesson B2

Keep your keys secret

about 8 minutes. Level: Builder. Nothing to install: a Google Colab notebook with a FAKE key, plus copy-paste lines.

By Dontè

Watch the video

Lesson video, about 3 min 12 s. Captions are off by default. Press CC to turn them on. It starts muted. Press Sound to hear the lesson from the start. Press and hold the playing video (or hold the period key) to watch at 2x speed.
Show transcript

Welcome to Lesson B2. In Lesson A2 you made an API key so your code could talk to Grok. Today you'll learn how to keep that key safe, and what to do if it ever leaks.

Our tip: think of a key as a password tied to your bill. Anyone who has it can use your account, and you pay.

The biggest danger is putting the key right in your code. OWASP, a respected security group, warns that many organizations have secrets, quote, "hardcoded within the source code in plaintext." End quote. If that code gets shared or posted online, the key goes with it.

The fix uses two small files. A dot env file holds your secrets, one per line. Your code reads from it. A dot gitignore file is a list of files that Git, a tool for saving and sharing code, should never upload. We put dot env on that list.

Let's try it. Open Google Colab, start a new notebook, and paste the code block from the lesson page into one cell. Notice the key in this code is fake on purpose. It literally says not a real key.

Part one writes a practice dot env file with our fake key. Part two writes a dot gitignore that hides dot env. Part three reads the key from the file, without typing it into the code.

Press Run. We see the first eight characters of the fake key, then three dots. And the gitignore says dot env. It worked.

Our tip: when you print a key to check it, show only a few characters, never the whole thing. That way a screenshot can't leak it.

There's also a safety net. GitHub, a popular site for sharing code, has a tool that hunts for leaked keys. GitHub says, quote: "Secret scanning scans your entire Git history on all branches of your repository for hardcoded credentials, including API keys, passwords, tokens, and other known secret types." End quote.

Our tip: a safety net is nice, but don't count on it. Keep keys out of your code from the very start.

So what if a key does leak? Our tip, in this order. One, remove or disable the old key in the provider's console, if it offers a way. Two, make a new key. Three, put the new key in your dot env file or Colab Secrets. Four, check your usage page for charges you don't recognize.

Safety check. Our tip: a leaked key can run up a bill. Remove it, then make a new one. And never paste a real key into a chat, a screenshot or a lesson exercise.

Quick check. Where should a key live? In a dot env file or Colab Secrets, never in the code. What does dot gitignore do? It tells Git not to upload certain files. And the first step if a key leaks? Remove or disable it, then make a new one. Next, in Lesson B3, you'll build an agent that watches a stock price and alerts you.

What you'll learn

Step 1: Why keys matter

In Lesson A2, you made a key so your code could talk to Grok. Our tip: think of a key as a password tied to your bill. Anyone who has it can use your account.

The big danger is putting the key right in your code. OWASP, a respected security group, warns that many organizations have secrets "hardcoded within the source code in plaintext." (OWASP Secrets Management Cheat Sheet) If that code gets shared or posted, the key goes with it.

Step 2: Two new files

Step 3: Try it in Colab (fake key only)

Open a new notebook at colab.research.google.com. Paste this into one cell and press Run. The key is fake on purpose.

# 1. Write a practice .env file with a FAKE key
with open(".env", "w") as f:
    f.write("XAI_API_KEY=xai-FAKE-0000-not-a-real-key\n")

# 2. Write a .gitignore that hides .env from Git
with open(".gitignore", "w") as f:
    f.write(".env\n")

# 3. Read the key from .env without typing it into the code
key = None
for line in open(".env"):
    if line.startswith("XAI_API_KEY="):
        key = line.strip().split("=", 1)[1]

print("Key loaded:", key[:8] + "...")   # show only the first few characters
print(".gitignore says:", open(".gitignore").read().strip())

What you should see: the first 8 characters of the fake key followed by "...", and ".gitignore says: .env".

Our tip: when you print a key to check it, show only a few characters, never the whole thing.

Step 4: A safety net

GitHub, a popular site for sharing code, has a tool that hunts for leaked keys. GitHub says: "Secret scanning scans your entire Git history on all branches of your repository for hardcoded credentials, including API keys, passwords, tokens, and other known secret types." (GitHub secret scanning) It also says that for public repositories, "Secret scanning runs automatically for free." (same page)

Our tip: a safety net is nice, but don't count on it. Keep keys out of code from the start.

Step 5: If a key leaks

Our tip, in this order: 1. Remove or disable the old key in the provider's console, if it offers a way. 2. Make a new key. 3. Put the new key in your .env file or Colab Secrets. 4. Check your usage page for charges you don't recognize.

Check yourself

  1. Where should a key live? (Answer: a .env file or Colab Secrets, never in the code)
  2. What does .gitignore do? (Answer: tells Git not to upload certain files, like .env)
  3. What's the first step if a key leaks? (Answer: remove or disable it, then make a new one)

Caution box Our tip: a leaked key can run up a bill. Remove it, then make a new one. Never paste a real key into a chat, a screenshot or a lesson exercise.

Builds on

Sources

Creator credits

Keep going

PreviousB1 →NextB3 →TrackBack to Build With AI →