Security

Security controls for tenant automation

API access is denied by default and checked against tenant, role, scope, and module entitlement. Deployment and regulatory requirements must be validated separately.

Default-deny automation surfaces

Tenant automation keys (mjt_) are honored only on routes registered in the automation allowlist. A valid key with broad UI permissions cannot call undocumented or non-automation endpoints. Use GET /api/v1/automation/capabilities to inspect permitted paths for your key.

Tenant scoping

Application requests resolve to a tenant context, and automation keys are tied to the company that issued them. Review database, infrastructure, and operational isolation controls for the deployment before relying on them.

Transport security

All API traffic must use TLS 1.2 or newer. Do not send bearer tokens or session cookies over plain HTTP, including in development tunnels without TLS termination.

CSRF for browser sessions

Interactive sessions rely on same-site cookie policies and CSRF double-submit for state-changing requests. Do not disable CSRF checks or expose session cookies to third-party origins.

Rate limiting

Clients must be prepared for HTTP 429 responses. Use exponential backoff and idempotent retries for safe operations, and confirm the limits configured for your deployment.

Audit logging

Security-relevant actions, including API-key and integration changes, are written to tenant-scoped audit logs. Confirm retention, integrity controls, and review procedures for your deployment.

Outbound webhooks and SSRF protection

Configure only HTTPS endpoints you operate. Before relying on outbound delivery in production, confirm how the deployed release validates destination hosts, redirects, and private or link-local addresses.

See the Webhooks page for event delivery semantics and verification expectations.

Secret handling

Store mjt_ secrets in a vault; never commit them to source control.
Do not paste keys into chat, tickets, or email.
Do not embed automation keys in front-end code or mobile binaries.
Rotate after exposure suspicion; revoke unused keys promptly.

Platform keys (mjs_) are for operator infrastructure only. Customers should not request or distribute them for tenant integrations.

Authorization layers

Authentication proves who is calling; authorization decides what they may do. Checks include user role, module entitlement, tenant API key scope, and whether the route is on the automation allowlist. All layers must pass.

Reporting issues

If you discover a suspected vulnerability affecting your tenant deployment, contact your platform administrator through your established support channel. Do not perform destructive testing against production tenants without written approval.