Connecting Okum means handing over an n8n API key, and an n8n API key is control of your server. This page explains exactly what happens to it — including the parts that are still on the list.
Last updated: 30 July 2026
The key is encrypted with AES-256-GCM before it is written to the database, using an encryption secret held outside the database in the server environment. Each key gets its own random initialisation vector. The plaintext key is never stored.
Decryption happens only inside Okum's server-side functions, at the moment a request to your n8n instance is made. The key is never returned to the browser — which is why the API key field in Okum stays blank once you have saved one, rather than showing you the value back.
What Okum does with that key:
All of these are actions you trigger. Okum does not modify workflows you did not deploy through it.
Okum never stores your clients' OAuth tokens. When a client connects Google, Slack or anything else, that authorisation lives in n8n's own credential store, where it always did. Okum has no copy.
This is an architectural decision, not an oversight, and it has a real cost: it means Okum cannot actively test whether a client's token is still alive. It has to infer that from what execution errors reveal. We accepted a weaker signal in exchange for not becoming a place where a breach would expose every client's connected account.
Okum also never sees:
Failure classification reads the error text n8n produces. If a workflow writes sensitive values into an error message, that text is stored as part of the execution record. Okum does not read the data your workflows process.
Okum is built and run by one person. It has no SOC 2 report, no ISO certification, and has not had an external penetration test. Anyone telling you otherwise about a product this young is worth doubting.
There is also no published uptime status page yet, and no automated data export in the app. Both are on the list. Until then, ask and it will be done by hand.
One more thing worth being plain about: because Okum's own functions must be able to decrypt your key to call n8n, an attacker who compromised both the database and the server environment could reach it. Encryption at rest protects against a leaked database or backup, not against a total compromise. No provider's architecture is different here — some are just less specific about it.
Email ashimdoley3@gmail.com from your account address and your account, stored keys, client records and execution history are deleted. Deleting your Okum account does not touch anything on your n8n server — workflows already deployed there keep running, and any credentials in n8n stay in n8n. You can revoke Okum's access at any time by deleting the API key inside n8n, without contacting anyone.
Email ashimdoley3@gmail.com with "security" in the subject. Reports are read personally and acknowledged within 72 hours. There is no bug bounty programme, but genuine findings will be credited if you want that.