Start free

Security

Production message tooling, built paranoid

OpsChisel reads, repairs and resends live business data. That only works if the security model is stronger than what it replaces - the shared connection string and the hero script.

Start free - continue with Microsoft Ask a security question

No namespace credentials with RBAC

With Entra RBAC, access to your namespace is a role assignment, not a credential we hold. Optional connection strings, alert webhooks and AI provider keys are stored in Key Vault and shown once.

Originals that survive a fix

An edited resend that dead-letters again is captured as a new delivery on the same record. The earlier delivery keeps its hash, length and encoding, its body is retained inline or in overflow storage, and the record states per delivery whether that body is available - you open it from the History tab. Payload blobs are immutable and content-addressed: a write that loses a race never touches the bytes a committed record points at, and a body that cannot be stored fails the capture rather than being dropped.

Everything audited

Every mutating or destructive action - and every telemetry and AI lookup - lands in an append-only audit trail with who, what and when, and the before/after for edits and revocations.

Passwordless by design

Passwordless onboarding never asks for a connection string. You consent the OpsChisel DLQ Manager Connect application into your tenant and grant it a data-plane role on your namespace via Entra ID RBAC. The app holds no password or certificate - only a federated trust in our managed identity - and every call to your namespace or your telemetry uses a token issued in your tenant, so it works across tenants without a shared identity anywhere.

  • Grant, scope and revoke access entirely in your Azure tenant.
  • Least privilege, by name: Azure Service Bus Data Receiver on the namespace for capture, plus Data Sender only where you enable resend. Nothing broader.
  • Revocation is one-sided - remove the role assignment in your tenant and capture stops as Azure propagates it; you never have to ask us to disconnect.
  • A connection string remains available for a namespace that cannot use RBAC; it is stored in Key Vault, never shown again, and replaceable from the UI.
Your tenant Service Bus namespace your data never moves tenants Role assignment Azure Service Bus Data Receiver created by you - revoke anytime scoped data-plane access OpsChisel tenant no connection string, key or secret crosses Capture + console services Azure Container Apps Managed identity requests short-lived tokens from Entra ID short-lived Entra token nothing to rotate, vault or leak

Tenant isolation & data handling

OpsChisel is multi-tenant SaaS running on Azure Container Apps with Cosmos DB storage - the same cloud your workloads already trust.

  • Per-customer data isolation enforced server-side from the validated Entra token - a tenant id in a request is never trusted - and partitioned by tenant in every store.
  • Encryption in transit (TLS 1.2+) and at rest, using Azure platform encryption.
  • All customer data stays in Azure Sweden Central and is not replicated outside it.
  • Sub-processors are named plainly: Microsoft Azure (infrastructure) and Stripe (billing identifiers only - never message content).
  • Export retained records, every referenced payload - the current body and every retained prior body, inlined under its hash - and archived audit files as line-delimited JSON with a file manifest and integrity hashes (a reference the store could not serve is counted and listed, historical or current), or have every trace verifiably deleted from the live stores - a purge stops capture, cancels billing with credit, sweeps every store including archived audit and past exports, then re-counts each one and reports done only when nothing remains.
Tenant A Tenant B Tenant C TLS OpsChisel services - Azure Container Apps every query runs under the caller's validated Entra tenant - never a tenant id from the request Cosmos DB hierarchical partition keys /tenant-a/... isolated partition /tenant-b/... isolated partition /tenant-c/... isolated partition

Least privilege inside the product, too

Your own operators are governed as tightly as our service is. Sign-in is Entra ID only - no local passwords - and what a signed-in user can do is decided by fine-grained roles.

  • Built-in roles for the common shapes: admin, operator, read-only viewer.
  • Custom roles compose granular permissions (view, resend, edit, archive, delete, administer).
  • Namespace groups give a department its namespaces as one scope: a role granted on the group covers every namespace in it, now and later. A department admin grants and revokes on their own groups and sees only their own side of a shared namespace; which namespaces a group holds stays with a tenant admin. A change applies immediately where it was made and within 60 seconds everywhere. Alert rules and saved notification channels take the same group scope, so a department's alerts go to the department's channel and a channel is never deleted while a rule still sends to it.
  • Grant to Entra security groups, so a person who changes department is moved in Entra and their access follows; time-limit a grant for a contractor; every revocation is in the audit trail.
  • Give support teams eyes-on without hands-on via the viewer role.
The Namespace groups tab: the Company group expanded, showing its two namespaces, the role inherited by every namespace in the group (Anna Lind, viewer, until 2026-12-30) with move and revoke actions, and the Membership group below
The Grant access dialog with scope set to A namespace group, the Company group picked, and an optional day on which the access ends
The roles page: built-in and custom roles with their granular permissions - view, resend, edit, archive, delete, administer - ready to assign per namespace or entity

Guardrails on every sharp edge

Message operations are inherently powerful, so the defaults assume the worst moment - an incident, at night, under pressure.

  • Payloads are validated (JSON/XML) before any send.
  • Topic resends reach only the subscription that dead-lettered once the topic's subscriptions carry the targeting filter - until they do, the resend is refused rather than fanned out (a tenant setting turns the check on).
  • Bulk actions are selection-aware: touching everything under an entity demands a separate, spelled-out ALL confirmation.
  • Edit-locking stops two operators from repairing the same message at once - visible live across the team.
  • Auto-remediation is dry-run by default with a retry-ceiling loop guard, and never auto-deletes.
  • Deletes are explicit, role-gated, audited and never broader than the selection: a delete scoped to one failure cluster deletes that cluster, and the four-eyes threshold counts exactly what the sweep will touch.
Confirmation dialog for a bulk delete: three selected order dead-letters ticked in the grid, the action bar reading Resend 3, Archive 3, Delete 3, and the dialog asking 'Delete 3 messages? Are you sure you want to delete the 3 selected messages?' with Cancel and Delete

A supply chain you can verify

The trust story does not stop at runtime - it covers how the software is built and shipped. Every release runs a gated pipeline, and production only ever runs an image this pipeline cryptographically signed.

  • Every change is scanned for known-vulnerable packages, committed secrets and high-severity code findings, and blocked on any of them.
  • Each build publishes a bill of materials for both source and container image, and each image gets a keyless cryptographic signature (Sigstore / transparency log).
  • Deployment refuses any image this pipeline did not sign, and production ships only from the main line behind a dated confirmation - with the deploy identity scoped to the product's own resource groups.
  • No shared keys inside the platform: storage, the real-time backplane, the command bus and the secret vault all authenticate with managed identity.

Why it matters

Supply-chain compromise is how modern breaches happen. A signed image that a deployment refuses to run unsigned, plus a bill of materials for every release, is the difference between "trust us" and "here is the proof."

Compliance

Paperwork your security review will ask for

We're early, and we'd rather be precise than impressive. Here's where things stand.

SOC 2

On the roadmap - the controls are being designed against SOC 2 criteria from the start rather than retrofitted. We'll publish audit status here as it progresses; ask us where it stands today.

Data residency & GDPR

All customer data lives in Azure Sweden Central and is not replicated out. Sub-processors are Microsoft Azure and Stripe (billing identifiers only). You can export everything or have it verifiably deleted; the data-handling summary has the detail, and a DPA is available on request.

Security questionnaires

We answer vendor assessments and can walk your security team through the architecture. Start the conversation.

The safest secret is the one that doesn't exist.

Connect with an Entra role assignment, watch the audit trail fill in, and revoke it whenever you like. That's the whole trust model - try it free for 30 days.

Start free - continue with Microsoft Compare with Azure Monitor