Skip to main content
Avanti Robotics
Book a demo
AVM-WR-019Datasheet

Platform security

The authentication model, the tenant boundary, what is signed, where the gaps are, and how to report a vulnerability.

One dashboard for your whole fleet.

1Three ways in

People, robots and integrations reach this platform by three different routes, and each proves itself differently.

  • A person

    Session sign-in, constrained by role

    A password or a magic link establishes a session. What that person may then do is governed by one of four roles — owner, admin, operator and viewer — which form a strict privilege ladder: a viewer cannot write, an operator cannot manage users, and only an owner reaches billing.

  • A robot

    X.509 certificate over mutual TLS

    Each robot holds its own certificate, bound to the device and to its tenant, and presents it on every connection. A robot holds no password and no token. Certificates are held encrypted at rest and are never serialised into an API response after the one moment of initial provisioning.

  • An integration

    A bearer token, scoped by ability

    An integration presents a bearer token your team mints and revokes. A token carries one or more abilities from a closed set of three — read, commands and telemetry — so an integration only ever has the access it needs.

2The tenant boundary

Many organisations share this infrastructure, so isolation is the property everything else rests on. Every record is scoped to its tenant, and the scoping is applied in the data layer, so no individual query has to remember it.

The behaviour worth checking is what happens when the check has nothing to work with: where no tenant can be resolved, the query returns nothing at all. A fault in that path produces an empty result, never another organisation's robots. Cross-tenant isolation carries its own test suite, and a change that could leak across tenants does not pass.

Three ways in, and the wall none of them crossesA section through the platform, drawn as a building on a ground line. The outer wall is marked authentication and has three doors cut through it, one for each kind of caller waiting outside: a person who signs in and whose role limits what they may do, a robot — drawn as the same undimensioned outline used elsewhere on the site — presenting an X.509 certificate over mutual TLS bound to the device and its tenant, and an integration presenting a token whose abilities are a closed set of three: read, commands and telemetry, with no fourth. Inside, a second wall is marked tenant isolation. It has exactly one opening, and all three lanes pass through it scoped to one tenant, reaching a room holding that tenant's robots, telemetry, users and behaviours. A fourth approach, where no tenant can be resolved, gets through the authentication door and then meets the inner wall where there is no opening at all: it is solid hatched masonry, and nothing is returned.GROUNDSECTIONNOT TO SCALEUNDIMENSIONEDTHE PLATFORMAUTHENTICATIONTENANT ISOLATIONONE OPENINGscoped to one tenantONE TENANT'S DATArobots, telemetry,users, behavioursand nobody else'sA PERSONuses the dashboardSigns in, and what they may dois limited by their role.X.509 certificate over mutual TLS,bound to the device and its tenant.AN INTEGRATIONcalls the APIA token, and a closed set of threeabilities — nothing else is grantable.A ROBOTreports and receivesreadcommandstelemetryand no fourthNO TENANTcan be resolvedNo opening. Nothing is returned.
AVM-FIG-05Three ways in, and the wall none of them crosses

Three kinds of caller reach this platform, and each proves itself differently. A person signs in, and their role limits what they can do. A robot presents a certificate over mutual TLS that is bound both to that device and to its tenant — not a shared secret, and not a password. An integration presents a token whose abilities are a closed set of three: read, commands, telemetry. There is no fourth ability to grant.

The outer wall is authentication, and it has three doors because there are three credentials, and no more.

The inner wall is tenant isolation, and it has one opening, because there is one rule: everything that gets this far is scoped to exactly one tenant. Beyond it is that tenant's robots, telemetry, users and behaviours, and nobody else's.

The fourth approach along the bottom is the part worth reading twice. Where a tenant cannot be resolved, the query does not fall back to a default and it does not return everything — it returns nothing. On this sheet that is not a labelled branch, it is blank masonry: the inner wall simply has no opening down there. The safe outcome is the automatic one. An isolation guarantee that depends on every future author remembering it is not a guarantee; this one holds when someone forgets.

3Certificates, updates and transport

Certificates rotate without downtime and are revoked immediately if compromised.

Every update is cryptographically signed before it leaves the platform; a missing or invalid signature means nothing is applied. Updates are behaviour documents, not firmware images.

Connections to the API, the dashboard, the realtime channel and the robots' own messaging use current TLS, and each robot's channel is partitioned to its own tenant. Commands cannot be replayed, and outbound webhook traffic is protected against common network attacks.

4What we build against, named

The platform is built against a written threat model and assessed against the OWASP Top 10. Where the platform handles personal data, the governing regime is the UK GDPR and the Data Protection Act 2018. Robots sold as connectable consumer products fall under the Product Security and Telecommunications Infrastructure Act 2022 and the security requirements regulations made under it; the conformity register on the safety document names each obligation and what it requires.

5Data residency

Your data is processed and stored on UK servers, under UK law. That is the design of this platform, and it is the commitment we intend to be held to.

The platform's storage and processing default to a London region, and the design keeps every byte under UK law. Bring your CISO's questionnaire to the demonstration and we will answer it against the platform, section by section.

6Reporting a vulnerability

If you have found a security issue in this site or in the Avanti platform, we want to hear about it before anyone else does. Contact details, the languages we read and the expiry of this record are published in machine-readable form at /.well-known/security.txt, following RFC 9116.

What we ask

  • Report it to us first, and give us a reasonable period to fix it before publishing.
  • Include what you did, what you observed and enough detail for us to reproduce it.
  • Do not access, modify or delete data belonging to anyone else, and stop as soon as you have demonstrated the issue.
  • Leave denial-of-service, spam and social engineering out of it.

What we will do

  • Acknowledge your report and tell you what we think it is.
  • Keep you informed while we work on it, and tell you when it is fixed.
  • Credit you when we publish the fix, unless you would rather we did not.

We run no bug bounty and offer no payment. We will not pursue anyone who reports a genuine issue in good faith and within the boundaries above.