Maddox holds the record of who your customers are, what was said to them and what was promised. That is not data you get to be casual about, so the controls below are properties of the platform rather than options on a plan.
Tenant isolation by construction
Every record carries its tenant. Isolation is enforced in the data layer on every query rather than remembered by each feature, so a new feature cannot forget it.
Role and field level permissions
Access is granted per role and, where it matters, per field. A user who should not see a margin does not see the field, not merely a blurred value.
Everything is on the record
Changes are written to an audit trail you can query – who changed what, when, and from where. A change proposed by the assistant and approved by a person is written there too, alongside the arguments it was applied with.
Agents are configured, not dispatched
An agent here is a definition you write, scope, test and switch off. No agent sends an email, creates a record, updates a field or assigns an owner, so there is no unattended action path to bound – and we would rather state that on this page than let a reviewer assume otherwise.
Retention you control
Retention is a policy set per workspace, and it stays inert until both the switch is on and a window is set – deleting permanently is not something a half-finished settings page should be able to start. Data subject requests are handled as a first-class operation, not a support ticket and a database query.
Encrypted in transit and at rest
TLS on every connection, encryption at rest on the database and on stored files. Secrets are held outside the application image.
Reporting something
If you believe you have found a vulnerability, tell us through the request form and say so in the message. Tell us what you did and what you saw; we will confirm receipt and tell you what we are doing about it.
Isolation
A feature cannot forget which customer it is looking at.
Multi-tenant isolation fails in one predictable way: somebody writes a new query and does not add the filter. So the filter is not something a query adds. It is something a model has.
The filter is applied by the model, not by the caller.
Every tenant-owned table carries a tenant column, and the models over those tables attach a global scope that adds the predicate to every query built through them. A developer writing a new report does not opt in to isolation and cannot forget it; they would have to explicitly remove the scope, by name, in a diff, to lose it. The same hook stamps the tenant on every row at creation, so a record cannot be written without one either.
Where the scope is removed on purpose, it is replaced.
A handful of paths genuinely run without a signed-in tenant user — a scheduled sweep, a provisioning run, a support operator whose principal sits above the tenant boundary. Those paths remove the scope explicitly and state the tenant themselves in the same expression, because the global scope is fail-open for a principal that has no tenant, and a background job quietly inheriting whoever happened to be authenticated is the exact defect this arrangement exists to prevent.
What isolation is not.
It is not an encryption claim and it is not a per-customer database. Your data sits in the same schema as other customers’ data, separated by a predicate that every read and write carries, and the honest way to evaluate that is to ask where it is applied rather than to ask whether it exists. We would rather tell you it is one column and one scope than describe it as an architecture.
Access
Roles, and then fields inside a role.
Most CRMs stop at the record. A margin, a cost, a personal phone number and a compensation note all live on records people are supposed to see.
A hidden field is absent, not blurred.
A field permission is a row naming a role, an entity type and a field, and carrying two answers: may this role see it, and may this role change it. A role that may not see a field does not receive it. A role that may see but not change it gets a value it cannot write. Anything with no row is visible and editable, so the model is deny-what-you-name rather than grant-what-you-remember — which means a new field is not silently invisible to everybody the day it ships.
Four gates decide what the assistant can even be offered.
Before Ask Maddox is given a single tool it passes four intersected checks, and each one reports separately why it refused: a deployment-wide feature switch; a deny list that admins do not pass; the module gate, which is the same predicate the route gate uses, so the assistant never offers a capability whose screens the workspace has switched off; and then every permission the tool declares, all of them.
The module gate reusing the route gate matters more than it sounds. It means a capability cannot appear in the assistant that the person could not reach by clicking, which is the shape of the mistake that turns an AI panel into a privilege-escalation surface.
Four domains are refused structurally, for everybody.
Data-subject erasure, API keys, user and role administration, and marketplace mutation are not permissions the assistant fails to hold. They are domains the tool registry is never built to contain, so there is no configuration of roles — including a full administrator’s — in which the assistant reaches them. The same list is applied to a support operator working inside a workspace, from one place, so the next destructive domain cannot be added to one list and missed on the other.
The record
What happened, who did it, and what they approved.
An audit trail is only worth what it can answer under pressure. These are the three questions this one is built for.
Changes are written to a queryable trail.
Who changed what, when, and from where, on the record rather than in a log file. A change the assistant proposed and a person approved is written there too, alongside the arguments it was actually applied with — which is a different and more useful thing than recording that an approval happened.
What executes is read from the database, never from the request.
When the assistant proposes a change, the proposal is persisted and the browser is given an identifier. Confirming names that row; it does not describe a mutation. Before this, the confirm endpoint took the tool and its arguments straight off the wire, so a stale tab, an edited payload and a genuine approval were indistinguishable by the time they reached the registry — and indistinguishable in the audit trail afterwards.
Approval is also only meaningful about a world that has not moved. Between the moment a proposal is rendered and the moment somebody clicks it, another person can edit the same record. A proposal that can be re-checked is re-checked immediately before it is applied, and a mismatch is re-presented rather than applied. Approximately what somebody approved is not what they approved.
AI work is logged as AI work.
Enrichment, scoring, summarisation, classification and suggestion runs are written with the model used, a confidence figure, a summary of what went in and what came out, and — once somebody responds — whether it was accepted, and the reason if it was not. That last column is the one that makes the log worth keeping: it is the difference between a record of what the software did and a record of whether it was any good.
No agent acts, so there is no unattended action path to bound.
An agent here is a definition you write, scope, test in a sandbox and switch off. Nothing in MADDOX sends an email, creates a record, updates a field or assigns an owner because an agent decided to. We state that on this page rather than describing constraints on an execution path, because a reviewer is entitled to ask where the constraint is enforced and the honest answer is that there is nothing to enforce it on. The long version is written up here.
Data lifecycle
Retention, erasure, and the recording that deliberately does not survive.
The questions a compliance officer asks in the second half of the call are about leaving, not about arriving.
Call audio is transient by design; what is derived from it is kept.
Once a recording has produced a transcript — or has been examined and found to contain nothing assessable — the audio is deleted and everything derived from it stays. A failed or pending transcription never triggers the purge, because deleting audio on a retryable hiccup would turn a transient error into a permanent loss. The audio is the bulk and the liability; the transcript is what the product actually reads.
Call-audio retention needs two switches, on purpose.
A softphone call-audio retention policy is inert unless the workspace has both turned it on and given it a window. That is not belt-and-braces. A number typed into a settings field and abandoned is a plausible accident; everything else in that catalogue is reversible and this one deletes permanently, so the destructive path is deliberately not reachable by filling in a single field. The default scope keeps transcripts and removes only audio.
Uploaded recordings are kept thirty days unless you say otherwise.
Meeting recordings attached to a deal and 1 on 1 recordings uploaded for coaching have their own policy, and it is on by default: once a recording has been transcribed and is more than thirty days old, the file is removed and the transcript is kept. A recording still being transcribed, or one whose transcription failed, is never touched. An administrator can lengthen the window or switch the policy off.
A changed password or a deactivated user takes effect on the next request.
Every signed-in request re-checks the password the session was opened with, so changing a password ends every other session on the very next request, wherever it was changed from. Deactivating a user is checked on every request too, and the same refusal is applied to remembered sign-ins and to API keys, which reach the product by different doors. There is no window in which a departed employee’s open tab keeps working until it expires.
Consent and erasure are first-class objects.
Consent is recorded per contact, per channel and per purpose, with its source, when it was given and when it was withdrawn — withdrawal being a state on the record rather than a deleted row. A data-subject request is an object with a type, a due date and a completion, not a support ticket and a hand-written query, and a contact’s data can be exported in full on request.
One boundary stated plainly, because it is the one a reviewer will find: recording-consent law is resolved from the number being called and the rep is warned, in words, at one of four graded levels before the call connects. It is a warning and a record, not a block. If your policy needs an enforced block rather than an informed rep, it has to be built where the recording is actually made. That page states the same boundary at length.
Questions
The things people actually ask.
Is our data used to train the models?
No. MADDOX does not train, fine-tune or otherwise learn from your records — there is no training pipeline in the product at all. Each AI feature calls a commercial model API, and which provider serves which feature is configuration you can read rather than something hidden. What a provider may do with an API call is governed by that provider’s own terms; ask us and we will tell you in writing which provider serves which feature on your workspace.
Can MADDOX staff see our customer data?
Access is by the same tenant scoping everything else uses, and support access to a workspace is an action that leaves an audit-trail row rather than an ambient permission. If you need a named list of who can reach a workspace and under what conditions, ask — that is a question with a specific answer, not a policy paragraph.
How is one client’s data kept out of another’s?
Isolation is applied in the data layer on every query rather than remembered by each feature, so a new feature cannot forget it. That is the single most important sentence on this page: the boundary is structural, which is why it does not depend on the discipline of whoever writes the next screen.
What happens to call recordings, and for how long?
Softphone call audio is deliberately transient: once a call has been transcribed, the audio is deleted and the transcript and its utterances are kept. Uploaded meeting and coaching recordings are kept thirty days after filing by default, then the file is removed once its transcript exists. Both windows are tenant-controlled, and consent handling is described on the recording-consent page.
Are you SOC 2 or ISO 27001 certified?
Ask us directly and we will answer in writing rather than implying a status on a marketing page. What this page can tell you without qualification is what the software actually does: isolation enforced in the data layer, permissions down to the individual field, an audit trail you can query, and a documented list of what nothing delegated is allowed to reach.
How do we get a security questionnaire completed?
Send it. A questionnaire answered against this page’s claims is a fair test of them, and it is a faster conversation than a call. If an answer is no, you will get a no rather than a paragraph that reads like a yes.
Related
Send this page to whoever has to sign off.
If a control you need is not described here, ask us about it directly rather than assuming it is implied. We would rather answer no early than be found out late.