Security and control
Mechanisms you can point at.
Proxy holds other organisations' documents, sends messages over their names and records what was done. This page describes how that is constrained, in terms of things the platform does rather than adjectives about how seriously we take it.
- Isolation
- Enforced during route resolution, before application code
- Actor
- Required on every mutating operation
- Claims
- No certification is claimed on this site
Eight controls, and how each one is enforced.
The line under each control is the part that matters: not what the control is for, but what actually stops the thing it is meant to stop.
Isolation is structural
Every record belongs to one organisation. A request carrying another organisation's identifier is refused while the route is still being resolved, before a line of application code runs.
The answer is 404, not 403, because a 403 would confirm the record exists.
A scope narrows. It never grants
An integration holds scopes, and its effective permission is the intersection of those scopes with what its owner can already do. A credential cannot be configured into an authority nobody has.
Entitlement is asked separately, on every request, from the scope itself.
Three credentials, three jobs
A publishable key identifies your integration in a browser and reads nothing. A secret key works server to server. A client session is minted by your backend for one capability, one resource and a few minutes.
Credentials never appear in logs, exception messages or webhook payloads.
Every mutation has a named actor
The actor is not optional and not derived. It is written to the audit trail and onto the record itself, so the question "who did this, and when" has an answer that does not depend on log retention.
The same authorisation model serves the API and the web interface.
Encrypted in transit and at rest
Transport is TLS with no plaintext fallback. Objects are encrypted at rest by the storage provider, and signing traffic runs on its own host with cross-origin access closed rather than configured.
Allowed origins are an allowlist per integration, not a wildcard.
Retention is yours to set
Storage class and retention are explicit per object, across six classes from standard to deep archive. Deletion stays reversible for a defined window, and then it does not.
Every size and lifecycle change is a ledger event, not a recalculated total.
You can see what you spent
Each metered operation writes a usage record with the operation key, the quantity, the billing unit and the cost. Free operations are recorded in full rather than dropped, so the count is always there.
Usage is readable without buying anything: nobody is charged to see a bill.
Delivery is a record, not a hope
Webhook events carry a status through pending, processed, failed or ignored. Retries are recorded. A signature is validated server-side and the verdict is kept with the signature.
A replayed request answers 200 with Idempotency-Replayed: true.
Evidence is produced, not reconstructed.
Four artefacts, written as the work happens. None of them is assembled later from application logs, which is the arrangement that fails an audit six months after the log retention window closed.
GET /api/v1/audit?resource=01k5m7z4…
{
"data": [
{
"event": "storage.object.created",
"resource": "01k5m7z4h9c1e8ptw2yb3rkq5d",
"actor": { "type": "integration", "name": "Claims portal" },
"recorded_at": "2026-08-14T09:40:58+00:00"
},
{
"event": "processor.job.completed",
"resource": "01k5m8f2r7q0x3v9tzcd4npb6h",
"usage": { "operation": "ocr.document", "quantity": 1, "status": "charged" },
"recorded_at": "2026-08-14T09:41:07+00:00"
}
]
}
The actor is on the record, not only in a log line. A usage record carries the operation, the quantity and whether it was charged, so a bill can be explained against the work that produced it.
Audit trail
The event, the resource, the named actor and the time it was recorded.
On every mutation, by every service.
Usage ledger
The operation key, the quantity, the billing unit, the cost and the status.
On every metered operation, charged or free.
Delivery record
The outcome, the attempt history, and whether a retry has been made.
On every message sent and every webhook attempted.
Signature validation
The server-side verdict, kept with the signature it belongs to.
On every signature submitted for capture.
Retention is a decision you make per object.
Storage class is explicit rather than inferred, because how long something has to be kept is a legal question about your business and not a usage pattern. Deletion stays reversible for a defined window, and then it does not.
Every size and lifecycle change is a ledger event rather than a recalculated total, so a figure on an invoice can be traced to the events that produced it.
- standard
- Standard. Working documents, read often.
- standard_ia
- Standard infrequent access. Closed matters still occasionally opened.
- intelligent_tiering
- Intelligent tiering. Mixed access patterns you would rather not predict.
- glacier_instant
- Glacier instant. Archive that must still open immediately.
- glacier_flexible
- Glacier flexible. Archive where minutes to hours is acceptable.
- deep_archive
- Deep archive. Long retention obligations, rarely read.
Where the data is, and who else touches it.
Both answers are agreed for your organisation before anything is stored, and both are written down rather than described.
Region is an account-level setting
The region is fixed for your organisation rather than chosen per request, so it cannot drift as integrations are added or as a new team starts calling the API. Changing it is a migration, and it is treated as one.
Subprocessors are named
Proxy runs on infrastructure and uses providers for object storage, payments, delivery and identity checks. The current list, with what each one processes, is provided with your data processing terms and updated when it changes.
Encryption
Transport is TLS with no plaintext fallback. Objects are encrypted at rest by the storage provider. Signing traffic runs on its own host with cross-origin access closed rather than configured.
Reporting something
If you believe you have found a vulnerability, report it through the contact form, saying that it is a security report and giving enough detail to reproduce it. We will confirm receipt, and we will not pursue anybody who reports in good faith and does not access other organisations' data.
What this page does not claim.
A security page that claims everything is worth nothing, so this one names what is absent. If any of these become facts they will appear here with a date attached.
- Certifications
- No certification is claimed anywhere on this site. When a certificate exists it will be named, dated and available to read, and not before.
- Uptime figures
- Availability commitments belong in a service agreement for your organisation, not in a number on a marketing page.
- Customer names
- Proxy handles other organisations' documents. We do not publish who they are, and a reference call is arranged with permission or not at all.
- Benchmarks
- Extraction accuracy depends entirely on your documents. We would rather run your sample and show you that result than quote somebody else's.
Send us your security questionnaire.
We would rather answer a long list of specific questions than publish a short list of comfortable ones. Ask for the data processing terms and the subprocessor list at the same time.
- Isolation
- Per organisation, enforced in the router
- Access
- Scopes narrow a person's permissions, never widen them
- Evidence
- Audit trail, usage ledger, delivery record, signature verdict