Security & trust

Built to never surprise a portal.

You are responsible for your clients' HubSpot accounts. So NoxusHub is engineered to be safe by construction: read-only until you say otherwise, create-only when you do, and never a mutation a human didn't approve.

See how it works
Principles

Guardrails, not promises.

Each of these is enforced in the platform — a design invariant, not a setting someone can forget to flip.

Read-only by default
Every connected portal starts UNCONFIRMED and read-only. Agents can audit and analyse, but cannot touch a thing until you deliberately raise the access level.
Create-only writes
When writes are enabled they are strictly create-only — agents add new objects, never mutate or delete existing live records. There is no path to overwrite what a client already has.
API-verified sandbox label
A portal can only receive writes once we confirm, against the HubSpot API itself, that it carries a sandbox label. We verify the claim — we don't take a checkbox's word for it.
Human-in-the-loop approval
Nothing auto-mutates a portal. Every proposed change waits behind an explicit approval gate, with a readable diff, until a person on your team signs off.
Secrets encrypted at rest
OAuth tokens and credentials are encrypted at rest with Fernet. Plaintext secrets never sit on disk and never appear in logs.
Short-lived scoped tokens
Service-to-service actions use HMAC-signed tokens that are short-lived and scoped per workspace and per run. A token leaked from one job can't reach another client or outlive its task.
The path a change takes
A proposed change runs through the integration sandbox first and must pass before it is ever offered for production. Only after the sandbox run, an API-verified sandbox label, and an explicit human approval does anything reach a live portal — and even then, create-only.
How we handle data
We pull only the portal data an audit or task requires, keep it scoped to the workspace that connected it, and encrypt credentials at rest. Tokens are short-lived and scoped per run, so access narrows to exactly the job in front of it.

Read our Data Processing Addendum and the full list of subprocessors.

Connect a portal. It stays read-only until you decide.

See pricing