Every request goes through our own server, over an authenticated session. There is no client-side path into the database at all, so there is no client-side path around it either.
Row-level security in the database is the primary control, not a backstop. Every table that holds your records enforces which workspace can see which row, evaluated on every query, not just at the API layer.
Direct, elevated database access exists only for a short, documented list of exceptions, such as provisioning a new workspace or applying a billing update, and every one of those checks the session first, checks explicit authorization second, and writes an audit record.
You sign in once, and the session is held in an httpOnly cookie your browser cannot hand to a script. There is no local-storage token to steal.
Every request between your browser and Engrama travels over HTTPS. The application also tells your browser never to fall back to an unencrypted connection to Engrama or to any of its subdomains, so a downgrade is refused by the browser itself.
Your records and files sit in a Postgres database and object storage managed by Supabase, which itself runs on AWS. Encryption at rest is Supabase’s, not something Engrama layers on top of it.
Sign-in works three ways: email and password, or continuing with Google or Microsoft. Every method lands you in the same server-side, httpOnly session described above.
There is no SAML or enterprise SSO integration today.
Every document is delivered through a link that expires in minutes, minted only after we re-check that you are signed in and that the record is one you are allowed to see. Nobody, including someone who guesses or intercepts a link, gets a permanent path to it.
Opening a document lands in the same access log described in section 06.
A partner opens a page that holds only the request you sent them: what you asked for, and a place to answer it. They do not see your other partners, your other requests, or anything else in your workspace.
No account, no password, and nothing for you to set up.
Northgate Group asked you for one record
Ridgeway Logistics · this link is yours, there is nothing to sign in to.
Certificate of Insurance, general liability
Site works contract NG-2026-114 · policy year 2026
Needed by Friday, 30 January18 days left
Northgate sees the record you send and nothing else here.
The same four things sit behind every record in Engrama:
Engrama does not use write-once storage or cryptographic timestamping today. The mechanisms above are what enforce integrity.
Operating License
CurrentHeld by Northgate Services
Engrama proposes. A person approves. The trail records who decided and when.
When a check runs against a record you asked for, it reads the record, flags what does not match what you declared, and cites the line it came from.
Two checks need you
Checks read the document. They do not check the issuer's register or test the part.
The database is backed up daily by Supabase, which runs on AWS, and a row deleted from the database ages out of those backups rather than sitting in them indefinitely.
Those backups cover the database. Objects in file storage are not part of them.
Every change reaches production as a pull request. Typechecking, linting and the test suites run on it automatically, and a failure blocks the merge rather than raising a warning.
Dependencies are audited automatically whenever the lockfile changes and again every week on a schedule. A high or critical advisory fails the check and blocks the merge, the same way a failed test does.
It runs alongside the same pull-request gates described in the item above.
Your records are kept for as long as your workspace is active. If you terminate, you can ask us for an export within 30 days, and the workspace is deleted after that window.
Audit records are the one thing that outlives the workspace they describe. A deleted workspace with no record of what happened inside it is not an auditable one.
The full picture, data class by data class, is what the privacy policy is built on.
Your records and files sit in a Postgres database and file storage managed by Supabase, which runs on AWS. The application is served by Vercel, and the worker that processes uploaded documents at ingestion time runs in a separate AWS account that Engrama operates directly.
The full, current list of subprocessors lives on the subprocessors page, and that page is the one we keep current.
Engrama runs on managed cloud platforms rather than on hardware we operate, so the physical and environmental controls at that layer are the platform’s and sit inside its own audits.
Engrama runs only as a managed cloud service that we operate. There is no self-hosted, on-premises, or private-cloud deployment option today.
We are running a SOC 2 and ISO 27001 program today.
We do not have a completed certification yet. If you need a signed attestation or a report today, ask us directly and we will tell you exactly where the program stands.
Send security reports to info@innovedgelabs.com rather than to a public issue tracker. We acknowledge a report within two business days and give a status update within five.
Good-faith research has safe harbor. We do not pursue researchers who avoid privacy violations and data destruction, work only against accounts they own, and give us a reasonable window to fix an issue before disclosing it. Public disclosure is coordinated with the reporter once a fix ships, typically within 90 days of the report.
Security questions reach a person at info@innovedgelabs.com.
