What we can see, and what we cannot
September 2026 · 9 min read · Mayur
If you are considering connecting your storage to a tool made by a company you have never heard of, run by two people, you should want a straight answer to one question: what can they actually do with this access, and what happens if they turn out to be careless?
This is that answer. It includes the parts that are not flattering.
The short version
We hold credentials, not files.
Your objects stay in the cloud accounts you already have. They never move into storage we own. When a file passes through us, during a download or a cross-cloud copy, it passes through and we do not keep a copy.
That is not a policy we could change on a whim. It is the architecture. We are a control plane, which in plain terms means we are the steering wheel for machines we do not own. There is nowhere for us to put your files even if we wanted to, with one exception I will name below rather than hide.
How the access works
Two mechanisms, and one is meaningfully safer than the other.
The better one: IAM role (AWS)
On AWS you do not have to give us a key at all.
You create an IAM role in your own account, and you say that our AWS account is allowed to assume it. When we need to act, we ask AWS for a temporary credential, AWS checks your policy, and hands us one that expires on its own within the hour.
Nothing permanent leaves your account. There is no long-lived secret of yours sitting in our database, because there is no secret. You set the permissions, you can scope the role to specific buckets, and you can delete the trust relationship at any moment, at which point we are locked out immediately with no action required from us.
If you are on AWS, use this. It is strictly better and it takes about the same time to set up as pasting keys.
The other one: access keys
Other providers do not all offer an equivalent, so for those you paste an access key pair.
Those credentials are encrypted at rest with AES-256-GCM, using a key derived per user via HKDF. In plain terms: your credentials are not stored as readable text, and they are not all encrypted with one shared master secret. Each user's credentials are scrambled with something tied to that user.
That last part is the one that matters. It means a problem with one customer's data cannot open another customer's storage, because there is no master key that opens everything.
Our recommendation, in every guide we write: create a scoped key rather than an admin key. Give it access to the specific buckets you want to manage and nothing else. If you would not be comfortable with what a key can do in the worst case, scope it down until you would be.
You can revoke any key at your provider at any time. We are locked out the same instant. You never had to trust us not to leave, because you kept the power to throw us out the whole time.
What we can do
Only while you are actively using the product, and only what your credential permits:
- List the objects in the buckets you connected
- Read, upload, move, copy, or delete an object when you click to, because we are acting as you, with your credential
- Read and change bucket configuration (lifecycle, CORS, versioning, policy) when you ask us to
- Store object names and metadata in our search index, if you use search
That last one deserves its own sentence, because it is the one thing about your data that does live on our side. To make search across millions of objects fast, we index filenames and metadata in our database. Not contents. Filenames can be sensitive, and if yours are, you should know this before you turn search on.
What we cannot do
- We do not keep your files. An object we touch during a transfer is held for as long as it takes to hand it on, and then it is gone.
- We cannot reach buckets you did not connect. The credential opens what you pointed it at.
- We cannot use one customer's credentials to reach another's storage. Separate derivation, no shared master key.
- We cannot act when you are not asking us to, other than scheduled jobs you configured yourself.
The one exception, said out loud
There is exactly one case where files do sit on storage we run: managed buckets. That is an optional add-on where you ask us to provision and operate a bucket for you, so you do not have to hold an account with a provider at all.
In that one case, the data is on infrastructure we set up. It is still your data and you chose the arrangement deliberately, but "your files never live with us" is not true for managed buckets and I am not going to write a security page that quietly omits it.
By default, and unless you go and turn it on, it does not apply to you.
What we do not have
This is the section most vendor security pages leave out.
We do not have SOC 2. It is on the roadmap. It is not done. If your procurement process requires a SOC 2 report, we will fail that requirement today and I would rather you found that out here than three weeks into an evaluation.
We do not have a published SLA outside Enterprise agreements.
We do not have a third-party penetration test to show you yet.
We are two people. Country Devs is Mayur and Surya. There is no security team, because there is no team. What there is instead is a small enough system that both of us understand all of it, which is a genuine advantage and not the same thing as a compliance programme.
We have not been audited by anyone. Everything on this page is us describing our own architecture. You should weigh it accordingly, and you should weigh the fact that we told you so.
The question underneath the question
What people usually mean by "is it safe" is: what is my exposure if you turn out to be bad at this?
Here is the honest shape of that exposure.
Worst realistic case: someone compromises our systems and obtains encrypted credentials. Because derivation is per user, they do not get a master key that opens every customer. To use any credential they would need to break the encryption for that specific user. Meanwhile you can revoke every key at your provider in minutes and end the exposure entirely. If you used IAM-role connect, there is no stored credential to steal in the first place.
What you lose if we disappear tomorrow: nothing. Your data is in your own cloud accounts, untouched, and you go back to using the provider consoles. That is the property that makes bring-your-own-storage worth choosing regardless of what you think of us. We are not holding anything hostage because there is nothing for us to hold.
What you should do to limit exposure regardless: use IAM-role connect on AWS. Use scoped keys everywhere else. Do not connect a bucket you would not be comfortable connecting to any third party. Turn on your provider's own access logging, so you have a record independent of ours. These are good practices with any vendor and we would rather you followed them with us.
Questions people actually ask
Do you store my files? No, other than the managed buckets add-on described above, which you have to deliberately choose.
Do you store my access keys? Yes, encrypted with AES-256-GCM using per-user derived keys, for providers where key-based access is the only option. On AWS you can avoid this entirely with IAM-role connect.
Can your employees see my data? There are two of us and we do not have a mechanism to browse customer objects. The genuine limiting factor is architectural: we do not store your files, so there is nothing sitting there to browse. Object names in the search index are a different matter and are covered above.
What happens if I stop paying? Your data is unaffected because it was never ours. You lose access to the console, not to your storage.
Are you GDPR compliant? We process credentials and object metadata for EU customers under our data processing terms. We are not going to claim more than that on a blog post; ask us and we will answer specifically.
Can I use this in a regulated environment? Business tier has object lock, audit logs, and roles. Enterprise adds SSO and data residency. Whether that satisfies your specific regulator is a question for your compliance team, and if they need SOC 2 the answer today is no.
Why should I believe any of this? You should not, purely on our say-so. What you can verify independently: revoke a key at your provider and confirm we lose access. Use IAM-role connect and confirm no key ever left your account. Turn on your provider's access logging and see exactly what we do. Those checks do not require trusting us at all, which is the point.
If you are on AWS, IAM-role connect takes about five minutes and means no credential of yours is ever stored anywhere but AWS. The connect guide is here.