Security
Security at Xyranik
Xyranik acts on your behalf — it sends to your customers, spends on your ad accounts and holds the keys to the systems you connect. This page sets out the controls behind that, and the ones that are not built yet, in the order a security review asks for them.
Certifications and audits
Xyranik holds no security certification — not SOC 2, not ISO 27001 — and has not been through an external audit or penetration test. We do not describe ourselves as aligned with, ready for, or working toward any of them, because none of that is something you could verify. What exists are the controls below, each one a thing the product does today and which you can check for yourself in the product.
Documents
- Subprocessors
Every service Xyranik can send a workspace’s data to, what each receives, and what turns it on — read from the product’s configuration.
- How Xyranik processes personal data
Who is responsible for what, consent, retention, deletion and a person’s rights, for India’s DPDP Act and the GDPR; and how to ask for the data processing agreement.
Access and identity
Roles
Owner, admin, member and viewer. Every change is checked against the person’s role on the server, so a viewer can look but cannot change anything.
BuiltSingle sign-on
People sign in through your own identity provider, over OpenID Connect. A connection accepts only addresses in its own domains. Once a sign-in through it has worked, you can require it, and a password alone then gets no one on those domains in.
BuiltSCIM provisioning
Your identity provider can add people, change their role and remove their access, over SCIM 2.0. Removing someone takes their access away at once. It accepts the request formats Okta and Microsoft Entra ID use, and has not yet been run against a live provider.
BuiltPasswords
Password sign-in is handled by Supabase Auth. Xyranik’s own database holds no passwords.
BuiltTwo-factor sign-in
Anyone can turn on a code from an authenticator app, in Settings under Security. It is checked on the server, not only in the browser: a session that has had a password but not the code is refused every page until the code is given, so closing the prompt does not get past it. There are no backup codes yet — losing the device means contacting us.
BuiltWhere you are signed in
Every session your account has been seen using is listed in Settings under Security — the browser, the address it was last seen from, and when — and any of them can be signed out. Signing one out refuses it everywhere in Xyranik from that moment. The sign-in itself is held by our authentication provider, which offers no way to destroy one early, so it expires on its own rather than being deleted; changing your password is what ends it everywhere.
BuiltSign-in addresses
A workspace can restrict itself to its own addresses and ranges, IPv4 or IPv6, in Settings under Security. Off unless an admin turns it on, and checked on the server on every page and every API request rather than only at sign-in, so a session that moves to another network stops working rather than continuing. A list that would not admit the admin saving it is refused instead of stored — but if your own address changes afterwards you are refused like anyone else, and getting back in means contacting us.
Built
What software is allowed to do
Every agent is somebody
Each agent has an identity of its own, separate from the person who set it up: its own permissions, the most sensitive data it may use, and the most risk it may ask for. Xyranik’s own agents work this way too, so “pause that one” stops that one and nothing else.
BuiltDecided before it happens
Every action an agent asks for is checked against what that agent may do, whether the tool is switched on here, the data it would use, how risky the request is, and the rules you wrote. The model asking never decides; the answer is written down with every check, refusals included.
BuiltRules in your own words
Ask me before an ad budget goes up by more than 20%. Never let an agent take more than 100 people’s details. A request that leaves out the figure a rule is about is refused rather than waved through, so leaving a fact out is not the way around a rule.
BuiltOne switch stops all of them
It refuses everything from that moment: new runs, changes waiting to be carried out, and anything an agent asks for. A run already working stops at its next step. If the switch itself cannot be read, agents are treated as stopped rather than allowed.
BuiltThe agents you build, held the same way
An agent of your own asks the same question over the API — may this agent do this, here, now? — on a credential of its own that carries no permissions of its own: what it may do is decided per request, against the same checks and written to the same record. The answer is allowed, denied, or that somebody here has to decide first, which is not a yes. A leaked workspace token is the workspace; a leaked agent credential is one agent, and revoking it stops that one.
Built
Data protection and audit
Workspaces kept apart
Each workspace’s records are its own. A request for a record that belongs to another workspace is answered as if the record did not exist.
BuiltEncrypted credentials
The keys and tokens for the accounts you connect are encrypted before they are stored, each under its own random key (AES-256-GCM). The key that protects those keys can be replaced without breaking a connection.
BuiltAPI tokens
A token carries only the permissions it is given and is stored as a one-way hash. It can be revoked at once, or replaced with an overlap of up to a week. A test token reads your real data and only simulates changes.
BuiltData retention
An admin chooses how long two kinds of personal detail are kept: what people typed into forms, and anonymous visits and clicks. A daily run clears what is older. Until a period is set, nothing is removed.
BuiltAudit log
An append-only record of who did what and when: a person, an API token by its name, the system or an agent. Nothing in Xyranik edits or deletes an entry. Each closed day of entries is also hashed and chained to the day before it, so an entry changed or removed afterwards no longer matches its seal — and the day it happened is named.
Built
Application and network
HTTPS only
Browsers are told to reach Xyranik only over HTTPS, for a year at a time and on every subdomain (HSTS).
BuiltNo framing by other sites
Other sites cannot show Xyranik’s pages inside a frame, which blocks clickjacking. Hosted sign-up forms are the exception: they are made to be embedded, and carry no session and no customer data.
BuiltRate limits
The API, SCIM, single sign-on, public forms and AI work are rate-limited. The API allows 600 requests an hour for each token, and SCIM 3,000.
BuiltSigned webhooks
Each webhook is signed (HMAC-SHA256) so you can check it came from Xyranik. None is sent to a private or internal address: the address is checked when you save it and again before every send.
BuiltError reports without secrets
When something fails, the error report has cookies, request bodies, authentication headers, keys, email addresses and phone numbers removed before it leaves Xyranik.
Built
The people you contact
Consent on record
Each sign-up through a hosted form, each confirmation and each unsubscribe is recorded with its source and time, and a sign-up keeps the wording the person agreed to. The record stays even if the contact is later deleted.
BuiltOne-click unsubscribe
Each email carries the recipient’s own unsubscribe link and a one-click unsubscribe header, so mail apps can show their own Unsubscribe button.
BuiltSTOP for texts
Anyone who replies STOP to a text is not texted again, by any workspace that has their number.
Built
Not in place
Listed so you know where each stands.
- A security certification. Such as SOC 2 or ISO 27001.
- Checking a change landed as asked. A change is recorded as carried out when the platform accepts it. Nothing reads the value back afterwards, so each one is marked unverified rather than verified.
- A copy of the audit seals kept outside Xyranik. Each closed day of entries is hashed and chained to the day before, so a row edited or removed afterwards stops matching. But the seals are held in the same database as the log, so somebody able to rewrite one could rewrite the other. A copy kept where the application cannot reach it is what would close that, and there is not one yet. This is evidence of tampering after the fact, not prevention.
- Backup codes for two-factor sign-in. Two-factor sign-in itself is available and enforced on the server. What is missing is a way back in after losing the device holding your authenticator: keep a second device, or contact us.
- Requiring two-factor sign-in for everyone in an organisation. Each person turns it on for themselves. There is no organisation-wide requirement and no switch that claims one — a switch that claimed to enforce something the server did not check would be worse than not offering it.
- Single sign-on over SAML. OpenID Connect is supported.
- Choosing the region your data is kept in. One deployment serves every workspace.
- Encrypting your credentials under your own key service. Such as AWS KMS, Google Cloud KMS or Azure Key Vault.
Questions, or a problem to report
Email support@xyranik.com. If you have an account, you can also write to us from the Help centre once you are signed in.