Production Checklist

Complete this checklist before going live. Each item reduces a specific class of production failure.

Authentication

Use separate API keys per environment — create distinct integrations for development, staging, and production. A leaked dev key cannot affect production.
Store API keys in environment variables or a secrets manager — never hardcode them in source files or commit them to version control.
Confirm member_external_id mode is disabled — the ALLOW_UNVERIFIED_MEMBER_SESSION_MINTING environment variable must not be true in production.
Assertion JWT TTL is ≤ 60 seconds — the exp claim in your member_assertion should be now + 60 at most. Longer TTLs widen the window for replay attacks.
Private key is server-side only — the EC/RSA private key used to sign member_assertion JWTs must never be sent to a browser, mobile client, or logged to disk.
Assertion keys have meaningful kid values — use names like prod-v1, prod-v2 so you can rotate without ambiguity.

Enable only the tools your application uses — minimize the attack surface. The model can only call tools that are enabled; don't leave test or debug tools active in production.
Set require_member: true on user-scoped tools — any tool that serves per-user data should require a member session, not accept a plain API key.
Use hmac_signature for custom tools in production — static_bearer provides no request integrity. HMAC is strongly recommended for any production API.
Verify your custom tool endpoints implement signature verification — never accept requests to tool endpoints without validating X-Tengine-Signature. Any unverified endpoint can be called by anyone who knows the URL.
Verify timestamp drift check is implemented — reject requests where X-Tengine-Timestamp is more than 5 minutes old to prevent replay attacks.
Custom tool base_url uses HTTPS — http:// is blocked in production. Ensure your API has a valid TLS certificate.

Token caching is implemented — session tokens are 15-minute TTL. Re-minting on every request adds unnecessary latency and backend load. Use the caching pattern from the User-Scoped Quick Start.
Token refresh buffer is set — refresh tokens before they expire, not after. A 60-second buffer is recommended.
Member IDs are stable and unique — the sub claim in your member_assertion should be a permanent user identifier (e.g., database UUID), not an email address or username (which can change).

Rotate any credential that was ever logged or exposed — if an API key, assertion private key, or HMAC secret appeared in logs, error messages, or was committed to git, treat it as compromised and rotate immediately.
Custom tool endpoints validate X-Tengine-Project-Id — confirm the request is coming from your expected project, not an unrelated TengineAI project.

Monitor tool call failures — set up alerting on 5xx responses from your custom tool endpoints. Silent failures mean the model receives error messages instead of data.
Test the full flow in staging before go-live — run the model against your staging project with a staging API key. Confirm tool calls execute end-to-end.
Have a key rotation runbook — document the steps to rotate API keys and assertion keys for your team. A security incident is not the time to figure out the process.
Review enabled tools periodically — as your application evolves, disable tools that are no longer needed.

Item	Risk if skipped
Separate keys per environment	Dev key leak affects production
`require_member` on user-scoped tools	One user can invoke tools as another
HMAC signature verification on tool endpoints	Anyone can call your API directly
Timestamp drift check	Valid signatures can be replayed
Token caching	Unnecessary latency and backend load at scale
Stable member IDs	Per-user attribution breaks if IDs change