Encrypted in transit.
Traffic to the platform is served over HTTPS, and connections to our databases and file storage require TLS 1.2 or higher.
Trust · Security practices
Your data, protected at every layer.
Security runs through every layer of Inscendo: how your data is stored, how accounts sign in, how the attack surface is hardened, how our code ships, and how production runs. Here is the concrete picture, layer by layer.
Tenant isolation
Your data lives in its own database, not a shared table.
Most multi-tenant products pool every customer into one shared database and rely on application code to keep the rows apart. We don’t. Every customer gets its own dedicated, physically separate database and file storage, with integration credentials held in a tenant-scoped secrets vault. There is no shared table of customer records for a stray query to reach across.
Every request is bound to your tenant from a validated membership check before any data is touched, including every action Inscendo IQ takes on your behalf, whose tool calls are pinned to the acting tenant. Automated architecture tests enforce these isolation boundaries on every change before it can ship. The architecture page walks through the model in full.
Data protection
Your data, encrypted and recoverable.
Encrypted at rest.
Databases use Transparent Data Encryption and file storage is encrypted with AES-256, managed by Microsoft Azure.
Secrets in isolated vaults.
Application secrets and each tenant’s integration credentials are held in managed, access-controlled vaults (Azure Key Vault), separated by scope. Inscendo IQ uses your credentials; we never log them.
Point-in-time backups.
Every database can be restored to any moment within a 35-day window, with longer-term backup retention on top.
Accounts & access
Getting in is hard for everyone but you.
Multi-factor authentication required.
Every account signs in with a required second factor, either an authenticator app (TOTP, RFC 6238) or a one-time code by email, backed by single-use recovery codes and an optional per-device trust that stores only a hashed token, revocable per device.
Argon2id password hashing.
Passwords are hashed with Argon2id at OWASP-recommended parameters (64 MiB memory, 3 iterations) and verified in constant time. We never store or log a plaintext password.
Escalating account lockout.
Repeated failed sign-ins trigger escalating, time-bounded lockouts, and the same limit covers failed second-factor attempts.
No account enumeration.
Sign-in timing is equalized against a decoy hash, so response times can’t reveal which email addresses have accounts.
Bounded sessions.
Sessions use signed tokens with an idle timeout and a hard 30-day cap. Account status and role are re-derived and re-validated on every renewal, so access changes take effect continuously.
Safe password recovery.
Password-reset links are single-use, hashed, and time-limited, and completing a reset revokes every trusted device on the account.
Attack-surface hardening
The common attacks, closed off by default.
SQL-injection resistant.
Database access uses parameterized queries only, and a dedicated test battery fires classic payloads (DROP, UNION, stacked statements, xp_cmdshell) at the query layer to confirm they are rejected.
SSRF protection.
Outbound requests Inscendo IQ makes on your behalf are screened against a private-network denylist, validated against the real connection IP so DNS-rebinding can’t slip through.
Rate limiting.
Sensitive endpoints, including sign-in, email send, and automation and webhook invocation, are rate-limited to blunt abuse and brute-force attempts.
Clickjacking defense.
A Content-Security-Policy controls which sites are allowed to frame the application, configured per environment.
Constant-time secret checks.
Tokens, signatures, and secrets are compared in constant time, enforced across the codebase, so timing can’t leak them.
Strict token validation.
Session tokens are validated for issuer, audience, signature, and expiry on every request, and the service refuses to start with a default or unresolved signing key.
Secure by construction, not by promise.
Most of the controls on this page are backed by automated tests that run in our build pipeline before any change can merge. They are not guidelines in a wiki. If a change violates one, the build fails and the change does not ship. Among what they enforce:
- Tenant-data isolation: records stay scoped to the tenant that owns them.
- No hardcoded secrets: a repository-wide scanner fails the build if it finds a credential.
- Constant-time comparison for every security-sensitive value.
- Parameterized database access only: raw or string-concatenated SQL is rejected.
- Deny-by-default authorization: every endpoint requires authentication unless it is explicitly allowlisted and justified.
- A fixed request pipeline: authentication, tenant resolution, and authorization run in a guaranteed, test-locked order.
- Backward-compatible migrations only: schema changes that could break the running version are blocked before deploy.
- Enforced architecture: layering boundaries and managed HTTP clients can’t be quietly bypassed.
Platform & operations
Run carefully, released safely.
No standing cloud credentials.
Infrastructure is defined as code and deployed through short-lived federated identity and managed identities, so there are no long-lived cloud passwords to leak.
Zero-downtime releases.
New versions are health-checked on a staging slot, in-flight agent work is drained before the swap, and a release rolls back automatically if error rates regress.
Durable error tracking.
Failures across every production path are captured to a durable, queryable log, with alerts on key capacity thresholds.
Gated production access.
Production deploys run through an authenticated pipeline that requires typed confirmation and code-owner approval on protected infrastructure and workflows.
Technical reference
The exact controls, in precise terms.
For the security engineers running a deep review, and the tools they use to do it, here are the specifics without the marketing gloss.
Cryptography & identity
- Password hashing
- Argon2id, m=64 MiB, t=3, p=1; 16-byte CSPRNG salt; constant-time verify (FixedTimeEquals)
- Multi-factor
- Required second factor: authenticator app (TOTP, RFC 6238) or emailed one-time code; single-use recovery codes, 10 × 80-bit, SHA-256 hashed
- Sessions
- HMAC-SHA256 signed JWT; issuer, audience, and expiry validated; 8-hour idle, 30-day absolute cap; re-validated on renewal
- Secrets
- Azure Key Vault (RBAC, soft-delete, purge protection), scope-separated; no secrets in source, enforced in CI
Data & tenancy
- In transit
- HTTPS; TLS 1.2+ minimum to the app, Azure SQL, and storage
- At rest
- Azure SQL Transparent Data Encryption; Azure Storage Service Encryption, AES-256
- Isolation
- Database-per-tenant physical separation; every request bound to a validated membership claim
- Backups
- Point-in-time restore, 35-day window; long-term retention on top
Application defenses
- Injection
- Parameterized queries only; raw-SQL concatenation blocked in CI; injection test battery
- SSRF
- RFC 1918 / loopback / link-local denylist enforced on the resolved connection IP (DNS-rebind safe)
- Comparisons
- Constant-time (FixedTimeEquals) for tokens, signatures, and secrets, enforced in CI
- Abuse control
- Partitioned rate limiters (by IP, automation, API config) on sign-in, email, automation, and webhook endpoints
- Browser
- Content-Security-Policy frame-ancestors; HTTPS redirection
Delivery & operations
- Infrastructure
- Azure, defined in Bicep; deploy via GitHub OIDC federated identity + managed identities, no standing credentials
- Releases
- Blue-green slot swap; /health/ready gate; in-flight agent work drained before swap; automatic error-rate rollback
- Schema
- Expand/contract migration guard blocks backward-incompatible changes before deploy
- CI guardrails
- Secret scan, deny-by-default authorization, request-pipeline order, tenant-scoping, dependency-direction, and HTTP-client-factory conventions
Going deeper on the due-diligence call.
This page is the overview. When your security team wants the specifics, here is where to go deeper, and for anything it doesn’t cover, just ask.
Working through a security questionnaire, or need to confirm a specific control? Email support@inscendoiq.com.