FAQ
If your question is not answered here, please send it to us through the contact form.
BeeHind is a security gateway that combines database access control (DAC), an AI gateway (AI Gateway) and server access control (Server Gateway) in one. As connections from people and applications to databases, AI services and servers pass through the gateway, it verifies identity, allows or blocks them by policy, masks personal data and writes audit records. It consists of the gateway, Management and the desktop agent.
In three ways. First, it is built to install as containers: you install a gateway cluster in each network and manage them all from a single Management. Second, it calculates which source column each cell of a query result came from (lineage), so it masks sensitive columns hidden behind aliases or functions. Third, it provides database access control, an AI gateway and server access control as one product, so you run just one user list, one policy screen, one audit store and one desktop agent.
Yes. Management matches the audit records from DAC, AI Gateway and Server Gateway against detection rules and groups activity such as blocked attempts, bulk sensitive data reads, off-hours access and connections from new IP ranges into review cases per person. Reviewers request justifications from the people concerned and record review results, and on the 1st of each month a monthly inspection report for the previous month is created.
MySQL, MariaDB, PostgreSQL, Oracle and SQL Server. The gateway parses each database's wire protocol directly, so no JDBC driver or database-side installation is needed.
Not with the desktop agent. Users enter the real database address and their usual database account in their database tool, and interception turns on automatically when they sign in to the agent. When connecting without the agent, they point the host and port at the gateway. For PostgreSQL, Oracle and SQL Server they add the issued UUID in front of the database name; MySQL and MariaDB connect to a dedicated port assigned to each service.
They connect directly to the gateway with a connection address issued by an administrator (agentless). For each address, you set the name recorded in the audit log and the IP ranges allowed to connect. Access rules, SQL control and masking apply exactly as they do with the agent.
Two options are available: Management, the gateway, PostgreSQL and Caddy together on a single server with Docker Compose, or the gateway on Linux VMs as a systemd service. Templates for Kubernetes (Helm), AWS and Azure are in progress.
Yes. Management and the gateway make no external network calls at runtime. You bring the images and the install script into the network as one bundle and install from there.
We recommend starting with one production database on a single server. Then add connections that do not use the agent, add gateways for each network and register AI services. Contact us, and we will recommend a setup that fits your environment.
No. The license only checks the term of use. When the term ends, access control and auditing keep running.
It does not store users' database passwords. The gateway does not log in to the database on the client's behalf; it passes the login between the client and the database as is (authentication relay). The database decides whether the password is correct. To set up masking per table column, you can optionally register a lookup account. The password an administrator registers for this account is stored encrypted and sent only to the responsible gateways.
Yes. When needed, the gateway reads the schema to calculate which source column each cell of a query result came from, and masks by position in the result. A statement it cannot work out is rejected with a reason, so no value that should be masked slips through. Values with a fixed format, such as national ID numbers, are found by value pattern in any column.
Yes. The gateway sets up TLS separately on the client side and the database side, so it can inspect and control the content. Certificates are issued by the gateway cluster's certificate authority and rotated automatically. Connections whose content it cannot inspect are rejected, never silently let through.
Running gateways keep making decisions with the policies they already have and keep writing audit records directly to the audit store. They also close sessions whose approval period has ended on their own. Sign-ins and policy changes, however, have to wait until Management is back.
The gateway writes directly to the store you choose: OpenSearch, Elasticsearch or a relational database (PostgreSQL, MySQL, MariaDB, Oracle). Records are linked in a hash chain for integrity verification, and copies go to your SIEM over syslog (RFC 5424) or Splunk HEC.
The desktop agent sends connections to AI services through the gateway. The gateway reads each request, checks the user and the model, and inspects the prompt for personal data and credentials using value patterns. For each pattern, you choose block, mask or detect only. The gateway reads the content of OpenAI-compatible APIs, the Anthropic API and the claude.ai web app.
Yes. Only the gateway uses your company's real key (organization key), and users and applications get virtual keys. The gateway swaps in the organization key when it forwards each request. Virtual keys can be revoked one at a time, and you set models and usage limits per user and service.
Yes. Register an MCP server reached over the network (Streamable HTTP) as a service, and the gateway restricts tool names to an allowlist, checks argument values against value patterns and records the call history by name.
Yes. Register a server's SSH port as a service, and the gateway decides who can log in to which server with which account and records each connection and the commands run. Session screens are recorded for playback in the admin console, and the gateway can log in to servers on the user's behalf with a password or SSH key it stores. Files transferred over SFTP pass only for the operations you allow (upload, download, file changes), and each file is recorded in the audit log. Port forwarding opens only to the destinations (host and port) allowed for each user.
Nothing. The gateway terminates SSH on both sides, so target servers keep using their own sshd. For accounts the gateway logs in to with a stored SSH key, add the public key to authorized_keys. For accounts that log in with certificates, configure sshd once per server to trust the cluster's user CA.
Today this works through SSH port forwarding: forwarding opened with ssh -L or ssh -D is passed only to the destinations (host and port) allowed for each user. Per-user access and audit for direct connections to server ports that do not go through SSH (for example web admin consoles, Redis and RDP) is coming soon.
The screen output and window size sent by the target server are recorded for playback in the admin console. Keystrokes typed by the user are not stored, so passwords are not recorded. File transfers (SFTP) are not part of the recording; each transferred file is recorded in the audit log instead. Recordings are saved to S3-compatible storage.
Tell us which databases, servers and AI services you need to protect and how your network is laid out. We will recommend a setup and a rollout order. You can start with a single server.
'%3e%3crect%20x='-10'%20y='-10'%20width='120'%20height='140'%20fill='%231C1917'/%3e%3crect%20x='-10'%20y='38'%20width='120'%20height='16'%20fill='%23EA580C'/%3e%3crect%20x='-10'%20y='70'%20width='120'%20height='16'%20fill='%23EA580C'/%3e%3cpath%20d='M50%200Q30%2017.5%200.8%2018.7C-1.5%2080%2022%2097%2050%20118C78%2097%20101.5%2080%2099.2%2018.7Q70%2017.5%2050%200Z'%20fill='none'%20stroke='%23FFFFFF'%20stroke-width='18.0'/%3e%3c/g%3e%3cpath%20d='M50%200Q30%2017.5%200.8%2018.7C-1.5%2080%2022%2097%2050%20118C78%2097%20101.5%2080%2099.2%2018.7Q70%2017.5%2050%200Z'%20fill='none'%20stroke='%231C1917'%20stroke-width='7'/%3e%3c/svg%3e){kind=small}
