Locking Down a Gemini API Key on Servers Whose IP Keeps Changing — Restrictions for Headless Automation

Option A: satisfy the floor with an API restriction only

The lowest-friction stopgap is to leave the application restriction empty and add only an API restriction — narrow the key down to the Generative Language API alone. That by itself stops a leaked key from being pivoted onto other Google APIs, and it puts you on the "restricted" side of the unrestricted-key block.

# Narrow a key's API restriction to Generative Language API only
from google.cloud import api_keys_v2
from google.cloud.api_keys_v2 import Key, Restrictions, ApiTarget
 
def restrict_to_gemini(project_id: str, key_id: str) -> None:
    client = api_keys_v2.ApiKeysClient()
    name = f"projects/{project_id}/locations/global/keys/{key_id}"
 
    key = Key(
        name=name,
        restrictions=Restrictions(
            api_targets=[ApiTarget(service="generativelanguage.googleapis.com")]
        ),
    )
    # update_mask swaps only restrictions; other fields are preserved
    op = client.update_key(key=key, update_mask="restrictions")
    op.result()  # wait for it to apply
    print("Restricted the key to generativelanguage.googleapis.com")
 
restrict_to_gemini("your-project-id", "your-key-id")

But this is only the floor. A key with an API restriction alone, if stolen, can still call Gemini from anyone's environment. As an indie developer who eats the bill personally, stopping here honestly makes me nervous. You'll want to constrain the origin one step further.

Option B: funnel egress through a fixed IP so IP restriction works

Even headless jobs can make an IP restriction work if you pin the exit IP to one place. The execution environment's own IP still changes, but you put a relay with a fixed IP in front of it — a NAT gateway, or a fixed-IP forwarding proxy — and route every Gemini request through it.

# Call Gemini through a fixed-IP forwarding proxy
# The runner's IP changes each run, but the key only allows the proxy's fixed IP
import os
from google import genai
 
# Set HTTPS_PROXY and the httpx under the SDK routes through it
os.environ["HTTPS_PROXY"] = "http://PROXY_HOST:PROXY_PORT"
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
resp = client.models.generate_content(
    model="gemini-flash-latest",
    contents="This request arrives via a fixed-IP proxy.",
)
print(resp.text)
# On the key, register only the proxy's fixed IP under server_key_restrictions.allowed_ips

The upside is that you constrain the origin without changing the key mechanism. The downside is that the relay itself becomes something you operate. A NAT gateway accrues hourly charges; a self-run proxy is an availability problem you now own. For low-volume personal automation, whether that relay's cost and upkeep is worth what you're protecting is genuinely marginal. I ran this for a while, then moved on to the next option because the upkeep wore me down.

Option C: drop the API key on servers and move to service-account auth

If you're settling in, I think this is the real answer. API keys aren't a good fit for headless server work in the first place. An API key is a shared secret — whoever holds it can use it — with weak tools for constraining the origin. Server-to-server calls are better served by OAuth 2.0 (service account) auth, which mints short-lived tokens per call.

Called through Vertex AI, Gemini authenticates with service-account credentials instead of an API key. With the same google-genai SDK, flipping to vertexai=True lets most of your call code stay as it is.

# Call Gemini with service-account auth instead of an API key (via Vertex AI)
# Point GOOGLE_APPLICATION_CREDENTIALS at the service-account key JSON path
from google import genai
 
client = genai.Client(
    vertexai=True,
    project="your-project-id",
    location="global",
)
 
resp = client.models.generate_content(
    model="gemini-flash-latest",
    contents="This request arrived via service-account auth. No more API key.",
)
print(resp.text)
# Auth runs through Application Default Credentials.
# Use the service account bound to the runtime and you don't even ship a key file

Now constraining the origin moves to "which service account gets which IAM role." You manage authority on a stable axis — identity — instead of the unstable one of IP. If shipping key files bothers you, use the service account attached to the runtime and let Application Default Credentials handle it, so you never carry the credential around. For me, the unrestricted-key block became the nudge to move server work into this shape.

How to decide how far to go

How far you go depends on the nature of the work and who eats the bill. My own call is roughly the table below.

For a one-off check with a throwaway key, A is plenty. But if you run many scheduled jobs daily — as we do at Dolice Labs — paying the up-front migration cost to land on C makes every later audit easier. Frame B as the middle ground for when you can't rewrite key-dependent code right away.

Pitfalls while switching over

Moving to Vertex has a few quiet snags.

• The model name string is the same, but availability can differ subtly. Right after switching, do one live call with the model you actually use and confirm you don't get 404 or NOT_FOUND. What an alias like gemini-flash-latest points to shifts over time.
• Get location wrong and you'll miss in that region. If you use the global endpoint, state location="global" explicitly.
• If the service account lacks the needed role, you get 403 PERMISSION_DENIED — which looks exactly like the unrestricted-key-block 403, so don't misattribute the cause. On Vertex you need something like the Vertex AI User role.
• Pass both an API key and a service account and the SDK gets lost over which to prefer. During migration, keep only one env var in play — decide "don't leave GEMINI_API_KEY set while turning on vertexai=True" and isolation gets easy.

A single connectivity check at the moment of the switch prevents most of these. I make it a rule, every migration, to run exactly one call from the same environment before enabling the production schedule.

Your next move

Run the Option A inventory code first and just check whether any app=none, api=ALL-APIs key is hiding among your headless jobs. If even one server-side key is sitting there, that's your next candidate to silently fail. Decide between getting by with A and moving to C after you've seen the inventory, and you'll get the order right.

If you run automation the same way, I hope this gives you a place to start your own audit.