01
Application authorization
Every protected request is checked against the authenticated user, Workspace membership, assigned role, permission, resource ownership, and applicable business rules.
Organizing today’s activity…
KOMERRA is entrusted with customer records, orders, documents, communications, business activity, and Credit balances. This page explains how that trust is protected — plainly, specifically, and without pretending that any internet-connected service is risk-free.
Layered security
Identity, authorization, isolation, verification, and evidence work together.
01
Authenticate
02
Authorize
03
Isolate
04
Audit
KOMERRA applies layered controls across identity, permissions, database access, payments, integrations, AI-assisted workflows, logging, monitoring, providers, and incident response.
No single safeguard is treated as sufficient. Authentication does not replace authorization. Application checks do not replace tenant-aware database controls. A payment redirect does not replace provider verification. AI confidence does not replace human review.
Security controls must be continuously tested, reviewed, updated, and matched to the behaviour of the production platform rather than existing only in policies, diagrams, or development plans.
KOMERRA is designed so that a failure or mistake in one layer does not automatically become unrestricted access to the entire platform.
Database tenant isolation
Business records are associated with a tenant and protected through tenant-aware database controls, including row-level security where configured. This creates an independent barrier behind application authorization.
Hardened authentication
Credentials are protected using strong one-way hashing. Sessions are time-limited, sensitive authentication events are monitored, and repeated failed attempts may trigger delays, temporary lockout, or additional verification.
Session and token protection
Refresh credentials are rotated, reuse can invalidate the related session family, logout revokes applicable access, and authentication secrets are not stored in ordinary application records.
Role-aware authorization
Access is evaluated against Workspace membership, assigned role, explicit permissions, resource ownership, and the requested action rather than relying only on whether a user is logged in.
Audit trails
Security-sensitive events such as logins, lockouts, credential changes, permission changes, Credit movements, webhook rejection, and privileged actions can create durable records for review.
Server-side trust decisions
Payment verification, Credit allocation, permissions, document ownership, tenant access, and other sensitive decisions are determined by trusted server-side logic rather than browser claims alone.
KOMERRA’s access model is designed to verify more than a password. It evaluates identity, session state, Workspace membership, role, permission, and the resource being requested.
Passkeys and device biometrics
Where enabled, fingerprint or facial unlock uses device and operating-system security through passkey or WebAuthn-style authentication. Raw fingerprint and facial templates ordinarily remain on the user’s device.
Individual staff access
Businesses can provide staff with individual access rather than sharing one password, making it possible to assign roles, remove access, and attribute sensitive actions to the responsible user.
Verification where risk requires it
Email, telephone, identity, business, administrator, ownership, or payment verification may be required before access to higher-risk features is granted.
Time-bounded sessions
Sessions are not intended to remain trusted indefinitely. Expiry, rotation, re-authentication, device changes, risk events, or sensitive actions can require a new authentication decision.
Suspicious-session response
Unexpected credential reuse, repeated login failure, unusual authentication behaviour, or another material risk may revoke sessions, lock an Account temporarily, or require additional verification.
Administrative visibility
Authorized Workspace administrators can review staff access and security-relevant activity, helping businesses remove former users and identify permissions that are broader than necessary.
Device unlock and identity verification are different.
A phone’s fingerprint or Face ID feature ordinarily confirms possession of an approved device credential without sending KOMERRA the raw biometric template. A separate identity-verification workflow may process a facial image or identity document through an approved provider and must have its own purpose, notice, safeguards, and retention rules.
KOMERRA uses multiple layers to keep Workspace records, permissions, files, documents, and business activity separated.
Every protected request is checked against the authenticated user, Workspace membership, assigned role, permission, resource ownership, and applicable business rules.
Tenant-aware database controls are designed to prevent one business from reading or changing another business’s protected rows, even if an application query is written incorrectly.
Internal services receive only the identity, tenant context, permissions, and information required to perform the requested operation.
Security-sensitive actions create records that can support investigation, accountability, troubleshooting, and administrative review.
Tenant isolation must be verified continuously.
Database policies are not enough if privileged database connections bypass them, tenant context is missing, background jobs use the wrong Workspace, object-storage keys are predictable, or administrative tools ignore authorization. KOMERRA’s security process must test every access path, not merely document the intended architecture.
Security covers more than storage. It includes collection, transmission, access, processing, export, retention, deletion, backup, and recovery.
Encryption in transit
Supported production traffic is protected with modern transport encryption between browsers, applications, APIs, infrastructure, and approved providers.
Protected storage
Databases, managed storage, and object-storage providers are selected and configured to support encryption, access control, durability, logging, and restricted credential use.
Private file access
Private uploads should be retrieved through authorized requests or time-limited signed access rather than being exposed through permanently public storage paths.
Least-privilege access
Personnel, services, jobs, and providers should receive only the production access and information reasonably required for their authorized responsibilities.
Retention and deletion controls
Account data, Workspace content, billing records, logs, files, backups, and verification information follow purpose-specific retention and deletion rules rather than being kept indefinitely by default.
Provider governance
Hosting, storage, AI, messaging, monitoring, verification, email, and payment providers are assessed according to the information involved, contractual protections, access, location, reliability, and security risk.
KOMERRA separates language understanding from trusted calculations, authorization, record ownership, payment confirmation, and final business approval.
Review before high-impact action
For workflows requiring confirmation, KOMERRA presents the important extracted details before a record, communication, document, or other material action is approved.
Visible source and context
Users should be able to compare an AI extraction or suggestion with the original message, image, document, voice note, or business record before relying on it.
Code performs trusted calculations
Prices, quantities, totals, taxes, balances, stock movements, Credit deductions, permissions, and payment outcomes should be calculated or validated by deterministic application logic rather than guessed by a model.
Permissions still apply
An AI feature cannot lawfully exceed the permissions of the authenticated user, cross tenant boundaries, bypass approval requirements, or create authority that the user does not possess.
Confidence is not proof
Confidence indicators and validation rules help prioritize review, but they do not transform uncertain Output into independently verified fact.
Corrections remain possible
Users can review, correct, reject, or replace extracted information before approval, and material corrections should remain attributable through the relevant activity history.
AI may propose
A likely customer, order, amount, classification, reply, reminder, or document draft.
Code must validate
Tenant, permission, identifiers, arithmetic, Credit availability, workflow rules, and provider results.
A person must own
The final business decision, customer communication, financial commitment, and approved record.
KOMERRA separates payments made to a business from payments made to KOMERRA for Credits or paid services.
Customer sales
Where a Mini Store displays the business’s bank details, payment link, cash option, POS option, or another payment instruction, the customer pays the business or its selected provider directly.
KOMERRA may record an order, store uploaded evidence, extract payment details, and display a status, but the business must independently confirm settlement through its bank or authorized payment provider.
A screenshot, receipt image, debit alert, transfer claim, or AI extraction is evidence to investigate — not final proof that funds settled.
KOMERRA Credits
A successful browser redirect does not create Credits. The backend verifies the payment reference and expected transaction details through the provider’s trusted server-side interface.
Payment webhooks are checked using the applicable provider signature or secret, processed idempotently, and reconciled against the expected Account, currency, amount, status, and transaction reference.
Duplicate callbacks, forged requests, mismatched amounts, reused references, or unverified client-side claims must not create additional Credit value.
Connected providers are useful, but every external callback crosses a security boundary and must be treated accordingly.
Cryptographic verification
Supported payment and integration webhooks are checked against the applicable provider signature, secret, certificate, or verification mechanism before protected state is changed.
Idempotent processing
Repeated delivery of the same provider event should not create duplicate Credits, duplicate records, repeated notifications, or repeated financial effects.
Reference reconciliation
Provider references, expected Account, amount, currency, status, and transaction ownership are reconciled before a sensitive event is accepted.
Rejected-event visibility
Invalid signatures, malformed payloads, unknown references, amount mismatches, replay attempts, and processing failures produce security or operational records.
Restricted provider permissions
Connected services should receive only the scopes and permissions needed for the selected workflow rather than unrestricted access by default.
Secret management
Provider secrets, API credentials, signing keys, and access tokens belong in protected secret-management or environment systems, not source control, client bundles, logs, or public configuration.
Security investigations depend on reliable records showing what happened, when it happened, which identity acted, what resource was affected, and whether the operation succeeded.
Security-event monitoring
Authentication failures, lockouts, session events, permission changes, suspicious requests, provider failures, and other material signals can be monitored and investigated.
Privileged-action logs
Administrative and support actions affecting users, businesses, permissions, verification status, Credits, security controls, or protected records should be attributable and reviewable.
Abuse and fraud indicators
Rate limits, behavioural signals, verification results, duplicate activity, suspicious payment evidence, and provider events help identify misuse requiring additional review.
Masked diagnostics
Error monitoring and session diagnostics should mask passwords, authentication secrets, payment credentials, government identifiers, and designated sensitive fields.
Error-to-incident connection
Material application failures can be linked to request identifiers, affected releases, service logs, and relevant replay or diagnostic context without exposing unnecessary private data.
Purpose-based retention
Audit, security, support, and diagnostic records are retained according to risk, investigation, accountability, and legal needs rather than indefinitely without purpose.
KOMERRA’s incident process is designed to move from detection to containment, investigation, recovery, communication, and measurable improvement.
Authentication anomalies, repeated failures, rejected webhooks, unusual request patterns, provider errors, and security events are recorded for review.
Affected sessions, credentials, integrations, routes, Accounts, or Workspaces may be temporarily restricted while the risk is assessed.
Relevant logs, audit events, provider references, request identifiers, deployment history, and affected records are reviewed to determine scope and cause.
The affected service is restored through controlled remediation, credential rotation, configuration correction, rollback, data recovery, or another appropriate response.
Where notification is legally or operationally required, affected businesses, users, providers, or authorities receive clear and appropriate information.
Material incidents lead to documented follow-up actions, control improvements, ownership, testing, and review rather than being treated as isolated technical errors.
Personal-data incident notification
Where an incident creates a legal notification duty, KOMERRA will notify the relevant business, affected people, the Nigeria Data Protection Commission, or another competent authority as required by the applicable circumstances and law. Incident communication will distinguish confirmed facts from matters still under investigation.
KOMERRA relies on specialist infrastructure and technology providers, but provider use must remain governed, limited, documented, and monitored.
Managed infrastructure
Production services may use managed hosting, databases, queues, storage, monitoring, email, messaging, AI, verification, and payment infrastructure selected for operational and security capabilities.
Provider assessment
Material providers are assessed according to purpose, information processed, permissions, contractual commitments, service location, incident handling, resilience, and security risk.
Separated credentials
Development, test, staging, and production credentials should be separated. Production secrets should be rotated after exposure, personnel changes, provider incidents, or other material risk.
Private internal communication
Background workers, schedulers, internal services, queues, and databases should use protected service identities, authenticated connections, and private networking where supported.
Dependency risk management
Libraries, containers, runtime versions, build systems, and third-party packages require updates, vulnerability review, controlled deployment, and removal when unsupported.
Subprocessor transparency
Material providers that process personal data are identified through the Privacy Policy, Data Processing Agreement, Subprocessors page, or an applicable enterprise agreement.
Availability, integrity, and recovery controls reduce the chance that a technical failure becomes permanent business loss.
Backup strategy
Critical managed data should be covered by documented backup, snapshot, retention, and recovery arrangements appropriate to the service and information involved.
Recovery procedures
Recovery procedures should define how services, databases, queues, files, credentials, and configurations are restored after failure or compromise.
Migration discipline
Database migrations require review, controlled execution, rollback or recovery planning, tenant-safety validation, and protection against accidental destructive changes.
Background-job reliability
Workers and schedulers use durable queues, deterministic identifiers, retry limits, idempotency, and failure visibility to reduce duplicate or lost business actions.
Health and capacity monitoring
Service health, queue backlog, error rate, latency, resource pressure, provider failure, and deployment status are monitored to identify degradation before it becomes widespread.
Business continuity
Critical workflows should have documented fallbacks so that businesses can continue essential communication, payment confirmation, and record keeping during an outage.
Business-controlled records
As between KOMERRA and the business, the business retains its rights in customer, order, product, document, communication, and operational records placed in its Workspace.
Transparent Credit usage
Chargeable actions and Credit movements should be visible through billing or usage history, including the action, amount, status, and relevant reference where applicable.
Export and deletion pathways
Available controls support correction, export, Account closure, and deletion processes, subject to ownership verification, fraud prevention, legal obligations, backups, and valid retention requirements.
No data sale
KOMERRA does not sell private Workspace records to advertisers, data brokers, or unrelated third parties.
Restricted AI use
Identifiable private Workspace content should not be used to train unrelated general-purpose models unless the Workspace owner knowingly opts into a separately explained program.
Business privacy responsibility
Each business remains responsible for having a lawful basis, giving required notices, assigning appropriate staff access, and respecting customer and employee privacy rights.
KOMERRA uses recognized security and privacy frameworks as engineering and governance references. We communicate assurance status precisely rather than turning framework names into marketing decoration.
ISO/IEC 27001
ISO/IEC 27001 provides requirements for establishing, implementing, maintaining, and continually improving an information-security management system.
KOMERRA may align policies, risk management, access control, incident response, supplier management, continuity, and improvement work with these principles.
SOC 2
SOC 2 reports are produced through an independent examination of controls relevant to criteria such as security, availability, processing integrity, confidentiality, and privacy.
Designing around these criteria does not itself mean that KOMERRA has completed a SOC 2 examination.
Nigeria Data Protection Act
KOMERRA’s privacy and security programme is designed to support lawful processing, purpose limitation, data minimization, appropriate safeguards, accountability, individual rights, provider governance, and incident response.
Assurance status
Unless KOMERRA publishes a current certificate or independent assurance report, references to ISO/IEC 27001 or SOC 2 describe control alignment and readiness goals—not completed ISO certification, a SOC 2 report, regulatory approval, or a guarantee that an incident cannot occur.
Report suspected vulnerabilities privately and provide enough detail for us to reproduce, assess, and correct the issue.
Send security reports to support@komerra.app
Include “Security Report” in the subject and provide the affected page or service, steps to reproduce, expected and observed behaviour, approximate time, potential impact, and any safe supporting evidence.
Do not access another person’s records, disrupt production, perform destructive testing, publish sensitive details before remediation, use social engineering, or retain information beyond what is necessary to demonstrate the concern.
KOMERRA will not insult customers by claiming otherwise. Our commitment is disciplined engineering: isolation by default, minimum necessary access, verification before trust, deterministic controls around money and permissions, evidence for critical actions, practiced incident response, transparent communication, and continuous improvement when weaknesses are found.
Start with 20 free actions and experience business software designed around verification, accountability, control, and trust — no card required.