Admin sessions
Signed, HTTP-only, same-site session cookies authenticate the management surface. The management API revalidates the user and organization role before protected operations.
Security
Protect the provider key. Constrain everything that can use it.
Gatekyper handles high-value credentials and sits in the request path for paid APIs. Its security model starts with explicit trust boundaries, least privilege, safe failure, and auditable control—not security theater.
Trust boundaries
No credential is accepted everywhere.
The browser, management API, request gateway, MCP server, worker, database, cache, and upstream providers have distinct responsibilities and credentials.
Gate Tokens
Gate Tokens authenticate gateway calls only. They do not grant dashboard administration and are useless when presented directly to an upstream provider.
MCP sessions
MCP clients map to known actors and permission levels. Agents can read their own state and request access without receiving provider credentials.
Provider credentials
Upstream secrets are accepted by the Provider Vault and unlocked by the gateway only after a request passes identity, route, and policy checks.
Provider Vault
Plaintext has a short life.
The Provider Vault is designed so a normal read path returns identification metadata, not the reusable secret.
Accept once
An administrator submits a provider credential through the authenticated management surface. It is never returned by a read API.Encrypt with context
Provider credentials are encrypted with AES-256-GCM and a random nonce. Authenticated context binds ciphertext to its organization, credential, provider, and key version.Keep the root key separate
The master encryption key is supplied outside the database. A database copy alone is not sufficient to decrypt provider credentials.Decrypt only for use
The gateway decrypts the active credential in runtime memory after token and policy checks, then injects provider-native authentication.Rotate with an audit trail
A candidate credential can be tested and activated while the previous version retires. Existing Gate Tokens remain stable.
Gate Tokens
Display once. Store hash-only. Revoke independently.
A Gate Token has a public lookup identifier and a high-entropy secret. Only the lookup identifier and a peppered HMAC of the secret are retained.
High entropy
Each secret is generated from cryptographically secure random bytes and belongs to a named token kind and owner.
Constant-time verification
The gateway looks up the public identifier, recomputes the keyed HMAC, and compares the result in constant time.
Limited blast radius
Expiration, scope, budget, rate, environment, and revocation controls limit what a leaked Gate Token can do.
Runtime enforcement
Policy decisions fail closed.
Unknown, missing, expired, revoked, or out-of-policy requests stop before the upstream provider call.
Deny by default
A token without a valid attached policy cannot proxy traffic. Unknown provider routes and arbitrary target URLs are not forwarded.
Safe dependency failure
Token, policy, hard-budget, credential-decryption, and kill-switch errors deny the operation when the boundary cannot be evaluated.
Explicit production scope
Production access must be granted deliberately. Development or temporary identities do not inherit it by implication.
Reservation before spend
A hard-stop budget reserves a conservative estimate before forwarding, preventing concurrent requests from all passing one stale check.
Settlement after response
Observed usage settles the reservation. When provider cost arrives late or usage is incomplete, the result remains an estimate rather than a false exact number.
Separate denial ledger
Blocked requests write denial events and do not masquerade as provider usage. Requests that reach a provider write usage events.
Privacy
Metadata is the default record.
Gatekyper needs enough information to enforce and explain access. It does not need to retain application content to do that.
Recorded by default
Request identifier, token and actor identifiers, provider, capability, model, endpoint, policy decision, status, latency, and estimated usage or cost.
Not stored by default
Authorization headers, provider keys, Gate Token plaintext, cookies, prompts, responses, file contents, and raw application payloads.
Threat model summary
Known risks have named controls.
The model focuses on realistic failure paths around secrets, machine identities, policy, and the network boundary.
Provider-key leakage
Authenticated encryption, redacted display, no read-back, runtime-only decryption, and sensitive-header stripping.
Gate Token leakage
Hash-only storage, expiration, tight scopes, budgets, rates, usage visibility, and independent revocation.
Runaway agent spend
Conservative budget reservation, per-request estimates, rate controls, expiry, denials, and kill switches.
Agent self-escalation
Request-only MCP defaults, bounded auto-approval templates, human review, and audit events.
Gateway bypass or SSRF
Allowlisted adapters and known routes; no arbitrary URL proxy in the current product.
Audit tampering
Append-only application APIs and no dashboard update/delete surface; stronger external integrity controls remain future work.
Operator responsibility
The host is part of the security boundary.
Self-hosting keeps the control plane within infrastructure you operate, but it does not remove operational responsibility.
Protect application secrets, database and cache access, backups, transport security, the reverse proxy, and the machine running the services. Keep the master encryption key separate from database backups.
Restrict exposed interfaces, review audit and denial activity, use narrow provider credentials as defense in depth, and test rotation and recovery procedures before an incident.
Gatekyper does not claim a certification, external audit, perfect spend precision, or immunity from compromise. Review the source and deploy it according to your own risk requirements.
Private disclosure
Report security issues privately.
Email security@gatekyper.dev with the affected version, impact, reproduction details, and a safe way to follow up. Do not publish an exploitable issue before a fix can be coordinated.
Real keys in. Scoped tokens out.
Trust the boundary you can verify.
Read the architecture and gateway documentation, inspect the source, and begin with a local deployment and a tightly scoped test identity.