Security

How we isolate every print shop's data

Markyard is multi-tenant: many print shops share the same database. The strongest thing we can honestly say about that is that isolation between them is enforced by the database itself, not by application code remembering to filter correctly.

Every table that holds a shop's data carries row level security with two settings on together: enable, which turns row level security on at all, and force, which keeps it on even for the table's own owner. Without force, a bug that ran a query as the table owner, for example a misconfigured admin script, would silently see every shop's rows. With it, that path is closed at the database layer, before any application code runs at all.

This is not a claim we ask you to take on faith. It is checked by an automated script in our own repository that queries the database directly and confirms, table by table, that both settings are on and that access behaves as intended, rather than a line in a document that nobody re-checks after launch.

Authentication

Markyard uses Supabase Auth for sign-up, login and session handling, with email and password or Sign in with Google. Passwords are handled by Supabase Auth directly; Markyard's own code never sees or stores a plain-text password. Sessions travel in secure, http-only cookies.

Every account can turn on two-step verification with an authenticator app, and a workspace owner can require it for everyone in the workspace. That requirement is enforced by the database: without the second step, a member of such a workspace cannot read its data, whatever the screen shows.

Secrets and token handling

API keys and database credentials live in server-side environment variables, never in code shipped to the browser. The OAuth refresh token Google issues for a connected Gmail mailbox is encrypted with AES-256-GCM before it is written to the database, using a key held outside the database itself, so a copy of the database alone is not enough to read a live token. The token is decrypted only on the server, for the moment it takes to ask Google for a short-lived access token, and is never logged or sent to the browser.

Gmail access

The direct Gmail connection asks Google for permission to read mail and to send mail, and nothing else. Neither permission can delete, archive, label or change a message in your mailbox. Only an owner or admin can connect a mailbox, the connection is tied to their workspace with a one-time security check, and disconnecting it asks Google to revoke the grant and deletes the stored token at once. What Markyard reads and keeps is described in the Privacy Policy.

What we hold, and where

Markyard's database and files are hosted by Supabase in the European Union, encrypted at rest. The application runs in Vercel's Frankfurt, Germany region. Every connection to it is HTTPS only, with strict transport security, framing disabled and other standard security headers set on every response. AI processing of inquiry text is performed by Google's Gemini API. See our Privacy Policy for exactly what that involves and where it sits under GDPR.

The AI boundary

Markyard's AI reads an inquiry and suggests: a set of extracted details, a quote, a reply. Replies and quotes go out after a person in your workspace approves them, and that requirement is checked by the database, not only by the interface you see.

The one exception is a setting an admin has to turn on for a mailbox, after confirming a warning: automatic replies that ask a customer for missing details. They are capped at three per inquiry and 200 per workspace per day, messages Markyard recognises as automated, such as out-of-office notes, are not answered, and quotes are never sent this way.

Untrusted email and prompt injection

Anyone can send an email, so the text of every message is treated as untrusted input. In every request to the AI model it is fenced off and labelled as data to read, never instructions to follow. The model's answers are untrusted too: they are checked against a fixed format before anything is stored, an answer that does not fit is discarded, and every AI-written reply is checked against written rules and rewritten once if it breaks one. An automatic reply is checked again just before it would leave: if it still breaks a rule, or contains a link, an email address or a web address that is not in the shop's own signature, it is not sent and waits for a person instead. The model has no access to settings, permissions, other inquiries or other workspaces, so a message written to manipulate it can at most affect what is extracted and drafted for that one inquiry. Attached files from Gmail are never sent to an AI model.

Report a security issue

If you find a security problem in Markyard, we want to hear about it before anyone else does. Reach us through the contact page and describe what you found; we will follow up directly.

Incidents are handled under a written internal incident response procedure: detection, containment, investigation, notification, record-keeping and follow-up. If a personal data breach affects a print shop's data, we tell the shop within 72 hours of becoming aware of it, as our Data Processing Agreement sets out.