EN
Contact sales

Use cases

From a small setup to company-wide

Use cases 1 to 4 cover database access control, use case 5 covers server access control, and 6 to 8 cover AI service use. Use case 9 combines them all, and use case 10 finds anomalous activity in the records of all three paths.

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

Single serverInternal networkManagementSigned policyGatewayIdentityPolicyMaskingRecordsAudit storeEmployee PCDesktop agentmTLS tunnelProduction DBDirect access blocked
  • Controlled connections
  • Policy distribution
  • Audit records
When to use it
Teams whose databases sit on one network; organizations that want to start small and try it first

Flow

  1. A developer signs in to the agent.
  2. The agent intercepts the database tool's connection and sends it to the server's tunnel port.
  3. After its decision, the gateway connects to the database over TLS and relays the login.
  4. Sessions and statements are recorded in PostgreSQL on the same server.

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.
02
DB

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.

Internal networkManagementSigned policyGatewayIP rangePolicyMaskingRecordsAudit storeContractor PCBI toolBatch serverIssued addressProduction DB
  • Controlled connections
  • Policy distribution
  • Audit records
When to use it
Contractor PCs, PCs where software installation is blocked, BI tools such as Tableau and Redash, batch servers

Flow

  1. An administrator selects a service, issues a connection address and sets who it is issued to and the allowed IP range.
  2. The client points its host and port at the gateway. For PostgreSQL, Oracle and SQL Server it adds the issued UUID in front of the database name; MySQL and MariaDB connect to a dedicated port assigned to each service.
  3. The gateway checks the source IP and relays the login to the real database.

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.
03
DB

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.

Internal networkManagementApproverApprovalTime-limited policyGatewayPeriodSQL rulesMaskingRecordsAudit storeContract developerDesktop agentmTLS tunnelProduction DB
  • Controlled connections
  • Policy distribution
  • Audit records
When to use it
Production database queries by contractors and operations support staff; any database with tables that hold personal data

Flow

  1. The contract developer requests access in the agent or the admin console, with a reason and a period.
  2. The request goes through the defined approval steps in order.
  3. Once approved, a policy allowing access for the requested period is deployed to the gateway right away.
  4. When the period ends, new connections are rejected and open sessions are closed.

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.
04
DB

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.

ManagementAudit storeHQ data centerGateway clustersOracleCloudGateway clustersPostgreSQLDevelopment networkGateway clustersDevelopment DBSigned policyRecordsEmployee PCDesktop agentmTLS tunnel
  • Controlled connections
  • Policy distribution
  • Audit records
When to use it
Organizations with databases spread across several networks; deployments with enough connections to need multiple gateways

Flow

  1. Gateway nodes register themselves with Management using an enrollment token and receive only their own cluster's policies.
  2. For each service, the agent gets the address of the responsible cluster and opens a tunnel there.
  3. Every node writes directly to the audit store.

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

Server networkManagementSigned policyGatewayCommandsFilesRecordingRecordsAudit storeRecording storeEmployee PCssh, sftpmTLS tunnelweb-01web-02batch-01Credential injection
  • Controlled connections
  • Policy distribution
  • Audit records
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

Flow

  1. An administrator registers the server's SSH as a service and pins its host key.
  2. A login method is set for each server account, and command templates are attached to access rules.
  3. Users sign in to the agent and then use ssh and sftp as usual.
  4. The gateway checks commands and file transfers and records the session screen.

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

InternetManagementSigned policyGatewayInspectPatternsMaskingRecordsAudit storeEmployee PCAI appmTLS tunnelAI serviceclaude.ai
  • Controlled connections
  • Policy distribution
  • Audit records
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)

Flow

  1. The agent intercepts connections to AI services and sends them to the gateway.
  2. The gateway decrypts TLS, reads the request and checks the user, the model and value patterns.
  3. Only values that match a pattern are masked before sending, and responses are masked with the same patterns.

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.
07
AI

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.

InternetManagementSigned policyGatewayKey checkLimitsKey swapRecordsAudit storeIn-house server appDeveloper toolVirtual keyOpenAIAnthropicAmazon BedrockOrganization key
  • Controlled connections
  • Policy distribution
  • Audit records
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)

Flow

  1. An administrator registers the AI service and the organization key and issues virtual keys.
  2. Applications send requests to the gateway with a virtual key.
  3. The gateway checks rules and limits, swaps in the organization key, forwards the request and tallies token usage.

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.
08
AI

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.

Internal networkManagementAdministratorSelect allowed toolsSigned policyGatewayTool checkArgumentsRecordsAudit storeEmployee PCAI clientmTLS tunnelIn-house MCP server
  • Controlled connections
  • Policy distribution
  • Audit records
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

Flow

  1. An administrator retrieves the MCP server's tool list and selects the tools to allow.
  2. The gateway reads each call and checks the tool name and arguments.
  3. Allowed calls are forwarded; denied calls get an error that states the reason.

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

ManagementIdentity providerIntegrationSigned policyGateway clustersIdentityPolicyMaskingRecordsAudit storeCopySIEMEmployee PCDesktop agentContractor PCIssued addressIn-house server appVirtual keyProduction DBweb-01AI service
  • Controlled connections
  • Policy distribution
  • Audit records
When to use it
Organizations that want to run database access control, server access control and AI usage control together

Flow

  1. Start with one production database on a single server.
  2. Add connections that cannot use the agent with issued connection addresses.
  3. Add a gateway cluster for each network that has databases.
  4. Register servers' SSH as services.
  5. Register AI services and MCP servers as services.

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
DB + Server + AI

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.

DACSQL statements, query resultsAI GatewayPrompts, tool callsServer GatewayCommands, file transfersAudit storeRecords by personAnomaly detectionMatched against detection rulesBlocked attemptsBulk sensitive data readOff-hours accessConnection from a new IPWho did something anomalousReview cases per personJustificationThe person concerned answers in the agentReview resultViolation, normal work, false positiveMonthly inspection reportCreated on the 1st for the previous 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

Flow

  1. An administrator copies detection rules from the nine presets and turns them on.
  2. Management reads the audit store every 10 seconds and groups records that match a rule into review cases per person.
  3. When a reviewer requests a justification, the person concerned answers in the desktop agent.
  4. The reviewer records a review result: violation, normal work or false positive.
  5. On the 1st of each month, the previous month's monthly inspection report is created.

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.

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.

Contact salesFAQ