Data stays on the installation’s server. Access goes through roles.
Eyeward runs entirely on one server: the database, files, search, mail, chat and the office editor. Below: what that server is made of, what leaves it and why, how sign-in, roles and tokens work — and how secrets are stored.
Diagram: a browser, the Eyeward Sync client and AI agents connect to the installation server. The server has three layers: the application (the app server and background jobs), services (chat, mail, office files, full-text and semantic search, cache) and data (the database and files on the local disk). Only when needed, requests go out to an Ollama machine, exchange-rate sources, a public-holiday calendar, browser push services, mail servers and your site hosting.
Only this leaves the server — and only when needed
Each row fires only when someone uses that feature: picks an exchange-rate source, allows push notifications, publishes a site.
| Where to | What leaves | When |
|---|---|---|
| Ollama machine on your network | Text from records, comments, notes and files — to build the semantic index | While semantic search is on. Without Ollama, search works on plain text only |
| CBR, NBRB, ECB | Only the exchange-rate request | Once a user picks a rates source for search; there is none by default |
| Nager.Date | A country code and a year; the holiday list that comes back is kept on the server for three months | When public holidays are on in the Gantt calendar or greetings are on for the country in a profile |
| Your browser’s push service | The notification text, encrypted for your browser | If you allowed push notifications on that device |
| Recipients’ mail servers | Messages you send to outside addresses | When you send mail outside |
| Your previous mail server | An IMAP connection for mail migration. After a one-time migration the source password is wiped | While a migration or ongoing sync is running |
| Your site hosting | The files of a published site, over SSH/SFTP | When you press Publish |
| An AI agent you issued a token to | Whatever the agent read — within the token owner’s roles | Until the token is revoked |
Inbound from the internet: forms and chat on published sites call the Eyeward server, so the app needs a public address for them. The chat server doesn’t connect to outside servers: federation and sign-up are off, and the only way into chat is through Eyeward.
Sign-in: a password, a second factor and sessions in plain sight
The usual sign-in is a username or email and a password. Each person turns on the second factor for themselves, and the company owner can see which employees already have it.
Password · Second factor · QR sign-in · Sessions · Bans
- Password
- Stored as a scrypt hash — it can’t be recovered from the database, only reset.
- Second factor
- A code from Google Authenticator or any other app (TOTP). Setup gives you backup codes, each valid once. After too many wrong codes, sign-in is locked for a while.
- QR sign-in
- A device where you’re already signed in shows a QR code. The code lives for 2 minutes and works once.
- Sessions
- Devices lists every active session: device type, OS, IP address and last activity. An unfamiliar session ends with one click.
- Bans
- Banning a user closes every way in at once — sessions as well as device and agent tokens.
Authenticator app demo
Eyeward (demo)
Backup codes: issued at setup, each works once
The code is computed in your browser with the TOTP algorithm from a random demo key, and it isn’t sent anywhere.
Roles decide who sees what — down to the field and the record
Access is granted only through company roles; there are no personal permissions. Several roles add up — a second role never takes anything away. The server checks every permission.
Example: the Orders module at Gidrovelm. The roles and levels are made up — the mechanism is real.
- Levels 1–100
- A field is visible if the role’s level in the module is at least the field’s read level, and editable if it’s at least the edit level. Records have a level too: a record above the role’s clearance never makes it into the list.
- Field exceptions
- For a specific role, the level of a particular field can be overridden — to open it or to close it.
- “Own records only”
- A condition compares a record field with the current user — say, “Assigned to” — or checks the record author. It can only narrow access, never widen it.
- Preview
- Check a role through an employee’s eyes without a test account: “View as this role” or “As a specific employee”, in a safe read-only mode, with a “What’s visible” breakdown.
- Server-side checks
- A field closed by its level is cut out of the server’s response: it isn’t in the form, the list or an export.
- Who bypasses roles
- The module’s creator, the company owner and the installation’s superadmin. Nobody else.
A token is shown once; the database keeps only its hash
The sync client and AI agents sign in with a token, not a password. Each token has a scope: it opens exactly what it was issued for.
Agent tools with this token mcp_read
- whoami
- list_modules
- get_module_schema
- query_records
- get_record
- search
- create_record — not with Read only
- update_record — not with Read only
No token gets a delete tool.
1 — Prefix · 2 — Secret · 3 — Hash
- Prefix. eyw_mcp_ means an agent’s access to records, eyw_dev_ a sync client’s access to files. Spot the string in a log or a config file and you know exactly what leaked.
- Secret. The string is shown once, when it’s issued. Lost it? Revoke the token and issue a new one.
- Hash. The server stores only a sha256 of the string. The token itself can’t be recovered from the database.
| Used by | Prefix | Scope | What it opens |
|---|---|---|---|
| Eyeward Sync | eyw_dev_ | files | The Files section and the client’s update check — nothing else |
| AI agent, Read only | eyw_mcp_ | mcp_read | 6 read tools: modules, schemas, records, search |
| AI agent, Read and write | eyw_mcp_ | mcp | Also creating and updating records. There is no delete tool |
An agent acts on behalf of the token’s owner and within their roles. Revoking works instantly, and banning a user closes their tokens too. There are no other keys: Eyeward has no general-purpose API keys.
Every change is logged — and nearly everything can be rolled back
The activity center keeps a single log: who changed what, and when, across the whole system. Everyone sees only events from modules they have access to. Delete a record and its history stays in the log.
Activity
A single audit trail of every user action across the system
Today
- 4:05 PM
Marina Gulevich Updated Record · Orders
ЗАК-0042 Pumping station NS-40
- Status: Confirmed → In production
- Cost: 94,100.00 Br → 96,300.00 Br
- 3:48 PM
Igor Savchuk Created Record · Invoices
СЧ-0118 Advance for ЗАК-0042
- 3:20 PM
Ivan Sidorenko Created Comment · Orders
ЗАК-0047 Press P-160 upgrade
- Text: “Frame welded, sending it to the paint shop”
- 2:55 PM
Marina Gulevich Deleted Record · Orders
ЗАК-0041 Pumping station NS-40 (duplicate)
- 2:10 PM
Ivan Sidorenko Created Record · Orders
ЗАК-0041 Pumping station NS-40 (duplicate)
- 1:37 PM
Igor Savchuk Updated Record · Clients
Olvata-Energo
- Payment terms, days: 14 → 30
- 12:02 PM
Marina Gulevich Restored Record · Invoices
СЧ-0112 Payment for ЗАК-0045
- Amount: 19,575.00 Br → 21,750.00 Br
- 11:15 AM
Igor Savchuk Updated Field · Orders
Delivery date
- Required: no → yes
No events match these filters
Records · Module settings · Documents, charts, workspaces · Files
- Records
- Versions with before/after pairs, row by row for tables. Roll back a whole record or a single field. Every edit is labelled with its source — the form, Kanban, Gantt, an import and 8 more.
- Module settings
- Every save is a separate version. The module can go back to any of them.
- Documents, charts, workspaces
- Published in versions — you can return to an earlier one.
- Files
- Content version history with a comparison and a Restore button; deleted files go to the trash.
- A deleted record
- Can’t be restored: there is no trash for records. The delete dialog lists up front what goes away with the record.
Restoring versions and purging history are separate role operations — not everyone gets them.
A working mockup of the Orders module’s version history. Every earlier version has a “Restore the module to this version” button: it shows what will change, and once confirmed it records a new version on top — the earlier ones stay in the history.
Every saved module setting becomes a version: what changed, who changed it and when. Any version can be restored.
-
Marina Gulevich 9/22/2026, 4:40:12 PM Version 14 fields and form Current
Fields
- Delivery date required
- added Cost
-
Igor Savchuk 9/19/2026, 11:15:47 AM Version 13 statuses
Statuses
- added Ready to ship
-
Marina Gulevich 9/15/2026, 9:32:05 AM Version 12 rules
Rules
- added Urgent order → notify the shop supervisor
-
Ivan Sidorenko 9/10/2026, 2:05:31 PM Version 11 settings
Settings
- Require approval
offon
- Require approval
Settings, fields, form, rules, statuses and actions will go back to how they were in this version. The history is not rewritten: a new version is added on top, and it can be restored too.
Restoring leaves the module’s relations and company binding alone.
How secrets are stored — and what’s up to you
We won’t tell you “everything is encrypted”. Here is how secrets are stored — and where the installation owner adds protection.
| What | How it’s stored |
|---|---|
| User passwords | hash A scrypt hash — can’t be recovered from the database |
| Passwords on public file links | hash A scrypt hash |
| Device and agent tokens | hash Only a sha256 hash |
| Second-factor secrets and backup codes | encrypted Encrypted by the sign-in library with the server key |
| SSH access to site hosting: key, password, passphrase | encrypted AES-256-GCM, with the key derived from the server secret. These are the only integration secrets Eyeward encrypts itself |
| Mail credentials: mailboxes, IMAP and SMTP, DKIM keys | on the server Only in the database on the installation’s server. Never sent to the browser |
| Records, files, mail, chat messages | on the server On the installation’s server. Storage encryption comes from the disk — see below |
Good to know
- Chat has no end-to-end encryption: messages are stored on the installation’s server.
- Deleting a record is final: there is no trash for records.
- Semantic search sends text to the Ollama machine — keep it on your own network.
What the installation owner should do
- Close access to the server and the database for anyone who doesn’t need it.
- Encrypt the disks and the backups of the database and files.
- Ask everyone with broad roles to turn on the second factor — the owner can see who already has.
Check it against your own process
In the demo we’ll show roles and previewing them through an employee’s eyes, the activity log and version rollback — on an example close to yours.