SECURITY AND TRUST
Built to Keep the Right Data With the Right People.
Bikabo holds client work, staff compensation and financial history for separate businesses in one system. This page describes how that data is kept apart, who can reach what, and what is recorded when someone does.
Security at a Glance
- Every operational record carries the identifier of the business that owns it, and every query that reads one filters on it.
- Two checks stand between a request and an action, both on the server: does this role permit it, and is this particular record yours to touch.
- Seeing what work is costing and seeing what a person earns are separate permissions, so the people running delivery need never see the payout book.
- The Client Portal is a separate set of pages with its own sign-in and its own narrow queries, not the internal workspace with sections hidden.
- Files are returned only by a request that has been checked against the person asking, and every Client download is recorded.
- Financial history is corrected by new linked entries, never edited in place, and the rate that applied at approval is recorded on the entry.
Tenant Isolation
Each business on Bikabo is a separate tenant. Every operational record, from a Client to a Task to a ledger entry, carries the identifier of the tenant that owns it, and every query that reads one filters on it explicitly.
A user account is a global identity, so the same person can belong to more than one business. Role and access live on the membership rather than the person, which means signing in to one workspace confers nothing at all in another, and the same individual can be an Admin in one business and an Assistant in another without the two touching.
Authentication and Sessions
- Passwords are stored as hashes, never as recoverable text.
- Failed sign-in attempts are counted and rate limited, so a password cannot be guessed at speed.
- A sign-in attempt against an address that does not exist costs the same time as one against an address that does, so the response cannot be used to discover who has an account.
- The session identifier is regenerated on sign-in.
- Sessions are revalidated against the database on every request rather than trusted for their lifetime. Deactivating someone takes effect on their next request, not at their next sign-in.
- Password reset links carry a hashed, expiring token compared in constant time.
- Changing an account email requires confirmation at the new address.
Permission Plus Resource Access
Two independent checks stand between a request and an action, and both have to pass:
Permission + Resource Authorization = Allowed Action
The first asks whether this person’s role permits this kind of action at all. The second asks whether this particular record is theirs to touch: is this your Task, is this Client in your tenant, are you the Checker on this submission. Holding the permission to review work does not let anyone review a submission that was never assigned to them.
Both checks run on the server, on every action. A control that is hidden in the interface is hidden because the check already failed, not instead of the check.
Financial Role Separation
Money is not one permission. Seeing what a Task or Engagement is costing and seeing what an individual worker has earned across the business are separate keys, held separately.
That separation is what makes the Admin Profiles meaningful. An Operations Admin runs delivery and can see the cost forming on the work they coordinate, without ever seeing the payout book. A Finance Admin manages compensation and client billing without being able to assign or reassign work. A Client Admin owns the client relationship and never sees staff compensation at all.
Client Portal Isolation
The Client Portal is not the internal workspace with sections hidden. It is a separate set of pages with its own sign-in identity and its own narrow queries, which select only what a Client is entitled to and never join to the internal record at all.
A Client record and a portal login are two different things. Having the first does not create the second, and portal access can be invited, suspended, reactivated and revoked independently of the Client continuing to exist.
What a Client never sees
- Who checked their work, or that a Checker exists.
- Internal assignments, submissions, review decisions and revision history.
- Staff compensation, payouts or advances.
- Internal cost, margin or exposure figures.
- Internal notes and internal team discussion.
- Secure Access Details.
Protected Files
Uploaded files are never served straight off the filesystem. They sit outside the paths the web server will hand out, in a location that refuses direct requests and executes nothing at all.
Every download runs through a script that checks the requester first: a staff member must belong to the tenant that owns the Task, and a Client may only receive a file that has been explicitly marked visible to them, on a Task and an Engagement that are themselves visible to them, and only once the work has actually been delivered. Knowing a file’s address is never enough to retrieve it.
Uploads are checked on the way in as well: size, an allowed extension, and confirmation that the contents match the extension claimed. Files are stored under generated names rather than the name they arrived with. Every download a Client makes is recorded.
Secure Access Details
Some client work needs credentials or connection details to perform. Putting those in a note or a message would spread them through the system in plain text, so they get their own field type with its own rules:
- Encrypted at rest with AES-256.
- Masked by default, everywhere they appear.
- Revealed only by someone who holds the specific permission to reveal them.
- Every reveal is recorded, with who and when.
- Excluded from ordinary notifications, from email, from exports and from the Client Portal.
Auditability
Sensitive actions are written to an audit trail with the person, the action, the record and the time. That covers role and access changes, ownership transfer, payment and payout records, revealing a Secure Access Detail, and Client downloads from the portal.
The audit trail exists so a question about what happened has an answer that does not depend on anyone’s memory.
Financial History Integrity
Financial records are never edited in place. A correction is a new entry linked to the one it corrects, so the original and the correction both remain readable, and a figure that was true last month still says what it said last month.
The rate that applied when work was approved is recorded onto the entry at that moment. Changing a compensation rate today does not rewrite what yesterday cost.
The same principle covers the work itself. Reassigning a Task does not erase who held it before, what they submitted, or how it was reviewed.
Request and Input Protection
- Every form that changes something carries a CSRF token, checked on submission.
- Every database query is parameterised. Values reach the database as values and are never assembled into the text of a query.
- Output is escaped where it is written, so stored text cannot become markup.
- Actions that create financial consequences carry guards against being submitted twice, including a database-level lock on the approval path, so a double click cannot pay for the same work twice.
- Sensitive requests are rate limited.
Sensitive Notifications and Email
Notifications tell people that something happened and where to look. They do not carry the sensitive value itself. Secure Access Details never appear in an email or a notification body, and a notification about a record is delivered only to people who are entitled to that record in the first place.
Client conversations and internal team discussion are separate systems. Nothing an Assistant or Checker writes internally is delivered to a Client, and a reply reaches a Client only when someone on the business side sends it.
Data Lifecycle
Removing access does not remove history. Deactivating a team member ends their access immediately and leaves the record of their work intact. Archiving a Client stops new work without deleting what came before. Closing an Engagement winds it down through an explicit process rather than making its history disappear.
The same rule holds commercially: moving to a smaller plan restricts what can be added next, it does not delete what is already there.
Platform Access Boundary
Bikabo operating the service is a separate fact from anyone’s role inside a business on it. Platform administration is not a tenant role that could be granted by mistake, it is a distinct record checked by its own gate, in its own pages, deliberately not sharing machinery with the permission system that governs tenants.
That separation exists so that no configuration inside a business can ever produce platform-level access, and so that platform access cannot quietly inherit a tenant’s permissions.
Reporting a Security Issue
If you believe you have found a security problem in Bikabo, report it to secure@bikabo.com. Please include enough detail to reproduce it. Do not test against another business’s data.
On certification. This page describes controls implemented in the software rather than the findings of an external audit, and Bikabo does not hold SOC 2, ISO 27001, HIPAA or PCI certification. Nothing above should be read as implying one. Where a formal security review is part of your procurement, write to secure@bikabo.com and we will answer your questionnaire directly.
Security Questions
No. Every operational record carries the identifier of the business that owns it, and every query that reads such a record filters on it. A user account is a global identity that can belong to more than one business, but the role and the access come from the membership, not the person, so signing in to one workspace grants nothing in another.
Only if their role includes it. Seeing the cost exposure on a Task and seeing a worker’s earnings across the business are two separate permissions. An Operations Admin runs delivery with the first and not the second, so the person coordinating the work never sees the payout book.
Their own Engagements, whether work is In Progress or Completed, files that have been explicitly delivered to them, their conversations with your business, and payment information where you have chosen to show it. They never see internal assignments, review history, who checked the work, staff compensation, internal costs or margins.
Protected. Uploaded files are stored outside the paths the web server will serve, in a location that refuses direct requests and executes nothing. A file is only ever returned by a request that has been checked first, against the person asking and against that specific file.
No. Corrections are new entries linked to the ones they correct, never edits in place, and the rate that applied when work was approved is recorded on the entry at that moment. Changing a rate today does not rewrite yesterday.
Their access ends and their history stays. Deactivating a team member takes effect on their next request rather than at their next sign-in, and it removes nothing: the work they did, what they submitted, how it was reviewed and what it cost all remain readable. The same holds when a Task is reassigned, when a Client is archived and when an Engagement is closed.
Running the service and holding a role inside a business on it are separate facts, kept separate on purpose. Platform administration is its own record behind its own gate, not a permission that a tenant could hold or grant, so no configuration inside your business can produce platform access and platform access does not inherit a tenant’s permissions. Secure Access Details are encrypted at rest, masked wherever they appear, and every reveal is recorded with who and when.