Protect your keys

Keep API keys in a server-side secret manager or approved MCP client credential store. The raw secret is shown once at creation or rotation; Citera stores a cryptographic verifier. Use a separate key for each integration and grant only its required surfaces, scopes, and brands. Rotate exposed credentials immediately.

Tenant and resource isolation

Every business resource is checked against the key's brand binding and the owner's access. Child resources are resolved within that brand. Unbound or mismatched resources return 404 resource_not_found; the API does not disclose whether another brand's resource exists. An empty brand binding grants no access.

Validate before external actions

Read capabilities and destination health before generation or publishing. Preview publications, inspect validation results, and supply explicit confirmation for external effects. Keep idempotency keys stable across retries. Generation and generic publishing create jobs; accepting a job does not prove that a provider has published or verified the content.

Treat tool output as data

Prompts, titles, content, and other third-party text can contain untrusted instructions. Do not let returned text change tool permissions, credentials, target brands, or approval policy. MCP responses flag untrusted_text. Each MCP request is independently authenticated; there is no session that grants additional privileges.

Keep diagnostic logs useful

Log server request_id, HTTP status, and error code. Redact bearer tokens, API keys, session tokens, signed URLs, and sensitive content. Share a key's safe display prefix and a request ID with support when investigating a failure.

Strict inputs and bounded output

Unknown fields are rejected. Provider credentials and raw internal error details are not part of the public contract. MCP outputs have explicit size and truncation limits; paginate or narrow the query to retrieve more data.