# BeeHind — A security gateway that protects your company's digital assets

> BeeHind is one gateway for DB, AI and server access. It identifies users behind shared accounts, enforces policy on SQL, commands and AI, masks data and finds anomalies.

https://beehind.me/en · Unvus Co., Ltd. · contact@unvus.com · 2026-11-09

## 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.

- **DAC**: Database access control
- **AI Gateway**: AI service control
- **Server Gateway**: Server access control

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.

Four steps every connection goes through at the gateway:
- **Verify identity**: Identifies the real person behind a shared account.
- **Decide by policy**: Allows or blocks connections, SQL statements, server commands and AI requests by rule.
- **Mask results**: Masks personal data in query results and prompts.
- **Audit**: Records who did what and when, in one audit store.

**Anomaly Detection**: Finds who did something anomalous, and what they did. (Justification → Review result → Monthly inspection report)

### The path your critical data travels is left unguarded

- **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.

### One product guards three paths

- **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**: 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 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)

### 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.

## The security gateway that understands databases deeply (https://beehind.me/en/dac)

The gateway parses the database wire protocol directly to decide who runs which statement on which database. It identifies the person even behind a shared account, masks personal data in query results and records everything. With the desktop agent, users keep the database tools and connection addresses they already use.

Database access control (DAC) is a category of security products that control and audit connections to databases from the middle of the path. Its core functions are user authentication, command control, masking and auditing.

BeeHind's DAC parses the database wire protocol directly. That lets it control SQL statements without changes to your databases or applications, and mask sensitive columns even when they hide behind aliases or functions.

Because it is an inline proxy that sits between clients and databases, it can reject connections, block statements and mask results, unlike monitoring-only approaches. Configure the database firewall to accept connections only from the gateway, and the gateway becomes the only way in.

### Two paths, depending on who connects

| Who connects | Desktop agent | How it reaches the gateway | How the user is identified |
| --- | --- | --- | --- |
| Database tools on employee PCs | Required | The agent intercepts the connection and sends it through an mTLS tunnel | Signed identity assertion |
| Contractor PCs, BI tools | Not required | Connects directly with an issued connection address | Name assigned to the address and allowed IP range |
| Batch servers | Not required | Connects directly with an issued connection address | Allowed IP range |

### Decisions at every step, from connection to statement

- **Access rules**: For each combination of user or group, service and database account, choose allow, deny or approval required.
- **Connection restrictions**: Set the allowed IP ranges, days of the week and hours. When the allowed time ends, open sessions are closed too.
- **Database account control**: Define which database accounts each service may use. Any other account is rejected before it reaches the database.
- **SQL control**: Block execution by statement type, such as DELETE or DROP, or by regular expression pattern. Test a rule against sample statements before you save it.
- **Approval**: Accept access requests, route them through multi-step approval and allow access only for the requested period. Sessions are closed when the period ends.
- **Session management**: View open sessions and force them to close per session or per person. Disabling a departing employee's account closes their sessions as well.

### Masks columns even behind aliases and functions

The gateway masks sensitive values in the results the database returns before passing them to the user. Your databases and applications stay unchanged.

- **Sensitive fields**: For values without a fixed format, such as names and addresses. Select customers.name as a sensitive field, and the gateway follows the result back to the source column (lineage) to mask it, even if it is aliased as customer or wrapped in a function.
- **Value patterns**: Values with a fixed format, such as national ID numbers, card numbers and phone numbers, are found and masked in any column. Twelve built-in patterns cover personal data and credentials, and you can add your own as regular expressions.
- A statement whose source columns cannot be worked out is not executed; it is rejected with a reason. Values that should be masked are never let through.
- Who sees masked values is set per user and group. Masked characters are replaced with *, and the length stays the same.

### Controls encrypted connections by inspecting their content

The gateway sets up TLS separately on the client side and the database side. The gateway cluster's certificate authority (cluster CA) issues the certificates and rotates them automatically before they expire. Connections whose content cannot be inspected are rejected by default.

### Records who did what, by name

- **What is recorded**: Session start and end, executed statements, allow and deny decisions, row counts, masked items, and the user's name along with where that name came from.
- **Storage**: Records go to OpenSearch, Elasticsearch or a relational database. If the store does not respond, records are buffered on disk and sent again later.
- **Integrity**: Records are linked in a hash chain and verified in the admin console. Changing or deleting a record in the middle shows up.
- **Access to audit data**: Personal data is masked on the audit screens too. People with permission open the original one record at a time after entering a reason, and that access is recorded as well.
- **SIEM integration**: Copies are sent over syslog (RFC 5424) and Splunk HEC.

### Supported databases

- MySQL: Agent, agentless (dedicated port per service)
- MariaDB: Agent, agentless (dedicated port per service)
- PostgreSQL: Agent, agentless (shared port)
- Oracle: Agent, agentless (shared port), TLS (TCPS)
- SQL Server: Agent, agentless (shared port)

### Known limitations

- Connections that use Oracle Native Network Encryption cannot be inspected, so they cannot be controlled. Configure clients to connect over TLS (TCPS) instead.
- Results cannot be masked in sessions from Oracle OCI-based clients. In those sessions, queries that require masking are blocked.
- SQL Server TDS 8.0 strict encryption is not supported yet.
- The gateway becomes the only way in only after the database firewall closes all other sources.

## Control data going to AI at the same checkpoint (https://beehind.me/en/ai-gateway)

The gateway decides on, masks and records the AI apps employees use, LLM API calls from in-house apps and developer tools, and even the MCP tools that AI calls. The value patterns you apply to databases work on AI requests as is.

An AI gateway is a proxy that sits between an organization and AI services to inspect requests, manage keys and record usage.

BeeHind's AI Gateway uses the same gateway, the same accounts and the same audit store as DAC and Server Gateway. The SQL statements, server commands and questions to AI from the same person are found under the same name.

### The right control for each way you use AI

- **AI apps employees use** — AI apps that employees sign in to with their own accounts on their PCs (for example, the Claude desktop app). The desktop agent sends connections to the AI service through the gateway. Employees do not change any app settings. (How the user is identified: Signed identity assertion)
- **LLM calls from in-house apps and developer tools** — In-house services and batch jobs that call LLM APIs; Claude Code, Codex, Gemini CLI. Point the API address at the gateway and replace the API key with a virtual key. The gateway swaps in your company's real key (organization key) when it forwards the request. (How the user is identified: Virtual key)
- **In-house tools called by AI (MCP)** — Organizations that expose in-house systems as MCP servers. Register the MCP server as a service and set an allowlist per tool call. Values in arguments are checked against value patterns too. (How the user is identified: Signed identity assertion)

### Features that control AI use

- **Virtual keys**: Only the gateway uses your company's real API keys; users and applications get virtual keys. Virtual keys can be revoked one at a time.
- **Model restrictions**: Block models whose token price exceeds a limit and models you have decided not to use. Set which models each user and group can use.
- **Content inspection**: Apply value patterns to prompts and streamed responses. Credential patterns such as AWS access keys, private keys and database connection strings are built in.
- **Usage limits**: Limit daily or monthly token and request counts per user and service.
- **Tool control**: Restrict MCP server tool calls to an allowlist and check arguments against value patterns.
- **Upstream format conversion**: Converts the request format when sending to cloud model services such as Amazon Bedrock and Google Vertex AI. When you move to another upstream target, application settings stay the same.
- **In-house model servers**: Register in-house model servers such as vLLM and Ollama as OpenAI-compatible services and inspect them with the same rules.
- **Config files for each tool**: The admin console generates config files for Claude Code, Codex, Gemini CLI and SDKs.

### Supported AI services

- Content read and controlled: OpenAI-compatible APIs (OpenAI, Google Gemini, DeepSeek and others), Anthropic API, claude.ai web app, MCP servers (Streamable HTTP)
- Upstream targets: Amazon Bedrock, Google Vertex AI, Claude Platform on AWS, Microsoft Foundry, Azure OpenAI
- In-house model servers: vLLM, Ollama and other OpenAI-compatible servers
- Developer tools: Claude Code, Codex, Gemini CLI, SDKs

### Known limitations

- For services not on the list and apps that pin certificates, the gateway cannot read the content and records only that a connection was made.
- If PCs have a direct route to AI services, users can turn off the agent and bypass the gateway. Close that route at the firewall.
- Usage limits are tallied every few seconds, so usage between tallies can go over the limit. They are a cost-management tool, not a security control.
- Masking is not yet applied to results returned by MCP tools.

## Records who did what on your servers, by name (https://beehind.me/en/server-gateway)

The gateway terminates SSH on both sides to decide who logs in to which server with which account, controls the commands run and the files transferred, and records the session screen. Users keep using ssh and sftp as usual.

Server Gateway is a server access control gateway that sits in the path people take to reach servers over SSH. It takes over the job of a bastion host (jump server) and also records who connected and what they did.

BeeHind terminates SSH on both sides. The gateway accepts the user's SSH connection and makes its own separate connection to the target server. That lets it read and decide on commands, file transfers and port forwarding inside encrypted SSH. Nothing is installed on target servers.

It uses the same user list, the same policy screens and the same audit store as DAC and AI Gateway.

### Choose a login method for each server account

| Method | What the user does | What the gateway does | Setup on the target server |
| --- | --- | --- | --- |
| User input | Enters the server account's password | Passes what was entered to the target server as is, without storing it | Nothing |
| Stored password | Nothing | Logs in on the user's behalf with a stored password | Nothing |
| Stored SSH key | Nothing | Logs in on the user's behalf with a stored SSH key | Add the public key to authorized_keys for each account |
| Certificate | Nothing | Creates a short-lived certificate for each connection and logs in on the user's behalf | Once per server, configure it to trust the cluster's user CA |
The way into servers is the desktop agent's tunnel. No separate port is opened for server access, and users run ssh with the real server address and server account.

### Decisions from connection to command and file

- **Access rules**: Allow or deny connections for each combination of user or group, server and server account. You can also set the IP ranges and hours allowed to connect.
- **Command control**: Use command templates to define the commands to block or allow. Both commands run as ssh server command and commands typed into an interactive shell are checked.
- **Commands that need approval**: Commands needed only during maintenance, such as service restarts or sudo, are blocked normally and can run only while a command permission is approved.
- **File control**: Reads SFTP and lets through only the operations you allow among upload, download and file changes. scp and rsync are checked by the same rules, and each transferred file is recorded in the audit log.
- **Port forwarding**: Forwarding opened with ssh -L or ssh -D goes only to the destinations (host and port) allowed for each user. It is off by default, and reverse forwarding (ssh -R) is rejected.
- **Session recording**: Records the session screen for playback in the admin console. Keystrokes typed by the user are not stored, so passwords never end up in recordings.
- **Session management**: Force open sessions to close. Revoking an access rule closes its open sessions too, and you can set an idle timeout and a maximum session length.
- **Host key verification**: The target server's host key is pinned when the server is registered and checked on every connection. The agent registers the cluster's host CA on the PC, so users are never asked to confirm a fingerprint.

### Supported scope

- Connection path: Tunnel from the desktop agent (macOS, Windows)
- Tested tools: OpenSSH ssh, sftp, scp, rsync
- Login methods: User input, stored password, stored SSH key, certificate
- File transfer: SFTP (version 3), scp, rsync
- Audit: Connections, commands, file transfers, port forwarding, session recordings
- Recording store: S3-compatible storage
- TCP ports (coming soon): We are preparing per-user access to server ports that do not go through SSH (for example web admin consoles, Redis and RDP), with a record of each connection. The gateway does not interpret the content of these connections.

### Known limitations

- Commands typed into an interactive shell are checked by reading the line drawn on screen. Unlike commands run as ssh server command, this is an estimate.
- Block-list command templates alone cannot stop files from moving in and out through the shell.
- The content of forwarded connections is not inspected. SQL sent to a database over a forwarded connection is not recorded in the audit log, so register databases as DAC services.
- Secrets shown on screen remain in the recording as is.
- Agentless connections, web terminals, RDP, Telnet and FTP are not supported yet.

## Finds who did something anomalous and asks them for a justification (https://beehind.me/en/anomaly-detection)

Audit records from all three paths are gathered per person and matched against detection rules. Each flagged activity becomes a review case for that person, goes through the person's justification and the reviewer's review result, and is kept in the monthly inspection report.

Anomaly detection finds activity in audit records that breaks policy or departs from the usual, groups it by person and lets a reviewer reach a conclusion.

Management reads the audit store every 10 seconds and matches the records against the detection rules that are turned on. SQL statements and query results from DAC, commands and file transfers from Server Gateway and prompts from AI Gateway are all recorded under the same person's name, so you see together what one person did across all three paths.

It does not stop at detection. It continues with a justification that asks the person concerned for the reason, the reviewer's review result, exceptions for activity confirmed as normal work and a monthly inspection report that brings together the month's inspections. You do not need to connect a separate analytics product.

### Start with nine presets

Each rule starts as a copy of a preset. You then set its scope (destinations, people, groups), count threshold, severity and automatic justification request. Every value is selected from a list, so a single typo cannot silently disable a rule.

| Detection rule | Product | Default condition | Severity |
| --- | --- | --- | --- |
| Blocked SQL execution attempt | DAC | Each occurrence | Medium |
| Restricted server command attempt | Server Gateway | Each occurrence | Medium |
| Attempt to send sensitive data to AI | AI Gateway | Each occurrence | High |
| Denied connection attempts | DAC, AI Gateway, Server Gateway | 3 or more within 60 minutes | Medium |
| Connection attempts blocked at the gateway | All products | 3 or more within 60 minutes | Medium |
| Frequent sensitive data reads | DAC | 100 or more within 60 minutes | Medium |
| Bulk sensitive data read | DAC | 1,000 or more rows within 60 minutes | High |
| Off-hours access | DAC, Server Gateway | Each occurrence | Medium |
| Connection from a new IP range | DAC, Server Gateway | Each occurrence (after 14 days of learning per person) | Medium |
Every preset automatically sends a justification request to the person concerned when a review case is created. Rules apply only to records created after they are turned on. Business hours, public holidays and the learning period for connection sources are set in the detection settings.

### Record a conclusion for every detected activity

- **Review case**: Detections with the same rule, person, destination and day are grouped into one case. The original audit content (SQL, prompts) is not copied; only a summary is kept.
- **Justification request**: Asks the person concerned why they did it. The person sees it as a "justification request", not as "anomalous activity".
- **Justification**: In the desktop agent, the person concerned sees the statement they ran and answers with a category (part of my work, testing, mistake, instructed or approved, I did not do this and others) and an explanation.
- **Justification approval**: When enabled, the person's justification approver checks the justification in the agent. This check is supporting evidence; the reviewer makes the conclusion.
- **Review result**: Select Violation, Normal work, False positive (rule issue), False positive (data issue) or Undetermined, and add a comment. For a violation, also record the action taken.
- **Exception**: For activity confirmed as normal work, set a scope and an expiry date, and it is not detected again until then.

### Monthly inspection report

On the 1st of each month, BeeHind creates a report that brings together the previous month's detections, reviews, justifications and exceptions. It serves as evidence of the monthly access-log inspection required by Article 8(2) of Korea's Standards for Ensuring the Safety of Personal Information. Reports are never edited; generating a report again creates a new one.

- Detection: number of review cases and people, counts by rule and by severity
- Review: counts by result, and the actions taken on cases reviewed as violations
- Justification: requested, submitted, submitted late, denied by the person, not submitted
- Exceptions: newly created, revoked, currently in effect
- Periods not inspected: audit records that could not be verified, and breaks in the chain

### What it works with

- Records read: Audit records from DAC, AI Gateway and Server Gateway (OpenSearch, Elasticsearch, relational databases)
- Justification answers: Desktop agent (macOS, Windows)
- SIEM forwarding: Review case creation, justification submission, justification approval, review results, reopening (syslog, Splunk HEC)
- History: Every change to rules, reviews, justifications and exceptions is sealed in a hash chain and verified once a day
- Notifications: When the person answers "I did not do this", the reviewer is emailed right away

### Known limitations

- Rules apply only to records created after they are turned on. Past records are not detected retroactively.
- For services that do not record plain-text reads, reads of sensitive fields without masking are not recorded, so they are not detected.
- Off-hours access and connections from a new IP range are checked only in the records of people who have an account.
- Records of connections made without the agent (issued connection addresses, virtual keys) do not trigger automatic justification requests. Reviewers can still send a request themselves.
- Justifications can be requested only from people who signed in to the desktop agent within the last 90 days.

## Three components form the checkpoint (https://beehind.me/en/how-it-works)

The gateway controls and records, Management sets policies and sends them out, and the desktop agent proves who is connecting. Management is not in the connection path.

### Gateway

A proxy server that runs in front of databases, servers and AI services. This is where control and recording actually happen.

- Parses the database wire protocol directly to read connections, SQL statements and query results.
- Terminates SSH on both sides to read server commands and file transfers.
- Allows or blocks connections, statements, commands and AI requests by policy.
- Masks sensitive values in query results and AI requests.
- Writes audit records directly to the audit store.
- Where it runs: On the networks that hold the databases and servers it protects, and at the exit to AI services. Create a cluster for each network and run as many instances as you need.

### Management

The server that manages policies and accounts. It includes the admin console, the web interface administrators use.

- Manages users and groups and integrates with your corporate identity systems.
- Registers the services to protect and defines access rules, masking and SQL control.
- Signs policies and deploys them to the responsible gateways.
- Runs approvals for access requests and shows audit records.
- Detects anomalous activity in audit records and runs justification and review.
- Where it runs: A single instance, installed where gateways and agents can reach it.

### Desktop agent

An app installed on employee PCs. It proves to the gateway who is connecting.

- Signs in with a company account and receives a signed identity assertion.
- Intercepts only connections to registered services and sends them to the responsible gateway.
- Attaches an identity assertion to every connection, so people stay distinguishable even when they share a database account.
- Shows the services the user can connect to and accepts access requests.
- Where it runs: Employee PCs. macOS and Windows are supported.

### How a single connection is handled

1. **Sign-in**: The user signs in to the desktop agent with a company account. Management returns the list of services the user can connect to and a signed identity assertion.
2. **Connection attempt**: The user enters the real database address and database account in the database tool and connects. The agent intercepts only connections to registered services.
3. **Tunnel**: The agent opens a mutual TLS (mTLS) tunnel to the responsible gateway and sends the identity assertion and the original destination first.
4. **Connection decision**: The gateway decides whether this person may connect to this service with this database account, taking location and time of day into account. If the connection is not allowed, it is closed before it reaches the database.
5. **Login relay**: The gateway connects to the database and relays the login exchange as is. The database decides whether the password is correct.
6. **SQL control**: Each time a statement runs, the gateway checks whether it is a forbidden type of statement.
7. **Result masking**: The gateway masks sensitive values in the results the database returns before passing them to the user.
8. **Audit logging**: The session, statements, decisions and row counts are written to the audit store with the user's name.

While the connection stays open, the gateway re-evaluates it periodically. When the allowed time ends or a policy changes, it closes the open session.

### From a single server to clusters across networks

- **Single server (Docker Compose)** (Available): Installs Management, the gateway, PostgreSQL and Caddy on one host. An install script handles installation, version changes and rollback. For air-gapped networks, everything comes in one bundle.
- **Gateway on a Linux VM (systemd)** (Available): Installs gateway nodes on VMs without containers. When you start an upgrade from the admin console, each node downloads the new version and replaces itself.
- **Kubernetes (Helm), AWS, Azure** (In progress): The install templates are being finalized for deployment to real environments.

### A product that sits in the path must itself be trustworthy

- **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.
- **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.
- **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.
- **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.
- **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 databases, servers, AI services and platforms (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

### Useful terms

- **Gateway cluster**: A group of gateway nodes that handle the same services together. You create a cluster for each network and assign a responsible cluster to each service.
- **Interception**: The desktop agent catches connections to registered services on the PC and sends them to the gateway. Users do not change connection addresses.
- **Agentless**: A path where clients connect directly to the gateway with an issued connection address, without the agent. Used by contractor PCs, BI tools and batch servers.
- **Identity assertion**: A short-lived proof that Management signs and issues to a signed-in user. The gateway verifies the signature to identify the person.
- **Authentication relay**: 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. The database checks the password.
- **Credential injection**: The gateway logs in to the target server on the user's behalf with a stored password or SSH key, or with a certificate created for each connection. Users do not need to know the server's password.
- **TLS termination**: The gateway decrypts an encrypted connection, inspects the content and re-encrypts it before sending it to the database.
- **Lineage**: A calculation of which source column each cell of a query result came from. It is how the gateway finds sensitive fields hidden behind aliases or functions.
- **Value pattern**: A rule that finds values with a fixed format, such as national ID numbers and card numbers. Used for both database results and AI requests.
- **Virtual key**: A key that BeeHind issues to users and applications. When the gateway forwards a request, it swaps in your company's real key (organization key).
- **Fail-closed**: Denying, rather than allowing, when a decision cannot be made. Another name for the "when in doubt, block" principle.

## From a small setup to company-wide (https://beehind.me/en/use-cases)

### 1. 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.

Management, the gateway and the audit store are installed together on one server. The agent on employee PCs connects to the gateway through an mTLS tunnel, and the gateway relays the connection to the production database on the internal network. Direct routes from PCs to the database are closed at the firewall.

- When to use it: Teams whose databases sit on one network; organizations that want to start small and try it first
- What you get: Who ran which statement on the production database, and when, is recorded by name. Masking, SQL control and access rules apply right away. You no longer hand out SSH accounts on a bastion host to developers.
- Good to know: The server becomes the checkpoint only after the database firewall closes all other sources. Set up a separate emergency access path for outages.

### 2. Connect from places where the agent cannot be installed

Contractor PCs, BI tools and batch servers connect directly to the gateway with a connection address issued by an administrator. Connections without the agent get the same policies and audit.

Contractor PCs, BI tools and batch servers connect directly to the gateway with issued connection addresses. The gateway checks the source IP range, decides by policy and relays the connection to the production database.

- When to use it: Contractor PCs, PCs where software installation is blocked, BI tools such as Tableau and Redash, batch servers
- What you get: Adding people does not require opening the firewall again. Once an address is revoked, it can no longer be used to connect.
- Good to know: The issued-to name is what appears in the audit log; it does not verify identity. What actually restricts connections is the allowed IP range. Use the agent for connections where you must tell people apart reliably.

### 3. Handle personal data in production databases safely

Keep contract developers out of the production database by default and open access only for an approved period. Even while access is open, personal data is masked and statements that change data are blocked.

When an approver approves a contract developer's access request, Management sends a time-limited policy to the gateway. The gateway checks the period, controls SQL and masks results, then relays the connection to the production database.

- When to use it: Production database queries by contractors and operations support staff; any database with tables that hold personal data
- What you get: Access goes only to the people who need it, only for as long as they need it. Personal data in query results is masked, and every statement is recorded.
- Good to know: The gateway checks expiry on its own. Sessions are closed even when Management is down.

### 4. Install separate gateways in a multi-network enterprise

When databases are spread across a headquarters data center, the cloud and a development network, install a gateway cluster in each network and manage them all from one Management instance.

A gateway cluster is installed in each of the headquarters data center, the cloud and the development network, and one Management instance manages them. The agent on employee PCs opens a tunnel to the responsible cluster for each service, and each cluster writes directly to the audit store.

- When to use it: Organizations with databases spread across several networks; deployments with enough connections to need multiple gateways
- What you get: Policies and audit are managed in one place, whichever network a database is on. Gateways on the development network hold no policies or connection details for production databases. Start a new node with the same enrollment token, and it gets to work right away.
- Good to know: The firewall only needs to allow outbound traffic from the gateways to Management. Management runs as a single instance.

### 5. 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.

ssh and sftp connections from employee PCs pass through the gateway to the servers on the server network. The gateway checks commands and file transfers, logs in on the user's behalf with stored keys and saves the session screen to the recording store.

- When to use it: Teams where several people log in to servers as root or with shared accounts; cases where contractors need access to production servers
- What you get: People behind shared accounts are recorded separately. With credential injection, you do not hand out server passwords or SSH keys to users. Dangerous commands are blocked, and commands needed only for maintenance can run only while approved.
- Good to know: The gateway becomes the checkpoint only after the server firewall closes SSH from every other source. Agentless connections and web terminals are not supported yet.

### 6. 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.

The agent sends requests from AI apps on employee PCs to the gateway. The gateway reads each request, checks it against value patterns and masks matching values before forwarding it to the AI service on the internet.

- When to use it: Organizations whose employees sign in to AI apps on their PCs with their own accounts (for example, the Claude desktop app)
- What you get: You see AI app usage per person. Personal data and credentials are masked or blocked before they leave.
- Good to know: Charges still go to the signed-in account. The gateway does not store employees' sign-in credentials. Close direct routes from PCs to AI services at the firewall.

### 7. Route LLM calls from in-house apps and developer tools through company keys

Only the gateway uses your company's real keys (organization keys); users and applications get virtual keys. See in one place who used which model and how much.

In-house server apps and developer tools call the gateway with virtual keys. The gateway checks the virtual key and usage limits, swaps in the organization key and sends the request to OpenAI, Anthropic or Amazon Bedrock.

- When to use it: In-house services and batch jobs that call LLM APIs; developer tools that use API keys (Claude Code, Codex, Gemini CLI)
- What you get: The organization key is never handed out to anyone. Block expensive models and set usage limits per user. Moving the upstream target to Amazon Bedrock leaves application settings unchanged.
- Good to know: Clients must trust the gateway cluster's root CA.

### 8. Control the in-house tools AI calls

Register MCP servers as services and control them per tool call. Decide, person by person, what AI can do in your in-house systems.

When an administrator selects the tools to allow, Management sends the policy to the gateway. When an AI client on an employee PC calls a tool on the in-house MCP server, the gateway checks the tool and its arguments before forwarding the call.

- When to use it: Organizations that expose in-house systems as MCP servers; cases where what AI can do must differ from person to person
- What you get: Allow lookup tools and block delete tools. Tool call history is recorded with the person's name.
- Good to know: An empty allowlist allows all tools. MCP servers that run only on the PC are out of scope.

### 9. 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.

One Management instance, integrated with the corporate identity provider, manages several gateway clusters. Connections from employee PCs, contractors, batch servers and in-house server apps all pass through the gateway clusters to databases, servers and AI services. Audit records gather in one store, and copies go to the SIEM.

- When to use it: Organizations that want to run database access control, server access control and AI usage control together
- What you get: Disabling a departing employee's account closes their open database sessions and blocks their AI use. One value pattern works for both database results and AI prompts. The same person's SQL statements, server commands and AI questions are found under the same name.
- Good to know: Copies of audit records are sent to your SIEM.

### 10. Find who did something anomalous and collect justifications

Finds activity that matches detection rules in the audit records of all three paths, groups it by person, collects justifications from the people concerned and records review results. Each month's inspection is kept as a monthly inspection report.

Audit records from DAC, AI Gateway and Server Gateway gather in the audit store, and anomaly detection in Management matches them against detection rules to create review cases per person. The person concerned answers with a justification in the agent, the reviewer records a review result, and an inspection report is created every month.

- When to use it: Organizations that must inspect personal data access logs at least once a month; cases where blocking is not enough and you need to confirm who did it and why
- What you get: See blocked attempts, bulk reads, off-hours access and connections from new IP ranges per person. Activity confirmed as normal work is handled as an exception until its expiry date, so reviews do not pile up. The monthly inspection report also shows which periods could not be inspected.
- Good to know: Rules apply only to records created after they are turned on. Justifications are collected only through the desktop agent, not by email.

## Frequently asked questions (https://beehind.me/en/faq)

### 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.

### Which databases are supported?

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.

### Do users have to change their database tool settings?

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.

### What about PCs, BI tools and batch servers where the agent cannot be installed?

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.

### How is it installed?

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.

### Can it be installed in an air-gapped network?

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.

### How do we get started?

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.

### Will connections be blocked when the license expires?

No. The license only checks the term of use. When the term ends, access control and auditing keep running.

### 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.

### Are columns wrapped in aliases or functions masked too?

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.

### Can it control encrypted (TLS) database connections?

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.

### What happens if Management goes down?

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.

### Where are audit records stored?

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.

### 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.

### Can we use the company's LLM API keys without handing them out to employees?

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.

### Does it control MCP tool calls too?

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.

### 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.

### What do we need to install on target servers?

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.

### Can I allow ports other than SSH per user?

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.

### What does a session recording contain?

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.

## Talk to us about adopting BeeHind

https://beehind.me/en/contact · contact@unvus.com