S3-compatible storage
Object storage is where the files end up — archives, exports, scanned records, attachments. Useful when something needs retrieving, invisible the rest of the time.
Object storage is where the files end up — archives, exports, scanned records, attachments. Useful when something needs retrieving, invisible the rest of the time.
What S3-compatible storage holds, and why that matters here
S3-compatible object storage holds files at scale: document archives, system exports, scanned records, media and attachments. It is designed for durability and volume rather than for browsing, which means retrieval usually goes through an application or a technical request.
For an assistant, the relevant case is retrieval of a specific document on request — a historical record, an archived statement, a scanned file — where the alternative is a manual search.
- Document archives — historical records retained for compliance.
- Scanned material — digitised paper records.
- Exports and reports — generated files kept for reference.
- Attachments — files associated with records in other systems.
- Metadata — the tags and keys that make retrieval possible.
Questions Elbi can answer from your object storage
Can I get a copy of that?
Retrieving an archived document on request.
Where is the record from that year?
Historical retrieval that would otherwise be manual.
Is the scan available?
Whether a digitised record exists for a reference.
What files are attached?
Associated documents for a record.
Can you send me the statement?
Providing a stored document to an identified customer.
Does an archive exist for this?
Existence, which resolves a question without retrieval at all.
How Elbi retrieves from S3-compatible storage
- An access key issued for one purposeYour team creates a dedicated identity on the store — an IAM user or role on Amazon S3; a user or service account on MinIO, Ceph or a similar self-hosted store — and issues its access key pair for this connection alone.
- Read rights on named buckets and prefixesIts policy allows listing and reading objects under the prefixes you name, such as statements/ or archive/scans/, and nothing more: no uploads, no deletes, and no reach into buckets that are not on the list.
- Finding an object is a key lookup, not a searchObject stores do not search inside files. A request for "the March statement for this account" becomes a listing under a prefix built from the account reference and the period, which only works if your key naming follows a pattern. Where it does not, object metadata or tags can carry the reference instead.
- Entitlement is settled before anything is fetchedThe person asking is identified through your own sign-in, and the reference they ask about is checked against what they are entitled to before the object is retrieved. Archived documents are often more sensitive than live ones, so this check comes first rather than after the file has been found.
- The document is read, not keptA fetched PDF or scan is handled the same way as a file uploaded in a conversation: read to answer or fulfil the request, scans included, and not written to disk on our side. The object in your bucket is untouched.
- Versions and locked objects stay as they areIf the bucket keeps object versions or uses object lock for retention, reading the current version changes neither. Reading earlier versions needs its own permission (s3:GetObjectVersion on Amazon S3), so whether history is in scope is an explicit decision rather than a side effect.
Scope and control at bucket and prefix level
| Direction of access | List and read only, on named buckets and prefixes. There are no put, delete or policy-changing permissions, so the connection cannot alter the archive — which matters most where the archive is your evidence. |
|---|---|
| Who can see what | The key's policy decides which prefixes can be reached at all; the asker's identity decides which documents within them they may receive. A customer can be given their own statement without being given anyone else's. |
| Credentials | An access key pair you issue to a dedicated identity. You rotate or delete it on the store, from your side, and the connection stops without any involvement from us. |
| Where data goes | Retrieved documents are read to answer or fulfil the request and are not written to disk. Message content is destroyed within 24 hours, generally when the conversation ends, and no external AI service is involved at any point. |
| Audit | Object reads can be logged on the store itself: server access logs or CloudTrail data events on Amazon S3 and audit logging on self-hosted stores such as MinIO. Enable it for the buckets in scope and the record of what was fetched sits with you. |
| If it is unavailable | If the store cannot be reached, the key has been revoked, or the object is not where its reference says it should be, the assistant says so and passes the request to a person. It does not offer a similar-looking document in its place. |
What the object storage connection replaces
Archive retrieval is a slow, manual, low-value task that occupies real staff time in document-heavy organisations. Requests arrive, someone searches, a file is sent, and nothing about the process required judgement.
An assistant that can locate and provide a document against a reference removes that task entirely — provided entitlement is established first, because archived documents are frequently more sensitive than live ones.
The prerequisite is metadata. Object storage retrieval is only as good as the keys and tags applied when files were written, and deployments frequently discover that the archive is less navigable than assumed. That discovery is itself useful.
Where archive retrieval matters most
Banking
Historical statements and records.
Government
Archived case documents.
Healthcare
Digitised records where entitlement is strictly controlled.
Legal and compliance
Retained documents required for review.
Getting value from an object store
The value sits in requests that currently wait for someone to go and look: a copy of an old statement, a scanned form, the attachment from a closed case. Count those for a few weeks and note which follow a pattern — the same prefix, the same kind of reference. Those are the ones to connect first.
Key naming decides almost everything. An archive written as reference, then year, then document type can be navigated directly; one written as opaque identifiers needs metadata, or a lookup table kept somewhere else, before any assistant can find anything in it.
Scans are the other variable. A PDF with a text layer is read directly; an image-only scan has to be recognised first, and faint copies of older paper give weaker answers. Deciding which document types the assistant will read, and which it will only fetch for a person to handle, avoids promising more than the archive can support.
What connecting S3-compatible storage involves
- Inventory the buckets and prefixesList which buckets hold what, which prefixes the recurring requests touch, and which of them contain personal data. Archives often have folders nobody can explain; those stay out of scope until someone can.
- Write the policyAllow listing and reading on the named prefixes only. Many S3-compatible stores accept AWS-style policies, but the conditions they honour differ by product, so test the ones you rely on rather than assuming them.
- Issue the keyCreate the identity and its access key pair on your side and hand it over through a channel you agree. Record an owner and a rotation date at the same time.
- Agree the reference patternSettle how a person's request maps to a key or metadata lookup: which reference, which date, which document type. This is where most of the deployment effort goes, and where undocumented conventions come to light.
- Rehearse missing and ambiguous documentsTry references that do not exist, periods with two matching files, and scans too poor to read. Decide in advance what the assistant says in each case, and who the request goes to.
- Open one prefix firstStart with a single, well-organised prefix and one kind of request, and add further prefixes once that one is answering dependably.
Archived personal data, and where the bucket lives
Archives are where personal data accumulates quietly: statements, identity documents, medical forms, signed contracts. Under the Saudi Personal Data Protection Law each needs a purpose for being read, and the retention rules that applied when a file was archived still apply when it is retrieved. A prefix full of documents that should already have been deleted is a problem to solve before connecting, not after.
Where the data lives is decided by where your store runs. S3-compatible storage is often self-hosted, or taken from a provider in a location you chose, so residency is usually a decision already made; record it next to the bucket list so a reviewer sees both together.
The strongest evidence you can offer is the store's own read log set against the policy. Between them they show what could be fetched and what actually was.
What organisations typically see
How document archives are searched elsewhere
On AWS, the managed route is to index a bucket into a search or assistant service: Amazon Kendra and Amazon Q Business both offer S3 connectors that crawl documents into an index of their own. That suits large, stable collections, and it means a second copy of the content with its own permissions to keep in step.
Self-hosted stores usually come with a web console, MinIO's for instance, where technical staff can browse buckets. It is a tool for administrators rather than something to give a customer or a front-line employee.
Many organisations put a document management system in front of the archive, with its own search and access model. Where one exists and already holds the entitlement rules, it may be the better thing to connect to than the bucket underneath.
The recurring failure is a key with more reach than intended: a policy on the whole bucket, or on every bucket, because prefixes were fiddly to write. An archive key with write or delete rights is worse still, because it turns a retrieval tool into a way to damage the record.
Common questions about the object storage connection
No. Retrieval is bounded by entitlement, and archived documents are frequently more sensitive than live ones.
A common discovery. Retrieval quality depends on it, and the audit is itself valuable.
Yes, including scans — the same document handling as any uploaded file.
No. A retrieved document is read to answer or fulfil the request and is not written to disk on our side. The original stays in your bucket, and the key that fetched it is yours to revoke.
That is the point of S3 compatibility: stores that implement the S3 API, self-hosted or from another provider, can be connected the same way. Compatibility varies at the edges — policy conditions, versioning, object lock — so those are checked against your product during deployment.
No. The key is limited to listing and reading. An archive is a record, and a retrieval tool that could change it would be a liability rather than a convenience.
Connect it to your own systems
A working assistant against your own records, in both languages.