Security at tamr.

Infrastructure

• Encrypted in transit. All traffic is served over TLS behind Cloudflare, with HSTS so browsers only connect over HTTPS.
• Hosted in the EU. Application servers and the database run in Amsterdam, Netherlands.
• Encrypted backups. The database is backed up continuously, and backups are encrypted.
• Edge protection. Cloudflare's firewall and bot protection sit in front of the app, with a Turnstile bot check on the guest chat.

Data isolation and roles

Each restaurant is its own organization. Every request checks that the signed-in user is a member of that organization and has a role allowed to do what they are asking.

Restaurants can also create custom roles with the permissions they choose.

Account security

• Strong sign-in options. Passkeys, sign-in with Google or GitHub, email links, and passwords of at least 12 characters.
• Two-factor authentication. Any user can turn on an authenticator app (TOTP), and owners can require two-factor authentication for their whole team.
• Brute-force protection. Sign-in is rate limited per IP address, and password sign-in is temporarily locked after repeated failures.
• Recent sign-in for sensitive changes. Changing your email, removing a passkey, deleting a restaurant and creating API keys all require that you signed in recently.
• New device alerts. We email you when your account is used from a device we have not seen before.
• Server-side sessions. Sessions are stored on our servers, so you can see and end them from account settings.

API keys and integrations

• API keys are stored only as hashes, scoped to read or write, revocable at any time, and rate limited.
• Credentials for point-of-sale integrations are encrypted at rest with AES-256-GCM.

AI safeguards

• The tamr AI assistant can only propose changes. Nothing is applied until an owner approves it in the app.
• Phone numbers and emails are removed from guest messages before they are stored or sent to a model, unless a restaurant turns this off.
• AI requests exclude providers that retain or train on prompts.

Application security

• Security headers and a content security policy.
• Server-side protection against requests to internal networks when tamr fetches a URL you give it, such as a menu website.
• Uploads are restricted by file type and size.

How we build and ship

• Dependency and secret scanning run in continuous integration.
• Deploys only go out after the test suite passes.

Logging and audit

Account, security and admin actions are recorded in an audit log, including any time a tamr administrator impersonates a user to give support.

Privacy

How we collect, use and delete data is covered in our privacy policy, the vendors we use are on the subprocessors page, and restaurants can review our data processing addendum.

Reporting a vulnerability

If you think you have found a security issue in tamr, email [email protected] with the details and steps to reproduce. Our contact details are also published at /.well-known/security.txt.

• Give us reasonable time to fix the issue before sharing it publicly.
• Do not access or change other people's data, and stop as soon as you have shown the issue exists.
• Do not run tests that disrupt the service, such as denial of service or spam.