Skip to main content
Trust & Compliance

Security Architecture

How IBIOS is built to protect your business data. Authentication, infrastructure isolation, AI segregation, social engineering defences, and audit logging — in plain language.

Authentication

All user sessions are authenticated using JSON Web Tokens (JWT). Sessions expire, after which users must sign in again. This limits the window of exposure if a device is left unattended or a token is compromised.

Token type

JWT (JSON Web Token)

Session expiry

Sessions expire; sign in again

Password hashing

bcrypt

Failed login lockout

After repeated failed attempts

Rate limiting

Applied to all auth endpoints

Password reset

Email verification required

Infrastructure isolation

IBIOS is deployed using containerised infrastructure, with the web application, backend API, and database running as separate isolated containers. Network rules restrict which containers can communicate with each other: the web application can only call the API, and the API can only call the database. The database is not reachable from the internet.

This isolation means that even if a vulnerability were exploited in the web layer, an attacker would still face the API authentication layer before reaching any data. Direct database access from the internet is not possible by design.

All connections to the server from the internet are proxied through a reverse proxy, which handles TLS termination and enforces HTTPS on all endpoints. Plain HTTP connections are automatically redirected to HTTPS. The server does not accept connections on unencrypted ports from external addresses.

AI trade-secret segregation

Coming soon: the AI Receptionist will operate through a restricted database view. It will see the information needed to handle customer calls: customer names, appointment availability, product names and descriptions, and service information you have configured.

Accessible to AI

  • Customer names and contact details
  • Calendar availability
  • Product names and descriptions
  • Configured FAQ responses
  • Opening hours and service information

Not accessible to AI

  • Cost prices and trade margins
  • Supplier pricing and discount structures
  • Profit analysis and markup percentages
  • Financial records and payment history
  • Staff user accounts and permissions

When the AI Receptionist launches, this segregation will be enforced at the application layer, not just by convention. The AI will call a read-only API endpoint that returns only permitted fields, so a caller cannot instruct the AI to reveal cost prices or margins — those fields will not be in the data the AI has access to.

Social engineering defences: action risk matrix (Tier 4 coming soon)

All actions in IBIOS are classified into one of four tiers based on their potential for harm. The tier determines what authorisation is required and whether the action can be triggered by an AI or automated process, or only by a deliberate human action.

Tier 1Read operations

View records, search, read reports. No confirmation required. Fully logged.

Tier 2Standard writes

Create and update records, send messages, upload documents. Logged with user and timestamp.

Tier 3Elevated actions

Approve quotes, manage users, configure settings. Requires the relevant permission in the user’s role. Logged.

Tier 4Absolute blocks (coming soon)

Coming soon: delete records, change bank details, modify financial data. These actions will be blocked regardless of any instruction — including an instruction that appears to come from a user or AI. They will require a deliberate, authenticated action by an authorised user with explicit permission.

Coming soon: Tier 4 actions will be hard-coded blocks at the API level. No instruction — whether from a user, an AI, or an automated integration — will be able to trigger a Tier 4 action without the direct, authenticated action of a human user with the explicit permission. This is the same principle as requiring a physical signature for large financial transactions.

Penetration testing

Annual penetration testing by an independent third party is planned as part of the IBIOS security programme. To be transparent: this has not yet been completed for the current version of the product. We will publish the completion status and a summary of any significant findings and remediations when testing is done.

Internal security reviews are conducted on all significant code changes. The architecture described on this page reflects the current production system. If you have a specific security requirement or would like to discuss the security posture in more detail, contact us at security@allforone.ai.

Audit log

Every action that creates, modifies, or deletes data in IBIOS is recorded in an append-only audit log. Each entry records the user ID, the timestamp, the originating IP address, the entity type and ID affected, and a description of the action taken.

FieldExamplePurpose
Userjim@business.co.ukWho took the action
Timestamp2026-04-25 09:14:32Exact time, server-side
IP Address82.x.x.xSource location
ActionDELETE quote QUOT-0047-v2What was done
Entity IDQUOT-0047-v2Which record

The audit log is read-only for all standard user roles. It cannot be edited or cleared by staff or manager accounts. Admin accounts can view and export the log but cannot modify historical entries.

IBIOS (Integrated Business Intelligence & Operations System) is made by IBIOS Limited (NI743167), Northern Ireland. Some of the AI protections below belong to the AI receptionist, which is coming soon.

What do people ask about IBIOS security architecture?

Is IBIOS ISO 27001 certified?

No. IBIOS does not hold ISO 27001 certification. Our security practices are built to ISO 27001-style controls (not certified).

What if a staff member goes rogue?

The audit log records every action with user ID, timestamp, and IP address. Admin users can review all activity for any staff member. Role-based permissions limit what each user can do — a standard staff member cannot delete records, access cost prices, or modify other users’ accounts. If a compromise is detected, the admin can immediately revoke a user’s access from the user management panel.

Can someone brute-force passwords?

Rate limiting is applied to all authentication endpoints. After repeated failed login attempts, the account is locked and the registered email address receives a lockout notification. Unlock requires either a timed cooldown or an admin action. Password hashing uses bcrypt which is deliberately slow to compute, making brute-force attacks computationally impractical.

Will IBIOS store call recordings (coming soon)?

Coming soon: IBIOS call recording. Today, call reports and call briefings work from recordings held in your own connected service (such as GoHighLevel). When IBIOS call recording launches, recordings will be accessible only to users with the call recording permission in their role, and only after authentication.

What encryption is used for backups?

Database backups are encrypted. Backup files are stored in a geographically separated location from the primary server. Backup access requires server-level credentials that are separate from application-level access, meaning a compromise of the application does not automatically grant access to backup files.

Questions about security architecture?

Contact us at security@allforone.ai. We welcome specific security questions from prospective customers and will answer them as fully as we can within responsible disclosure limits.