Security
You stay in control.
Vrot does not get unlimited access to your business.
You choose which applications it connects to, what it may do inside each one, and which actions have to wait for a person. Everything it does is recorded. This page explains how that works — and, at the end, what we deliberately do not claim.
The five parts
Built around control, permissions and verification.
Not a policy page. These are the mechanisms the product is built from.
Scoped access
Each connection is limited to the permissions you grant. A worker can only reach the applications it was given, using the capabilities you allowed.
An application you never connect stays disconnected, and a worker cannot reach past the connections attached to it.
Approval policies
You decide which actions run automatically and which wait for a person. Anything above your threshold pauses until it is approved.
You can change which actions need approval at any time, and a paused action stays paused until a person decides.
Encrypted credentials
Connection credentials are stored encrypted. Vrot authorises through each provider’s own sign-in rather than asking for passwords.
Where a provider supports OAuth, Vrot holds a revocable token instead of a password, so access can be ended from the provider’s own settings.
Audit history
Every action a worker takes is recorded — what ran, when, which integration it used and what the result was.
The record covers the runs that worked as well as the ones that did not, so you can check what happened instead of assuming it.
Action verification
Vrot checks that an action actually produced the result it expected, rather than assuming the request succeeded.
If a check does not pass, the run does not carry on as though it had.
Permissions
What you decide.
A connection is not a blank cheque. Each one is granted capability by capability, and what you leave out stays out.
Connect Gmail so a worker can read enquiries and prepare replies, and it can do exactly that. If deleting mail is not part of the job, it is not part of the connection — so it is not something the worker can do by mistake, or be talked into doing by the contents of an email.
Permissions can be changed after a worker is running. Removing a capability takes effect for the next run, not just for new workers.
- Read emailsPermission granted in this example
- Create draftsPermission granted in this example
- Send emailsPermission granted in this example
- Delete emailsPermission withheld in this example
Approvals
When Vrot asks first.
You choose which actions run on their own and which ones need a person. Anything above your threshold waits.
Most of the work a worker does is routine: reading, checking, filing, drafting. Those steps can run without interrupting anyone. The steps that spend money, send something outward or cannot be taken back are the ones worth stopping for — and you decide where that line sits.
While an action is waiting, nothing happens. It does not time out into a decision, and it does not proceed because no one answered. It stays paused until someone approves or rejects it, and the outcome is written to the audit history either way.
Action waiting
Refund $850
Above the approval threshold set for this worker. Nothing is sent, and nothing changes, until a person decides.
Connections
How connections work.
Vrot authorises through each provider’s own sign-in. It does not hold a key to your business that only we can take back.
01
You authorise it
A connection starts in the Vrot desktop app and hands off to the provider’s own sign-in page. Where the provider supports OAuth, you approve the connection there and Vrot receives a token — it never asks you for the password itself.
02
Credentials are stored encrypted
The credential behind a connection is held encrypted rather than in plain text, and it is used only to reach the application it belongs to.
03
A worker reaches only what it was given
Connections are attached to workers deliberately. A worker without a connection to an application has no route to it, whatever it is asked to do.
04
You can revoke it at the provider
Access does not depend on us letting go of it. Removing Vrot in the provider’s own security or connected-apps settings ends the connection from their side.
Not every provider offers OAuth
A small number of integrations use an API key pair issued by the vendor instead. WooCommerce is the real example: you generate a key and secret inside your own store, paste them into the Vrot app, and they are stored encrypted on your machine. Revoking that key in WooCommerce ends the connection in the same way removing an OAuth authorisation does.
Each integration page lists exactly how that connection is authorised, so you can check before you connect anything.
Failure handling
When something goes wrong.
Things do go wrong: a provider has an outage, a record is not where it was expected, a document is unreadable. What matters is what happens next.
It checks the result
After an action, Vrot looks at what actually happened rather than assuming the request went through. A step that cannot be confirmed is treated as unfinished, not done.
It retries what is safe to retry
Some failures are transient — a provider is briefly unavailable, a request times out. Vrot retries safe operations where retrying cannot cause a duplicate or a second send.
It stops and tells a person
When a step cannot be completed or verified, the run stops and raises it for a person, with the audit history of what led there. Silence is not treated as success.
This is designed behaviour, not a guarantee. No system can promise it will never fail; the point of verification, retries and audit history is that a failure is visible and recoverable rather than quiet.
Honesty
What we don’t claim.
Security pages are usually a wall of logos. Here is the part most of them leave out.
- This page describes how the product is designed to work. It is a description of design, not a certificate, and it is not an audit.
- Vrot does not display compliance certifications it has not completed. There are no borrowed badges on this page, because a badge is only worth the audit behind it.
- We do not publish uptime figures, customer counts or test results we cannot stand behind. When those exist and hold up, they will appear here with the detail that makes them checkable.
- No automation removes risk entirely. Approval policies and audit history exist precisely because the honest answer to a sensitive action is a person, not a promise.
If a security review is part of how you buy software, write to support@vrot.ai and we will tell you plainly what is in place today and what is not. A straight answer is more useful to you than a badge, and easier for us to keep true.
Set the boundaries. Then let it work.
Install Vrot, connect one application, and give it exactly as much room as the job needs.
Windows application