Trust is infrastructure
Operational visibility requires operational trust.
Phibian is built around clear authorization, organizational separation, auditable activity and deliberate control of sensitive operational data. Security isn’t a page we added after the product. It is part of how the product is designed.
Current architecture
What is true today.
Every item below is an implemented control in the product, enforced in the system rather than described in a policy document.
Tenant isolation
Every tenant-owned record carries its organization. Row-level security is forced on tenant tables and the application database role holds no privilege to bypass it. Isolation is proven by two-organization tests that ship with every module, wrong-tenant reads return nothing and wrong-tenant writes are rejected.
Role-based access, default deny
Nothing is granted implicitly. Permissions are explicit and can be scoped to a program or a location, so access reflects what a person is actually authorized to see and do. Requests never supply their own organization, tenant context is resolved server-side from the authenticated session.
Auditability
Audit events are insert-only: the application has no path to update or delete one. Sensitive reveals, such as opening a client’s full name, write an audit event as a matter of course, and event timestamps are set server-side rather than accepted from a caller.
Customer-managed integration credentials
Connector credentials are held in a managed secret store and referenced from the database, never stored in it. Credentials are write-only from the interface, are never returned by any API response, and are scoped to one organization and one connector.
Location controls
Location is collected only during an open work session, under a policy the organization sets. Viewing raw location history is a distinct permission granted to no role by default, and viewing it is recorded. Coordinates, addresses and geofence names are never placed into messages, notifications or general logs.
Data handling on devices
Work captured offline is queued encrypted on the device and uploaded idempotently, so a retry cannot create duplicate records. Nothing is destructively deleted from the queue before it is confirmed.
How it is enforced
A control is only as good as the place it is enforced.
Access rules written into application code hold until one query is written differently. The controls above are enforced at the layers underneath that, and checked automatically as the product changes.
Enforced in the database
Isolation does not depend on every query remembering to filter correctly. Row-level security is forced on tenant tables, and the role the application connects as holds no privilege to bypass it. A query that forgets its boundary returns nothing rather than returning someone else’s records.
Enforced at the application boundary
Tenant context is resolved server-side from the authenticated session. A request cannot name the organization it wants to act on, so a caller cannot reach another tenant by changing a value it controls.
Proven by tests that run on every change
Cross-tenant isolation tests run in continuous integration: a second organization attempts the reads and writes the first is authorized for, and the suite asserts that each one fails. The same suite checks that the application role has no route around row-level security.
Held at the connector boundary
Integration code is confined behind a defined interface, so a vendor’s field names and response shapes never reach the operational core. Credentials are scoped to one organization and one connector and are resolved from a managed secret store at the moment of use.
Worker trust
Visibility without surveillance.
Work-related operational evidence can be valuable. It can also be abused when systems hide what they collect or present uncertain data as fact. “Support, not surveillance” is a governing design law in Phibian, these are the rules it produces.
Purposeful collection
Operational data exists for a reason a worker can understand. Location capture is bounded by the work session as a structural property of the system, not as a setting somebody has to remember to switch off.
Visible states
Workers can see what the system is doing: whether location was captured, whether it was confirmed, whether an action is queued offline, and what has been recorded about them.
Correctable records
Mistakes should not become permanent truths. A correction supersedes the original and both are kept, so fixing a record never looks like hiding one.
Human review
Location readings, exceptions and automated signals are evidence for review, never automatic guilt. A coverage gap raises a question for a person, not a finding against a worker.
Uncertainty is visible
The interface does not pretend to know what the data cannot prove. A weak GPS fix is reported as unconfirmed rather than as “outside”, and stale data is labelled rather than presented as current.
Timekeeping stays the worker’s
What the device recorded is what counts, including offline. Server receipt time is recorded for reconciliation but never silently replaces the time work actually happened.
There is a practical argument here as well as an ethical one. A workforce that experiences a system as surveillance works around it, and the operational record degrades to match. Trust is what keeps the data worth having.
Security review
Ask us the specific questions your review requires.
This page describes architecture. A security review usually needs more than that: how a particular control is implemented, what a data flow looks like end to end, or what your own assessors need to see. Write to us and you will get a direct answer from the person who built it.
Diligence and documentation
Security teams can contact us for questionnaires, architecture and data-flow reviews, or security diligence. Tell us what your process requires and what your timeline is, and we will work to it.
Reporting a vulnerability
We would rather hear about a security issue from you than from anyone else. Reports are welcome from customers, prospective customers and independent researchers alike.
Keep exploring
Platform
How Phibian connects field operations, workforce and compliance, and operational intelligence.
Explore PlatformWhy Phibian
The category thesis and the operator experience Phibian was built out of.
Explore Why PhibianDesign Partners
How to apply to run Phibian in your operation during early access.
Explore Design PartnersHave a security review to run?
Serious diligence questions get a direct answer from the person who built the underlying controls. Email us and we will pick this up in one thread.