Security

This page describes the security measures that are actually in place in APROS today, the ones we do not offer yet, and how to report a vulnerability. APROS is built and run by ТОВ «АПРИКОД» (APRICODE LLC, “Apricode”, “we”).

No system is completely secure, and we cannot guarantee that data will never be accessed without authorisation. We can tell you precisely what we do.

How APROS is separated

• A workspace of your own. Every customer company gets its own workspace at <company>.apros.app, with its own application instance and its own database. Inside the database, every record is still tied to its workspace, as a second line of defence.
• Shared services, kept apart by keys. Some services are shared by all workspaces: the integration service, the AI gateway, the cache and job queue, file storage, video calls, the document editor and the real-time messaging server. Each workspace uses them with its own credentials, storage bucket, key prefix, AI budget or access token, which are designed to limit it to its own data.
• Hosting. Our servers are rented from Hetzner Online GmbH in Germany. Cloudflare provides DNS. The Sub-processors page lists every company that can receive personal data.

Encryption

• In transit. Browsers and apps connect to APROS over HTTPS. Workspaces send Strict-Transport-Security, so browsers refuse unencrypted connections. Video-call audio and video are encrypted between each participant and our media server (standard WebRTC encryption). They are not end-to-end encrypted.
• Secrets. Most credentials that APROS stores for you are encrypted in the application with AES-256-GCM, using a per-secret key that is itself encrypted with a master key we can rotate. This covers channel and bot tokens, Meta and WhatsApp access tokens, Google and other OAuth tokens, mailbox passwords, payment and bank connection credentials, AI provider keys, MCP and Git tokens, and telephony settings. A few items are not encrypted yet: secrets for notification webhooks, the codes used to link Telegram accounts, the client id and account number of a PrivatBank connection, and some tokens saved by older versions of APROS.
• Other data. Records, messages, emails and files are not encrypted at the application level. They are protected by the access controls described below.

Accounts and sessions

• Users sign in with an email address and a password. Passwords are stored only as bcrypt hashes (12 rounds).
• Every password needs at least 8 characters, with upper-case and lower-case letters and a digit. By default, a workspace also requires at least 12 characters and a special character; an administrator can switch this stricter rule off.
• Repeated failed sign-ins from one IP address are limited (5 attempts per 15 minutes).
• A sign-in token lasts 30 minutes and is renewed with a refresh token that changes on every use. If an old refresh token is reused, the session is treated as compromised.
• A browser session lasts up to 7 days, or less if the workspace’s inactivity timeout (8 hours by default, set by the administrator) ends it first. A desktop or mobile device enrolled by the workspace can stay signed in for up to 90 days.
• Users can see their active sessions and end any of them. Ending a session takes effect immediately.
• When an administrator deactivates a user, that user’s sessions end and the user can no longer sign in.

Who can see what

• Roles and permissions. Access is granted per action and per type of record (for example, view, create, edit or delete leads), with a scope: own records, a manager’s team, a department or the whole company. Individual fields can be restricted too.
• Modules. Requests are also checked against the modules switched on for the workspace.
• AI agents work through the same checks. Every action an AI agent takes through its tools passes the same workspace, permission, record-scope and module checks as a person’s would.
• API keys are stored only as SHA-256 hashes, have no permissions until they are granted, can expire, and are limited to 600 requests per minute each.
• Files are kept in private storage. Download links are signed and expire after one hour. Users can also create public share links, which work until they are revoked or until the expiry date the user sets.

AI safeguards

• Each APROS AI agent has an autonomy level. At assistant level, every change needs a person’s approval. At semi-autonomous level, the agent can make internal changes, while outbound actions, deletions and other sensitive steps need approval. At autonomous level, only deletions need approval; other actions, including sending email, run without one.
• An AI agent attached to a messaging channel replies to customers automatically in its default mode. The workspace chooses whether to attach one and which mode it uses.
• Text that comes from customers, emails and web pages is marked as untrusted inside AI prompts, to reduce the risk of prompt injection.
• Changes made by APROS AI agents are recorded with the agent run that made them.
• AI clients that you connect to APROS over MCP (such as ChatGPT, Claude or Cursor) are not APROS agents. They act with the permissions you grant them, which can include deleting data, without APROS approvals.

Logs and monitoring

• Audit log. APROS records creations, changes and deletions of CRM records, changes to roles and permissions, API keys, connected accounts, views of stored secrets, exports, merges and AI approvals, with the user or agent, the time, the IP address and the browser. Administrators can read it in Settings. Sign-ins are recorded in the sessions list rather than the audit log.
• Application logs. Our logs automatically remove values whose names indicate a secret, such as tokens, passwords and API keys. They can still contain identifiers, names, email addresses and IP addresses.
• Webhooks. Webhooks from Meta are checked against Meta’s signature before they are accepted, then passed to the right workspace with a signed voucher of our own or, for workspaces not yet moved to vouchers, a shared secret. Telegram webhooks are checked against a secret.

Browser protections

Workspaces send security headers on every page, including Strict-Transport-Security, X-Content-Type-Options: nosniff, a Referrer-Policy, a Permissions-Policy and a Content Security Policy. Outside the Telegram Mini App, pages cannot be embedded in other sites.

Our team

Only Apricode staff who need it for their work have access to our infrastructure. They use it to run the service, to fix faults, to answer support requests and to carry out deletion requests.

What we do not offer yet

So that you can plan around it:

• APROS does not offer two-factor authentication or single sign-on yet.
• APROS has no third-party security certification (such as ISO 27001 or SOC 2) and no published third-party audit.
• We do not run a paid bug bounty.

Your part

• Give people only the roles they need, and review them when someone changes jobs or leaves.
• Use strong, unique passwords, and end sessions you do not recognise.
• Choose AI agent levels carefully, especially for agents that send messages or email.
• Keep API keys secret and give each key only the permissions it needs.

Reporting a vulnerability

If you believe you have found a security vulnerability in APROS, please tell us. We welcome reports from anyone.

How to report

Email hello@apri-code.com with the subject “Security report”. Please include:

• what the vulnerability is and where it is (the address, page or API endpoint);
• the steps to reproduce it, and a proof of concept if you have one;
• what an attacker could do with it;
• how we can reach you for follow-up questions.

Do not include other people’s personal data in your report. If you came across any, tell us what kind of data it was and delete your copy.

What we ask of you

• Test only against your own account or workspace. If you do not have one, write to us first and we will discuss a test workspace.
• Do not access, change or delete data that is not yours, and stop as soon as you have shown the problem.
• Do not disrupt the service: no denial-of-service or load testing, no spam, and no social engineering of our staff or customers.
• Do not test third-party services such as Meta, Google, Cloudflare or Hetzner. Report issues in them to those companies.
• Give us a reasonable time to fix the problem before you disclose it publicly, and agree the date with us.

What we will do

• We aim to acknowledge your report within 5 working days.
• We will keep you informed while we investigate and fix the issue.
• With your permission, we will credit you when we announce the fix.

Safe harbour

If you act in good faith and follow the rules above, we will not take legal action against you or report you to law enforcement for your research. We cannot authorise testing of systems that belong to others.

A machine-readable version of this contact is at /.well-known/security.txt.

Language versions

This document is published in Ukrainian and English, and both versions have the same content. If they differ, the Ukrainian version prevails. This does not limit any right you have under the law that applies to you.