Security

Defense in depth for tenant automation

The platform applies default-deny API access, strict tenant boundaries, and operational controls suitable for regulated HR and finance workloads.

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 isolation

Every authenticated request resolves to a single tenant context. Cross-tenant reads and writes are blocked at authorization and data access layers. Automation keys are bound to the company that issued them and cannot be reused across tenants.

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

Automation and interactive endpoints are rate limited per identity and tenant. Burst traffic may receive HTTP 429 responses. Implement exponential backoff and idempotent retries for safe operations.

Audit logging

Security-relevant actions—including API key lifecycle, integration connection changes, and privileged configuration—are recorded in tamper-evident audit trails scoped to the tenant. Review logs through your administrator workflows.

Outbound webhooks and SSRF protection

When the platform delivers webhooks or alerting callbacks to customer-controlled URLs, outbound requests pass SSRF controls: blocked private and link-local targets, restricted redirect behavior, and validation of destination hosts. Configure only HTTPS endpoints you operate.

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.