Nothing — unless they also control your infrastructure. A shield token only works through ShieldKey's proxy, which enforces IP allowlists, rate limits, geo-restrictions, and time-based policies before any request reaches the destination. The proxy is a chokepoint you control, with rules the attacker can't bypass.
Security Model
A transparent walkthrough of what ShieldKey defends against, how each layer works, what you're trusting, and where the boundaries are. Read the model, verify the math, audit the code.
API keys have no access control
According to Salt Security's 2024 State of API Security Report, 95% of organizations experienced security problems in production APIs. This isn't about encryption or token swapping. A raw API key is a skeleton key. It has no concept of who's using it, from where, how often, or whether it should still be active.
When someone gets your Stripe key sk_live_..., they can use it from any IP address, any country, at any volume, at any time of day, and your only signal is the bill at the end of the month. The key has no opinions about who holds it. It simply works.
Nothing — unless they also control your infrastructure. A shield token only works through ShieldKey's proxy, which enforces IP allowlists, rate limits, geo-restrictions, and time-based policies before any request reaches the destination. The proxy is a chokepoint you control, with rules the attacker can't bypass.
| Capability | Raw API key | Shield token |
|---|---|---|
| IP restriction | None. Works from any IP. | Locked to your server CIDRs. |
| Rate limiting | Provider's global limits only. | Per-token sliding window. |
| Instant revocation | Log into provider, rotate, redeploy. | Reply "REVOKE" from your phone. Or one click. Real key untouched. |
| Audit trail | No visibility until the invoice. | Every request logged with IP, geo, timing. |
| Anomaly detection | None. | Alerts on volume, geo, error spikes. |
| Key rotation | Requires code changes everywhere. | Rotate at provider. Token unchanged. |
| Breach response | Hours of scrambling. | Kill token. Seconds. Done. |
| Offboarding | Rotate every key they ever saw. Redeploy everything. | Revoke their tokens. Real keys untouched. |
What happens when keys leak
FireTail's 2024 report found 1.6 billion records exposed via API vulnerabilities that year. GitGuardian's 2025 Secrets Sprawl Report counted 23.8 million new secrets leaked on public GitHub in 2024, most never revoked. Same breach, two outcomes.
sk_live_4eC39HqLyjWDarjtT1zdp7dc in the API keys table.sk_shield_7f3a9b2c1d8e5f6a in the API keys table..env files during the project.Registration + request flow
Why a proxy gateway, not just encryption
A common question: "If I swap my Stripe key for a shield token, and the attacker has the shield token and knows the proxy URL, aren't they in the same position?"
Yes -- if that's all ShieldKey did. If we only replaced one string with another, an attacker with the token and the proxy URL could call the proxy and the request would forward. That's why token indirection alone is not the security model.
The security comes from what the proxy enforces before it ever touches the encrypted key:
Every enforcement check happens before decryption. An attacker who fails the IP check never triggers decryption of your real key. The encrypted blob stays sealed.
Five layers, each independent
Salt Security found that only 14% of organizations have an API posture governance strategy. Traceable and Ponemon's 2025 report puts the number who can detect attacks at the API layer at just 21%. ShieldKey's security is not a single mechanism. It's a stack of five independent enforcement layers. An attacker would need to defeat all of them simultaneously, and the audit trail would still catch them.
IP allowlisting
Each shield token is locked to a set of CIDR ranges you define, typically your server IPs. The proxy checks the source IP of every request against this allowlist before doing anything else. An attacker calling from their own machine, a VPS, or any IP outside your ranges is rejected with a 403.
This is the most important layer. Without control of your infrastructure, the attacker cannot use the token at all. Even if they have the token, the proxy URL, and knowledge of the API, they're blocked at the network level.
Per-token rate limiting
Sliding-window rate limits per shield token. Even in a scenario where an attacker somehow makes requests from an allowed IP (e.g., they've compromised one of your servers), they immediately hit the rate ceiling. This limits the blast radius and buys you time.
Geo-restrictions
Restrict token usage to specific countries or regions. If your servers are in US-East and EU-West, block everything else. Attackers operating from other regions are rejected regardless of IP.
Token state + instant revocation
Shield tokens have explicit states: ACTIVE, PAUSED, REVOKED, EXPIRED. The moment you detect something wrong, you have three options: reply "REVOKE" directly from the anomaly alert email (works from your phone, watch, anywhere), click revoke in the dashboard, or call the API. The next request with that token is rejected. Your real API key at the provider is untouched, so your other integrations continue working.
Compare this to revoking a raw API key: you log into the provider, regenerate the key, then redeploy every service that uses it. That's hours. ShieldKey revocation is seconds — reply to an email and it's done.
Audit trail + anomaly detection
Every proxied request is logged: timestamp, source IP, geo, HTTP status, latency. No request bodies, no API keys. Just metadata. The system checks for anomalies every 5 minutes: unusual source IPs, request volume spikes (3x above your 7-day average), and error rate surges. Alerts fire automatically via email — and you can reply "REVOKE" directly from the alert to kill the token instantly.
IBM's 2024 Cost of a Data Breach Report puts the average breach lifecycle at 258 days to identify and contain. With a raw API key, you have no visibility until the provider's invoice arrives. With ShieldKey, you see suspicious requests within minutes and can kill access from your phone.
What we defend against -- and what we don't
Traceable and Ponemon found that 57% of organizations experienced an API breach in the past two years. IBM puts the average cost of a data breach at $4.88 million. Transparency about limitations builds more trust than overpromising. Here's where ShieldKey stands.
| Attack vector | Defense | Status |
|---|---|---|
| Database breach at your platform | Attacker finds shield tokens, not real keys. Tokens blocked by IP allowlist at the proxy. | Defended |
| Source code / .env leak | Code contains shield tokens + proxy URL. Tokens useless without allowed source IP. | Defended |
| Log file exposure | Only shield tokens appear in logs. Real keys never leave ShieldKey's proxy boundary. | Defended |
| Supply chain attack (malicious dependency) | Dependency exfiltrates tokens. Tokens unusable from attacker's infrastructure. | Defended |
| Insider with DB access | DB contains shield tokens + encrypted blobs. Tokens IP-restricted. Blobs require master key. | Defended |
| Employee / contractor departure | Departing person had shield tokens, not real keys. Revoke their tokens instantly. Real keys at all providers stay active. No rotations, no redeployments. | Defended |
| Disgruntled former employee | Saved shield tokens from their time at the company. Tokens are revoked on departure and IP-locked to company infra. Both checks block access. | Defended |
| Compromised server in your infra | Attacker has allowed IP but hits rate limits. Anomaly detection flags unusual patterns. Revoke token. | Partially defended |
| ShieldKey's proxy infrastructure compromised | Mitigated by: immutable deploys, process isolation, memory zeroing, no-write containers, open-source audit. | Mitigated, not eliminated |
| ShieldKey acts maliciously | Mitigated by: open-source proxy code, third-party audits, future self-hosted proxy option for Enterprise. | Mitigated, not eliminated |
| State-level adversary targeting ShieldKey | We cannot guarantee defense against state-level actors with physical access to infrastructure. | Not defended |
ShieldKey reduces your attack surface from "every system that touches an API key" to "ShieldKey's proxy infrastructure only." That's a significant reduction. But it's not zero. You are trusting our proxy. We mitigate this with open-source code, third-party audits, immutable infrastructure, and a future self-hosted option. We'll never claim otherwise.
The offboarding problem nobody solves
GitGuardian found 23.8 million secrets leaked on public GitHub in 2024, most from zombie leaks that were never revoked. Every security framework talks about access revocation when employees and contractors leave. Almost no company does it properly for API keys.
When a developer, contractor, or agency with API key access leaves your organization, those keys are compromised. They exist in shell histories, local .env files, CI/CD logs, Slack messages, password managers, and screenshots. To truly revoke access, you'd need to rotate every key they ever touched at every provider, then redeploy every service that uses those keys. This is so painful that most teams skip it entirely or do it partially -- leaving a window of exposure that can last months or indefinitely.
With ShieldKey, the departing person never had real API keys. They used shield tokens, and those tokens have three independent kill mechanisms:
Token revocation
Revoke their shield tokens the moment they leave — from the dashboard, the API, or by replying "REVOKE" to an alert email from your phone. The next request with that token returns 401. Their saved tokens are now dead strings. No provider-side rotation needed, no redeployment, no risk of missing one.
Token expiration
Set expiration dates that match contract end dates. When the engagement ends, tokens auto-expire without anyone needing to remember to revoke them. This is the safety net for the revocation you forgot to do.
IP enforcement
Even if revocation was delayed and the token hasn't expired, the IP allowlist blocks the former employee's requests. They're no longer on your network, so the proxy rejects them before decryption. This is defense that works even when your offboarding process fails.
With raw API keys, every person who leaves is a potential breach. With ShieldKey, every departure is a one-click cleanup that takes seconds, backed by automatic expiration and IP enforcement as safety nets. The real keys at your providers never change. Your production services keep running. Your other team members are unaffected.
This applies to full-time employees, part-time contractors, freelancers, development agencies, and any third party that touches your API integrations during their engagement.
What you're trusting when you use ShieldKey
You trust that ShieldKey's proxy infrastructure has not been compromised. We mitigate this with immutable container deployments (no runtime modifications), process isolation between proxy workers, automatic memory zeroing after each request, no SSH access to production, and automated dependency scanning.
You trust that ShieldKey does not log or exfiltrate decrypted keys. We mitigate this by open-sourcing the proxy code so you can verify the claim, and by commissioning third-party security audits. The proxy has no disk write capability in production. Decrypted keys exist only in volatile memory.
You trust that ShieldKey's master encryption key is secure. We mitigate this with HSM-backed key storage, split-knowledge key ceremonies, and key rotation procedures.
For organizations that need to eliminate even this trust, our Enterprise roadmap includes a self-hosted proxy agent. You run the proxy on your own infrastructure. ShieldKey's server stores only the encrypted blob. Your agent handles all decryption locally. This makes the system fully zero-knowledge. We never see your real keys at any point.
How real keys are stored
Even if an attacker bypassed all proxy enforcement and accessed our blob storage directly, they'd find only encrypted data. Each real key is encrypted individually with a unique salt and IV.
The version byte is forward-looking. If a cryptographic weakness is discovered in AES-256-GCM (unlikely but possible), we can migrate to a new algorithm and re-encrypt all blobs without users needing to re-register keys.
How ShieldKey compares to other approaches
Salt Security's 2024 report found API usage grew 167% in the past year, but only 7.5% of organizations have dedicated API testing or threat modeling. APIs are proliferating faster than anyone is securing them.
Environment variables / .env files -- Your key is plaintext in a file. Any process on the machine can read it. Any developer with SSH access has it. Any log that accidentally prints env vars exposes it. No access control whatsoever.
Secrets managers (Vault, AWS Secrets Manager, etc.) -- Better. Keys are encrypted at rest and access-controlled. But the application still receives the plaintext key at runtime and uses it directly. A compromised application process has the real key in memory for its entire lifecycle. ShieldKey's advantage: the real key exists in memory for one HTTP request, then is zeroed.
Provider-level IP restrictions -- Some providers (Stripe, Google) offer IP restriction natively. If your provider supports it, use it in addition to ShieldKey. But most API providers don't, and none offer per-key rate limiting, audit trails, instant revocation decoupled from key rotation, or anomaly detection. ShieldKey gives you a uniform enforcement layer across all providers.
API gateways (Kong, Apigee, etc.) -- API gateways manage your inbound API. ShieldKey manages your outbound API keys. They solve different problems and can work together.