Threat Model
Last updated: April 2026. This is a living document.
Most security products say "secure" and stop there. We think you deserve to know exactly what we protect against, what we don't, and the reasoning behind our architecture decisions. If you find a gap, tell us.
Architecture: Capability-Based, Not Subtraction-Based
Traditional approaches give an agent full credentials and then try to limit what it can do — subtracting permissions after the fact. API Stronghold inverts this: secrets never enter the agent's execution context. The credential lives at the proxy boundary, injected only at the moment of the upstream API call.
This is the phantom token pattern: the agent holds a short-lived session token that can only be used through the AS proxy. Even if the agent is fully compromised, the attacker gets a token that expires in minutes, is scoped to specific providers, and is logged on every use. They never get the real API key.
Threat Actors
1. Compromised Agent Session
An attacker gains control of a running AI agent — via prompt injection, compromised dependencies, or a vulnerability in the agent framework.
- Agent never holds real credentials — only a proxy session token
- Session token expires in minutes (configurable TTL)
- Token is scoped to specific providers and key IDs
- Every proxied call is logged with HMAC-signed audit trail
- Emergency lockout kills all sessions in one API call
- Attacker can use the proxy session until it expires
- Actions within the allowed scope are indistinguishable from legitimate use
- Data read via the proxied API (e.g., customer records) is not filtered
2. Supply Chain Attack on Agent Code
A compromised dependency or GitHub Action tag injects malicious code that tries to exfiltrate credentials from the CI/CD pipeline or agent runtime.
- No real API keys in environment variables — only proxy tokens or fake keys
- GitHub Action v2 creates ephemeral sessions that auto-revoke at job end
- Exfiltrated session token expires in minutes
- Client-side decryption means the server never sees plaintext keys
- If the malicious code runs in the same process as the proxy, it can make proxied API calls
- The bootstrap secret (used to create sessions) is still a static credential in CI/CD
3. Prompt Injection
An attacker manipulates an AI agent's input to make it perform unintended actions using the credentials it has access to.
- Scope limits the blast radius — agent can only access what it was granted
- Blast radius report shows exactly what an agent could reach if compromised
- Short TTL limits the time window for exploitation
- Audit trail captures the full sequence of actions for forensics
- AS cannot prevent the agent from making authorized calls — scope is enforced, intent is not
- Actions within the allowed scope (e.g., sending emails, making payments) can be triggered by injection
- AS is not an input validation or prompt filtering layer
4. Insider Threat (Malicious Team Member)
A team member with legitimate access abuses their permissions to exfiltrate or misuse credentials.
- Group-based access control limits which keys each user/agent can see
- All decryption events are audit logged (who viewed what, when, from where)
- Emergency lockout can revoke all access for a user or the entire org instantly
- Secret encryption keys are per-client — one team can't decrypt another's vault
- A user who can decrypt a key can copy it — AS logs this but can't prevent it
- An admin can access all keys in their organization by design
- Social engineering of an admin account is outside AS's scope
5. Database Compromise
An attacker gains read access to the API Stronghold database.
- All API keys are encrypted client-side with AES-256-GCM before reaching the server
- The server never has access to decrypted keys (zero-knowledge architecture)
- Auth tokens are stored as SHA-256 hashes, not plaintext
- Master key is encrypted with the user's password — not stored on the server
- Metadata (key names, providers, user emails, org names) is not encrypted
- Active proxy session tokens can be extracted if plaintext column exists
- Encrypted blobs could be targeted for offline brute-force if the master password is weak
Architecture Decisions and Why
Proxy boundary, not in-context injection
The real credential is injected by the proxy at request time, never placed in the agent's environment. This means a compromised agent can only use credentials through the proxy (which logs, rate-limits, and scope-checks every call), never exfiltrate the raw key material.
Phantom token TTL (default 1 hour, max 24 hours)
Session tokens are short-lived by design. The default TTL is 1 hour, and the maximum is 24 hours. Shorter TTL = smaller blast radius if a token is stolen. Sub-tokens can narrow the scope and TTL further without restarting the session.
Client-side encryption (zero-knowledge)
API keys are encrypted in your browser using your master password before being sent to the server. The server stores only encrypted blobs — it can never read your keys. This means even a complete server breach does not expose your credentials.
Hash-based token authentication
All authentication tokens (service keys, MCP tokens, API user tokens, proxy sessions) are stored as SHA-256 hashes. Authentication compares hashes, never plaintext. This provides timing-attack resistance and limits exposure on database compromise.
Scope enforcement at call time, not provisioning time
MCP server scopes are frozen into each token at issuance. When a token is used, the frozen scope (not the server's current scope) is enforced. This prevents scope escalation attacks where an admin might accidentally broaden a server's permissions after tokens are already in use.
Emergency lockout (kill switch)
One API call revokes all credentials for an agent, a user, or an entire organization. Works even if the subscription is canceled or expired. The lockout is persistent — locked-out users cannot re-authenticate until an admin explicitly unlocks them. This is the incident response tool that most vault products don't have.
What We Explicitly Don't Do
Honest limitations. We'd rather tell you what's out of scope than have you discover it during an incident.
- We don't prevent authorized actions. If an agent has permission to call the Stripe API and a prompt injection attack triggers a payment, AS can't distinguish that from a legitimate call. Scope limiting reduces the blast radius, but doesn't replace application-level authorization logic.
- We don't filter data in transit. The proxy injects credentials and forwards requests. It does not inspect, filter, or redact the data returned by upstream APIs. If an agent reads PII from a database via an authorized API call, AS logs the call but doesn't prevent the data access.
- We don't protect against weak master passwords. If a user sets "password123" as their vault password, the encryption is only as strong as that password. We enforce minimum password requirements, but we can't prevent a determined user from choosing a guessable password.
- We don't protect against a fully compromised model. If the underlying LLM is replaced with a malicious model (e.g., via a model supply chain attack), that model can make whatever API calls the agent's scope allows. AS limits the scope, but can't validate the model's intent.
- We don't protect against overly broad scope configuration. If an admin gives an agent access to all providers with a 24-hour TTL, AS faithfully enforces that scope. The blast radius report exists specifically to flag these over-permissioned configurations before an incident happens.
Cryptographic Primitives
| Purpose | Algorithm | Parameters |
|---|---|---|
| Vault encryption | AES-256-GCM | 12-byte random nonce, AAD bound to client/user |
| Key derivation (master password) | PBKDF2-SHA256 | 310,000 iterations, 16-byte random salt |
| Token hashing | SHA-256 | All auth tokens stored as hashes, never plaintext |
| API user key derivation | HMAC-SHA256 | Domain-separated: "api-stronghold-auth" / "api-stronghold-decrypt" |
| Session tokens | 256-bit random | crypto.getRandomValues / crypto/rand |
| Proxy usage signing | HMAC-SHA256 | Per-call signature with request ID + timestamp |
| Recovery phrase | BIP-39 mnemonic | 24 words, NFKD normalized, separate AAD path |
Reporting a Vulnerability
If you find a security vulnerability in API Stronghold, please report it to support@apistronghold.com. We aim to respond within 24 hours and will credit you in our changelog unless you prefer to remain anonymous.
We do not operate a bug bounty program at this time, but we are genuinely grateful for responsible disclosure and will acknowledge your contribution publicly.