Technical & security overview

For IT, security, and procurement teams evaluating Workerbee: how users authenticate, where data lives, how tenants are isolated, and what gets recorded.

Authentication & authorization

How a user signs in depends on the surface. The LLM connectors (Claude, ChatGPT, Gemini) use OAuth. Code calling the API or MCP Server uses a project API key.

• Protocol (LLM connectors). OAuth 2.0 authorization-code flow. On first use, the user is redirected to Workerbee’s hosted sign-in and an explicit consent page. Users never copy or paste API keys or tokens.
• Tokens. Short-lived signed bearer access tokens (about one hour) with refresh tokens. The connection can be revoked at any time from the user’s assistant settings, or by Workerbee support.
• API keys (API and MCP Server). Created in the Intelligence Console and scoped to a project. Keys can be rotated or revoked from the same screen at any time — see API Key.
• Per-user identity. Every connector session is tied to an individual, named Workerbee account. The connector holds no shared or service credentials.
• Tenant scoping. The user’s company is a claim in the token. Every tool call is evaluated against that company, so a user can never read or affect another company’s roles, candidates, or results.
• Plan and entitlement gating. Tool availability is also filtered server-side by the customer’s plan and enabled modules. A tool that isn’t in the plan returns a clear denial, not degraded data.

Data handling

• What flows in. Job descriptions, résumés/CVs, and workforce data the customer chooses to submit, plus the user’s questions and feedback. Nothing is collected from the user’s machine or AI assistant conversation beyond what the user explicitly provides to Workerbee tools.
• Where it lives. Workerbee runs on Google Cloud in North American regions, and serves North American customers.
• Candidate privacy. External candidate identities stay anonymized until the candidate consents to be introduced to the customer.
• Protected characteristics. Workerbee’s structured schema has no fields for protected-class attributes. That data is not collected, by design.
• Tenant isolation. Each customer’s data is scoped to its own tenant. Any cross-customer intelligence, such as market benchmarks, is limited to anonymized aggregates. Individual records never cross tenant boundaries.
• Query safety. Conversation text is never interpolated into database queries. Questions are mapped to a closed set of typed, parameterized query primitives, with result caps and per-tenant rate limits.

Auditability

Every ranking and talent decision is backed by a decision audit record the customer can retrieve at any time with get_decision_audit. It covers how the Success Profile was defined, how candidates were scored, and what changed when.

Talent-intelligence answers are also logged server-side — the question, the result scope, and volume — for abuse detection and support.

Questions and contact

For security questionnaires, data-processing terms, and architecture deep-dives, contact your Workerbee account team, or file a request in-product with create_support_ticket. You can also email support@workerbee.ai.