How Gatewayz keeps your API keys and data secure

Gatewayz keeps API keys secure by checking each key on every request against its status, expiration date and request cap, by recording security events in an audit log, and by giving you controls to shut a key off. On ordinary API calls it stores billing metadata only, not prompt or completion content.

Why does an API key need protecting at all?

An API key is a bearer credential: whoever holds it can spend the balance behind it. There is no second factor on an API call, so a leaked key works for an attacker exactly as it works for you.

That makes two things matter. The first is how the service that issued the key stores and checks it, which is Gatewayz's job. The second is where the key travels after you copy it, which is yours. If you are new to how keys, endpoints and requests fit together, APIs, endpoints and keys covers the basics first.

How does Gatewayz protect API keys?

Gatewayz enforces per-key limits on every request, gives you controls to shut a key off, and records security events so incidents can be reconstructed. Each layer handles a different failure.

Limits checked on every request

Before a request is served, the key is checked in order: is it active, has it passed its expiration date, and has it used up its request cap. A request is authorized by the key in its Authorization: Bearer header, the scheme described in RFC 6750, so the key itself is the thing being checked. A key with a max_requests value that has been reached is refused with a 402 response and the code request_cap_exhausted. That status is terminal, so a well-behaved client stops instead of retrying. Spend ceilings for unattended agents goes deeper on why caps belong on the key rather than in your code.

Controls to shut a key off

Audit log

Security events are written to an audit log: key creation, key deletion, rejected keys and limit violations. Privileged administrative actions are recorded in a separate audit trail. An audit log does not prevent an incident, but it lets someone reconstruct what happened and when.

What data does Gatewayz store about my requests?

On ordinary API calls, Gatewayz stores billing and operational metadata, not the content of your prompts or the model's responses. It has to know who used how much in order to bill, but it does not need the text.

The per-request record holds a request id, the model, input and output token counts, processing time, status, and optionally the user and key ids. When a request fails, the stored error message is sanitized and never echoes your input. The error tracking tool Gatewayz uses receives no request or response bodies.

The reason for the 400-day window on usage records is practical. Billing disputes and chargebacks can surface long after a charge, and a record that has already been deleted cannot settle one.

What can Gatewayz not protect?

Gatewayz cannot hide your prompt from the provider that runs the model, and a few features you choose to use do expose or store content. These limits are worth knowing before you send anything sensitive.

The provider sees the prompt

A model cannot answer a prompt it cannot read. When you call anthropic/claude-sonnet-4-6 or openai/gpt-5, the prompt and model parameters are sent to that provider, from Gatewayz rather than from your machine. If your client sets the OpenAI user field, Gatewayz strips it before forwarding. That removes one identifier. It does not remove anything you put inside the message text itself, and the provider's own data policy applies to what it receives. If a prompt must not reach a third party, it should not be sent to a hosted model through any gateway.

Chat history is opt-in and stored

The Gatewayz chat app has a chat history feature. It is explicit and opt-in, and when you use it your conversations are stored and linked to your account, because that is the feature. The API does not use it.

Community routing exposes content to a node

Gatewayz runs a community GPU network in beta. Requests only go there if you explicitly ask, using a model id with the community/ prefix. The node that runs such a request sees the prompt and response content, though not your identity. A small sampled share of those requests is held briefly, for minutes, so the work can be checked by replaying it. If that tradeoff does not fit your data, do not use community/ ids.

Gatewayz knows you are a user

Anonymity from Gatewayz itself is not on offer. To bill you, it links your account to usage counts. What it avoids is linking your account to the content of what you asked.

What is my side of the shared responsibility?

Gatewayz protects the key once stored. You control everything that happens to the key before it reaches the Authorization header. The usual ways a key escapes are all on that side: a key pasted into a repository, a frontend bundle, a log line, a screenshot or a shared chat.

Checklist

1. One key per agent or environment. Separate keys for production, staging, each agent and each teammate. A leak then affects one key, and the audit trail tells you which workload it was.
2. Set a request cap on every key. A cap turns a leaked or looping key from an open-ended bill into a bounded one.
3. Keep keys server-side. Never ship a key in browser JavaScript, a mobile app or a desktop binary. Anything that runs on a user's device can be read by that user. Put a small server in between.
4. Load keys from environment variables or a secret manager. Do not hardcode them. The OWASP Secrets Management Cheat Sheet covers centralizing, rotating and auditing secrets.
5. Never commit a key. Add .env files to .gitignore, and turn on GitHub secret scanning or an equivalent pre-commit check. Removing a key in a later commit does not remove it from history.
6. Use expiration dates for temporary access. A demo key that expires on its own cannot be forgotten.
7. Replace keys on a schedule and on any doubt. Creating a new key and deleting the old one is cheap. Waiting to be sure a key leaked is not.

What to do if a key leaks

1. Delete or deactivate the key immediately. Do this before investigating, since the key keeps working while you look.
2. Deploy the new key to the one workload that used the old one. With one key per workload, nothing else breaks.
3. Review your usage for the period the key was exposed, looking for models, volumes or times you do not recognize.
4. Find and remove the leak's source: the commit, the log line, the client bundle. If it was pushed to a public repository, assume it was copied.
5. Add a guard so it cannot recur, such as a secret scanning rule or a pre-commit hook.

For the formal statement of Gatewayz's security practices, see the security page.

Frequently asked questions

Does Gatewayz store my prompts?

Not on ordinary API calls. The request record holds the model, token counts, status, timing and ids, not the text you sent or the text the model returned. The exceptions are the opt-in chat history feature in the chat app, which stores conversations because that is its purpose, and requests you explicitly route to the community GPU network with a community/ model id, where the node running them sees the content and a small sample is held for minutes for verification.

Can I stop a key without deleting it?

Yes. A key can be deactivated and later reactivated, and it can carry an expiration date after which it stops working on its own. Deactivating is useful when you suspect an agent is misbehaving and want to investigate before deciding; deleting is the right response once you know a key has leaked.

Does the model provider know who I am?

Requests reach the provider from Gatewayz, and a client-set OpenAI user field is stripped before forwarding. The provider still receives the full prompt and parameters, so anything identifying that you write into the message itself reaches them. Their own data policy governs what they do with it.

What happens when a key hits its request cap?

The next request is refused with HTTP 402 and the code request_cap_exhausted. It is a terminal response, not a temporary one, so retrying does not help until the cap is raised or a different key is used. Rate limiting is separate and returns 429, which is retryable after a pause.

How long does Gatewayz keep usage data?

Per-request records are kept for 90 days and then rolled up into daily aggregates. Usage records and the activity log are kept for 400 days by default so billing disputes can be resolved. The credit transaction ledger is the financial record and is not pruned.

Is it safe to put my Gatewayz key in a frontend app?

No. Any key shipped to a browser or a mobile device can be extracted by the person using it, and then used from anywhere. Keep the key on a server you control and have your frontend call that server, which can add its own authentication and limits.

Related

• APIs, endpoints and keys. What a key is and how a request uses it.
• Spend ceilings for unattended agents. Why caps belong on the key.
• Who reads the error?. Why a spent cap returns a terminal status.
• Your first Gatewayz API request. Put a key to work safely from an environment variable.
• What is an AI agent?. Why agents raise the stakes on key hygiene.