Why ObjectExplorer?

Where the day goes

Six things, on repeat, in every team that keeps its data in a bucket:

• Download it to see it. A 5 GB Parquet file, a zip you only wanted the file list of, one column you meant to check — each becomes a copy on a laptop, and the copy outlives the question.
• A console per provider. S3 in one tab, Cloud Storage in another, Blob in a third, each with its own idea of what a folder is and its own way of showing you nothing about the file.
• Handing data to a viewer. The quick way to read an unusual format is often to upload it somewhere, which is exactly what data you are not allowed to copy forbids.
• Partitions you navigate by hand. year=2026/month=01/day=15 is a table, but a console reads it as three thousand folders.
• pandas for a minimum and a maximum. Loading a whole file into a notebook to answer a question the file's own footer already knows.
• Click, wait, reload. Every step through a console is a page load, and a page load is where attention goes.

The loop it removes

A cloud console can list your objects and little else. To find out what is actually inside a Parquet file you download it, open a notebook, read it, and delete the copy — for one look at one file. Do that across three providers and you are also juggling three consoles, three sets of credentials, and a Downloads folder full of data that should never have left the bucket.

ObjectExplorer collapses that loop:

• One window for every provider. S3 and S3 compatible storage, GCS, Azure Blob, OneLake, Google Drive, OneDrive, Dropbox, Box and your local disks in the same tree, with the same keyboard shortcuts.
• Preview instead of download. Formats render in place — including the ones no console will ever open, like Parquet, SPSS and SAS.
• Search across buckets. One query over local folders and cloud prefixes at the same time.
• Query, chart and model in place. A table opens as a notebook: SQL over the object, a chart of what came back, and a gradient boosting model over the rows — all on your machine.
• Delta, Iceberg and Hudi are just tables. Open the folder and it answers in SQL, deletes and schema changes included.
• Move things where they belong. Copy, move, rename and delete across buckets and disks, with one Undo — the explorer half of a file explorer, not only the reading half.

And now the agent has the same day

Everything above is just as true when the one doing it is an agent, except that an agent cannot see that a file is a sas7bdat and give up. It downloads. It writes a script. It pulls a whole column into a context window you are paying for, and it does it with a credential someone had to hand it.

Point it at this app instead:

• It never holds a credential, and never talks to a provider. It asks here, and here decides.
• It reaches only what you ticked — one list of roots, one deny list that holds in every root.
• PII is rewritten on the way out, by rules you wrote once: hash, mask, FPE or drop, on a column name or on what a value says. The same rules hold over a share link you send a person.
• Every call is written down before the answer leaves, watchable live in the window and replayable afterwards.
• Limits cap what it can take, per call, per session and per day — which is a security number and a token-cost number at the same time.
• It can read your formats. Parquet, SPSS, SAS, Delta, Iceberg, Hudi — the agent asks in SQL and gets rows, instead of writing a parser.

That is ObjectExplorer for agents.

The part that decides it

Most tools that can read a Parquet file in a bucket read it somewhere else. ObjectExplorer reads it here. Objects are fetched from your provider to your computer and nowhere else, every reader runs on your own machine, and credentials never leave it.

That is what makes it usable on data you are not allowed to copy — and it means there is no data-processing agreement to negotiate before anyone can look at a bucket. The whole argument, and what exactly does leave the machine, is on your data stays here.

Next: how it works.