Agent trust layer
The keys you connect are sealed before they are stored
Connecting a store or an ad account means handing over a key that can spend money. What matters is not that it is "encrypted" but what happens when the key protecting it has to change — and whether a misconfiguration fails loudly or quietly.
14-day evaluation · no card · start before you connect anything
Every request passes through, in order
- 01Agent identity
- 02Permissions and policy
- 03Risk and approvals
- 04Action gateway
- 05Tenant isolation
- 06Prompt-injection defence
- 07Credential protectionYou are here
- 08Audit and decision ledger
- 09Kill switch
Uncertainty at any step resolves to a refusal or to asking a person — never to proceeding.
How a request is decided
- 01A fresh key per credential, wrapped by the deployment keyEach credential is sealed with its own data key, which is then wrapped by the deployment key and labelled with that key’s fingerprint. Nothing is encrypted directly under one long-lived secret.
- 02Which is what makes rotation possibleMove the current key aside and set a new one: new credentials are written under the new key, existing ones still read, and each can be moved across by rewrapping its data key — the credential itself is never re-encrypted. Before this, changing the key would have broken every stored credential at once.
- 03A missing key stops the deployment, loudlyThere is deliberately no fallback secret. A missing or too-short key throws at startup rather than quietly encrypting every customer’s API keys under a constant committed to the repository, which is the failure that would never be noticed.
- 04Reading tolerates the past; writing never produces itValues stored before any of this existed still read, told apart by their shape rather than by attempting a decrypt and catching the failure — because a corrupt envelope mistaken for plain text would be sent to a provider as a key. A build check fails if a new writer stores a raw value.
One stored credential
Example
- What you connected
- An ad account access token
- Sealed with
- A data key made for this credential alone
- That key wrapped by
- The deployment key, named by its fingerprint
- Shown again afterwards
- Never — not by us, not from the database
There is no fallback secret. A missing key stops the deployment rather than quietly encrypting every workspace’s keys under a constant in the source.
Rotation rewraps the data key only — the credential itself is never re-encrypted, and old credentials keep reading while new ones are written under the new key.
What this guarantees
API tokens are stored as a one-way hash
A token you create cannot be shown again, by us or by anybody who reaches the database. Tokens can be revoked at once, or replaced with an overlap so nothing breaks mid-change.
Secrets are stripped from what is kept and shown
Platform error messages routinely quote the credential they rejected. What is stored on a connection, shown on a page and handed to an agent has it removed, and error reports leaving Xyranik have cookies, bodies, auth headers, keys, addresses and phone numbers taken out first.
Webhook signing secrets rotate with an overlap
Both secrets sign during the change, so your endpoint keeps verifying deliveries while you move across rather than having to cut over in one step.
What it cannot defend against
Said plainly. A control whose edges are hidden is worse than no control at all.
No customer-managed keys yet
The envelope format supports wrapping a data key with a key service you control, and no such provider is registered — so in practice every credential is wrapped by our deployment key. AWS KMS, Google Cloud KMS and Azure Key Vault are not available, and the security page lists that among what is not in place.
Credentials stored before September 2026 may still be plain text
Ad-platform tokens and webhook secrets written before sealing existed are read as they are until a migration converts them. Nothing is broken by that and nothing new is written unsealed, but the conversion is an operator action rather than something that has already happened everywhere.
Every control, and what is not built
The security page lists each control as something you can check in the product, and lists separately what is not in place — including that Xyranik holds no certification and has had no external audit.