Skip to content

What we do with what you connect.

OnDuty reads systems that hold your customers' information. These are the mechanisms that constrain what it can do with them, and the things we have not done yet.

Two directions, and only one has a gate

YOUR SYSTEMSONDUTYREADS, READ-ONLY, NO GATE NEEDEDPERMITACTS, ONLY THROUGH THE GATE

A source connector has no code path that writes to your system. Anything OnDuty does to a system of yours is an action, and every action passes the decision engine first. There is no third path where a read turns into a write.

Credentials

  1. Encrypted at rest

    Fernet, key outside the database

    A copy of the database on its own does not yield a working credential.

  2. No key, no connection

    fail closed

    With the encryption key unset, connecting a source is refused. It never falls back to plain text.

  3. Losing the key is unrecoverable

    by design

    Every source has to be reconnected. A recovery path would be a second way to read the credentials.

  4. A refresh token only replaces a refresh token

    Google

    An absent value on a later consent leaves the stored one alone instead of destroying a working connection.

Built By design

The controls that matter are the ones a mistake cannot switch off. Read-only is a property of the code, not a checkbox. Fail-closed lives in the executor. An unknown role resolves to the least privilege, not the most.

Who can do what

Two different things get called role, and conflating them is how someone ends up with access nobody meant to give. Here they are separate.

Platform roleWorkspace role
What it saysWhether someone is OnDuty staffWhat someone can do inside one workspace
Where it appliesOur own administrative surfaceYour workspace, and only that one
ValuesStandard, or platform administratorOwner, admin, operator, analyst, viewer
Implies the otherNo.No.
  1. Permission, never role

    A route asks for a named permission, not for "admin or owner". Roles map to permissions in one place.

  2. Unknown resolves to least

    A role string nobody recognises is a viewer. A row that got there by a bug is never an owner.

  3. Nobody grants above themselves

    An admin cannot make an owner. Closed at the service, not hidden in the interface.

  4. A workspace keeps an owner

    The last owner cannot be removed or demoted.

  5. Support access is deliberate

    Our reaching into your workspace is an explicit, time-limited, read-only act through the administrative surface, with a written reason, and it is recorded where your owners can see it.

Built

Agents that run on your machines

On the top plan an agent runs inside your network, so conversation content never leaves it. A token of ours then lives on a machine we do not control, and the design assumes that machine is hostile.

  1. Two endpoints, and no more

    heartbeat, assignments

    A runner can reach exactly two routes. Every other route in the product is closed to it, and a test over the full route inventory says so.

  2. The token is hashed and shown once

    Lost means reissued, not recovered.

  3. Health is derived from silence

    A machine that has died cannot write "unhealthy" anywhere, so we compute it from when it last spoke.

Built

Where your data sits

In your workspace, in our Postgres database, scoped by tenant on every query. Every record carries the source it came from; disconnecting a source deletes the credential at once and keeps the record of where knowledge came from, marked as no longer connected.

What we have not done

You would find these out later anyway, and a company selling governance should not be vague about its own.

  1. No third-party audit

    SOC 2, ISO 27001

    Nobody outside has examined our controls, so we do not describe them as certified. If a formal review is a requirement, tell us and we will talk about the timeline honestly.

  2. Google verification pending

    restricted scopes

    Gmail and Drive use scopes that need a review before an app is opened past a limited number of users. We are in it, not past it.

  3. Intuit app review pending

    QuickBooks production keys

    Intuit issues production keys only after its app review. Until then QuickBooks connects sandbox companies, not real ones.

  4. Meta App Review pending

    Facebook Pages, Instagram, Meta Ads

    Every Meta permission we ask for needs Meta's App Review before anyone without a role on our app can grant it. Until it is done these sources work for our own accounts and not for yours.

  5. No public API

    by design

    No self-serve developer API and no public key issuance. Every integration goes through a connector we wrote and can reason about.

  6. Data residency is enterprise-only

    deployment decision

    Choosing where data lives is arranged per deployment, not a toggle that does nothing.

Not done In progress By design

Ask the awkward questions.

We would rather answer them now than have you find the answer yourself in six months.

On duty ·