'%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}
The security gateway for enterprise digital assets
One-stop access policy, auditing, masking and anomaly detection for access to databases, AI services and servers.
orders=> SELECT name AS customer, grade, ssn, phone FROM customers WHERE id = 1024; customer | grade | ssn | phone ----------+-------+-------------+-------------- ******** | VIP | ***-**-**** | 415-555-**** (1 row) · 3 values masked · audit loggedorders=> DELETE FROM customers WHERE id = 1024;✕ BeeHind: DELETE statements are not allowed on the production database (SQL control).
Protects
- Database
- MySQL
- MariaDB
- PostgreSQL
- Oracle
- SQL Server
- AI
- OpenAI
- Anthropic
- Gemini
- DeepSeek
- Azure OpenAI
- Ollama
- vLLM
- MCP
- Server
- SSH
- SFTP
- TCP portsComing soon
Four steps every connection goes through at the gateway
Example: kim.dev@corp querying orders-db
- 01
Verify identity
Identifies the real person behind a shared account.
kim.dev@corp - 02
Decide by policy
Allows or blocks connections, SQL statements, server commands and AI requests by rule.
SELECT allowed - 03
Mask results
Masks personal data in query results and prompts.
415-555-**** - 04
Audit
Records who did what and when, in one audit store.
1 row · logged
What is BeeHind
An all-in-one security gateway that controls database, AI and server access and detects anomalous activity
BeeHind provides DAC (database access control), AI Gateway and Server Gateway as a single product. The three share users, policies and audit records, and anomalous activity is found in the records they gather.
Just one of each, shared by all three
- User list
- Policy screen
- Audit store
- Desktop agent
- Disable a departing employee's account, and database, server and AI access is blocked at once.
- Find one person's SQL statements, server commands and AI questions under one name.
The problem
The path your critical data travels is left unguarded
Databases, servers and AI services are where a company's critical data comes and goes. Yet in many organizations, that path looks like this.
The database only knows the account name
Several developers share one database account, such as app_user. The database log shows only the account name, so you cannot tell who actually connected.
BeeHind identifies the person behind the account with a signed identity assertion attached to every connection.
No record of who queried what
After an incident or during an audit, you have to answer who ran which statement and how many rows they took. Logs scattered across databases make that hard.
BeeHind records each session, statement, decision and row count with the person's name in one audit store.
Personal data shows up on screen as is
Query a production database and national ID numbers and phone numbers appear in full. Few people need the whole value for their work.
BeeHind masks sensitive values before results reach the user. Your databases and applications stay unchanged.
Many people share the root account on servers
Several people log in to servers as root, with a shared account or with the same SSH key. Server logs show only the account name, so you cannot tell who ran which command.
BeeHind routes server access through the same gateway too, and records commands and screens under each person's name.
You don't know which files left your servers
Logs and dump files on production servers are easy to download over SFTP or scp. Nothing records who took what.
BeeHind reads SFTP to let through only the file operations you allow, and records every transferred file in the audit log.
You don't know what goes out to AI tools
Employees paste source code and customer data into AI tools. In-house applications call LLM APIs directly, too.
BeeHind routes AI requests through the same gateway to apply rules and record them.
Products
One product guards three paths
All three products use the same user list, the same policy screens, the same audit store and the same desktop agent. One rule that detects national ID numbers applies to database query results and AI prompts alike.
DAC
Database access control
Parses the database wire protocol directly to control connections, SQL statements and query results.
- Access rules with time and IP restrictions
- SQL control by statement type and pattern
- Lineage-based result masking
- Access requests with multi-step approval
AI Gateway
AI gateway
Decides on and records LLM API calls, the AI apps employees use and MCP tool calls in the same way.
- Virtual keys that protect company API keys
- Model restrictions and usage limits
- Value-pattern masking in prompts and responses
- MCP tool allowlists
Server Gateway
Server access control
Decides who can log in to which server with which account, and records each connection, the commands run and the files transferred.
- Access rules per server and account
- Command control and session recording
- File transfer (SFTP) control
- Port forwarding destination limits
- Login on the user's behalf with stored keys
Anomaly detection
The records of all three paths come down to one question: who did something anomalous, and what did they do?
BeeHind does not stop at blocking and recording. It gathers the audit records left by DAC, AI Gateway and Server Gateway per person and matches them against detection rules. Justification from the person concerned, the review result and the monthly inspection report all follow within the same product.
Built-in detection rules
- Blocked SQL execution attempt
- Restricted server command attempt
- Attempt to send sensitive data to AI
- Denied connection attempts
- Connection attempts blocked at the gateway
- Frequent sensitive data reads
- Bulk sensitive data read
- Off-hours access
- Connection from a new IP range
kim.dev@corp
- Activity
- Bulk sensitive data read
- Condition
- 1,000 or more rows within 60 minutes
- Destination
- orders-db (PostgreSQL)
- Time
- 22:14, outside business hours
- Rows returned
- 1,240 rows
This is an example for illustration. The name and figures are not from real records.
How it works
Every connection passes through the gateway
Below is one example setup. A gateway cluster is installed in each of the production database network, the server network and the DMZ that leads out to the internet, and a single Management instance manages all three clusters. One cluster installed on a single server can also handle all three.
- Controlled connections
- Policy distribution
- Audit records
The desktop agent on employee PCs opens a tunnel to the responsible cluster for each service. Each cluster receives from Management only the signed policies for the services it handles, and writes audit records directly to the audit store. Apps and batch jobs where the agent cannot be installed connect to a cluster directly with an issued address or a virtual key.
Checkpoint
Gateway
A proxy server that runs in front of databases, servers and AI services. It is installed as a cluster in each network, and this is where control and recording actually happen.
Administration
Management
The server that manages policies and accounts. It includes the admin console that administrators use.
Identity
Desktop agent
An app installed on employee PCs. It proves to the gateway who is connecting.
Use cases
Start small, then expand company-wide
Start by controlling one production database from a single server, then use the same product to expand to multi-network setups and AI service control.
- DB
Start with a single server
Install Management and the gateway together on one server, and make that server the only way into the production database. BeeHind takes over the role your bastion host used to play.
- Server
Control server access per person
Register a server's SSH as a service, and who logged in to which server with which account, what they ran and which files they transferred are recorded under their name. The gateway takes over the job of the bastion host.
- AI
Control what leaves through the AI apps employees use
When the desktop agent sends connections to AI services through the gateway, they are decided on, masked and recorded the same way as database connections. Employees do not change any app settings.
- DB + Server + AI
Control databases, servers and AI in one place
Whoever connects, and whether the target is a database, a server or an AI service, you use the same user list, the same policy screens and the same audit store.
Design principles
A product that sits in the path must itself be trustworthy
BeeHind is designed around five principles.
- 01
No central store of database passwords
The gateway does not log in to the database on the user's behalf; it relays the login as is. The database decides whether the password is correct. Passwords kept in one place turn that place into a target.
- 02
When in doubt, block
Statements the gateway cannot parse and connections whose content it cannot see are never treated as allowed. If it cannot work out where a column that must be masked appears in the result, it rejects the statement.
- 03
Control continues when Management is down
Management is not in the connection path. Running gateways keep making decisions with the policies they already have, and they write audit records straight to the audit store.
- 04
Policies apply only after their signature is verified
Management signs each policy, and gateways apply only policies whose signature they have verified. The password of the lookup account that reads schemas and the API keys of AI services never go into a policy. They are encrypted and sent separately, only to the gateways responsible for them.
- 05
Audit records only what actually happened
Anything that was not confirmed is recorded as not confirmed. If the row count could not be determined, it is recorded as "unknown", not 0. Records are linked in a hash chain, so a change to any record in the middle shows up on verification.
Supported environments
Supported databases, servers, AI services and platforms
BeeHind makes no external network calls at runtime, so you can bring it into an air-gapped network.
As of October 2026
- Protected databases
- MySQL, MariaDB, PostgreSQL, Oracle, SQL Server
- Protected AI services
- OpenAI-compatible APIs (OpenAI, Google Gemini, DeepSeek and others), Anthropic API, claude.ai web app, MCP servers (Streamable HTTP)
- AI upstream targets
- Amazon Bedrock, Google Vertex AI, Claude Platform on AWS, Microsoft Foundry, Azure OpenAI
- Server access
- SSH (access control, command control and audit, session recording and playback, port forwarding destination limits), SFTP (file transfer control and per-file audit), TCP ports (coming soon)
- Desktop agent
- macOS 13.4 or later (Apple silicon), Windows 10, Windows 11 (x64)
- Sign-in integration
- LDAP, Active Directory, OIDC, SAML 2.0, SCIM 2.0, passkeys
- Audit store
- OpenSearch, Elasticsearch, relational databases (PostgreSQL, MySQL, MariaDB, Oracle)
- SIEM forwarding
- syslog (RFC 5424), Splunk HEC
- Anomaly detection
- Nine preset detection rules, per-person review and justification, monthly inspection reports, SIEM forwarding
FAQ
Frequently asked questions
What is BeeHind?
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.
How is it different from existing database access control products?
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.
Can it also find out who did something anomalous?
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.
Does the gateway store database passwords?
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.
Does it control server access (SSH, SFTP) too?
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.
How do you control employees' AI use?
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.
See BeeHind in your own environment
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.