Bizy is Bonusly's AI sidekick. It helps people notice good work, write better recognition, and prepare for conversations, using context from Bonusly and from the work tools your team already uses.

This article is written for IT and security teams evaluating Bizy. It covers how connectors authenticate, what Bizy can and cannot see, where data goes, how long it is kept, and what controls administrators have. If you are looking for our compliance reports and certifications, those live at https://bonusly.com/security

Bizy's access model rests on one principle: Bizy sees only what its user can already see. When a member connects a tool, Bizy stores that member's own credential and reads the tool as that member. It does not use a shared service account, nor does it require a bot to be added to your channels, and it cannot reach content the member cannot open themselves.

Bizy inherits your existing permission model in each connected tool rather than introducing a parallel one. Connecting a tool is an individual decision that each member makes for their own account. And an administrator can switch any connector off for the entire organization regardless of what individuals have connected.

Every connector uses the provider's standard authorization flow. Bizy's user clicks to connect, reviews the permissions on the provider's own consent screen, and approves. Bonusly never asks for or stores a password for a connected service.

The authorization handshake is protected against the standard attacks on this kind of flow. Each request carries a single-use 128-bit random value that we store server-side and delete on first use, with a ten-minute expiry, so an authorization response cannot be replayed or grafted onto a different account. The identity of the connecting member comes from that server-side record rather than from anything the browser supplies. Return destinations after connecting are validated and restricted to paths inside Bonusly, so the flow cannot be used to bounce someone to an external site. Where the provider supports it, we use PKCE.

For your workspace administrators, the practical points are that Bizy appears in your provider's normal app approval process, that they can review the requested permissions before approving, and that they can revoke Bizy's access at any time from the provider side independently of anything Bonusly does.

Bizy only reads from connected tools. It does not post, edit, or delete anything in a connected tool.

Three clarifications worth making explicitly, because they come up in nearly every review.

On Slack: Bizy searches as the signed-in member. If a member cannot see a private channel or a direct message in Slack, Bizy cannot see it either. Adding Bizy does not widen anyone's Slack access, and it does not create a bot that sits in your channels.

On GitHub scopes: Slack, Microsoft Teams, and Linear are constrained by read-only authorization scopes, so those tokens are incapable of writing. GitHub's classic OAuth scopes do not include a read-only option that can reach private repositories, so the GitHub grant is broader than the operations Bizy actually performs. Bizy issues only read requests against it, and the repositories in reach are limited to the organizations and repositories selected during setup. If your security policy requires that the credential itself be incapable of writing, we recommend connecting only the repositories you are comfortable exposing, or leaving the GitHub connector disabled for your organization.

On meeting content: Bizy can use notes, summaries, and transcripts only for meetings where the member is a participant. It cannot see meetings they were not part of, and it cannot see a 1:1 partner's private notes. This matches the access rules of the Bonusly 1:1 feature itself.

Bizy's connectors are governed at the organization level, independently of individual member choices.

A Bonusly global administrator can enable or disable any connector for the whole organization from the Bizy administration settings. Disabling a connector immediately stops Bizy from using it and removes the related capabilities from Bizy entirely, so they are not merely refused when invoked.

Disabling a connector organization-wide also deletes every stored credential for that connector across all of your members. Turning a connector off removes Bizy's stored access rather than pausing it behind a setting that could later be flipped back on.

For each connector, we record the current setting along with who last changed it and when, so an administrator can see the present state and its most recent attribution.

Individual members always retain the ability to disconnect a tool themselves, and disconnecting is immediate.

Connector credentials are stored encrypted at rest using libsodium authenticated encryption (XSalsa20-Poly1305). The construction is authenticated, so a stored value that has been tampered with fails to decrypt rather than returning altered data. Encryption keys live in our platform's secret configuration, separate from application source code.

Non-secret fields such as expiry timestamps and the provider's user identifier are stored unencrypted so the system can query them, and we treat the record of which permissions were granted as non-secret as well.

Credentials are filtered out of application logs. Our logging configuration redacts credential-bearing parameters, request URLs are passed through that same filter before being logged, and the code paths that handle authorization responses record only status codes and error identifiers rather than response bodies. Access to internal logs is restricted to authorized personnel.

We maintain tooling to audit and re-encrypt stored credentials, which supports key rotation.

All data is stored and processed in AWS data centers in the United States (US-East region).

Members can disconnect any connector at any time from their Bizy connection settings. Disconnecting deletes Bonusly's stored copy of the credential outright. There is no soft delete and no archived copy, and Bizy immediately loses the ability to read that tool.

Because an OAuth authorization also exists on the provider's side, ending the grant itself is done in the provider's own connected-apps settings. Slack, Microsoft, GitHub, and Linear all support this, and workspace administrators can do it centrally for an entire workspace rather than relying on individuals. If your offboarding process needs the authorization revoked at the source, that provider-side removal is the step to include.

When an administrator disables a connector for the organization, Bonusly deletes every stored credential for that connector across all members, as described above. That is the fastest way to remove Bizy's stored access to a tool for everyone at once.

Deactivating a member in Bonusly disables their Bizy access, and Bizy stops operating on their behalf, including in background processing.

To have a specific individual's stored credentials or Bizy data removed outside these paths, including as part of a data subject access or deletion request, contact Bonusly Support. Requests are reviewed and processed by our support and security teams and handled according to our privacy and security policies.

Bizy is built on large language models from third-party providers. When you ask Bizy a question, your message and any information Bizy retrieves to answer it are sent to a provider for processing.

We use three providers:

Our AI providers do not train their models on Bonusly customer data. You can review their data-handling practices at https://openai.com/enterprise-privacy and https://www.anthropic.com/legal/privacy and https://openrouter.ai/privacy

Bizy retrieves information on demand rather than in bulk. It fetches what it needs to answer the question in front of it, which means a conversation about one colleague's recent work does not cause your Slack history to be uploaded somewhere. Retrieved content is truncated before it enters the model's context, and Bizy works from a limited window of recent conversation rather than your entire history.

For features that are not conversational, such as recognition suggestions and meeting summaries, we send only the specific text needed to produce the result.

Conversations are private to the member who had them. Company administrators cannot browse or search another person's Bizy conversations.

For deletion of specific data outside these windows, contact Bonusly Support.

Bizy enforces company boundaries in the application layer, on every request, in more than one independent way.

Every database query Bizy makes is scoped to the requesting member's company, and the scoping mechanism fails closed: if the company cannot be determined, the query returns nothing rather than everything.

Bizy's analytics capability deserves specific mention, because it is the component that constructs database queries from natural language, and that is exactly the kind of thing a security reviewer should be suspicious of. The system rewrites every generated query to inject the company scope held server-side, and strips any company identifier the model supplied, including identifiers hidden inside nested logical conditions or cross-collection lookups. Collections must be on an allowlist to be queried at all, write operations are rejected outright, and returned fields are restricted to an explicit allowlist that defaults to nothing. Credential and authentication fields are unconditionally excluded.

Requests from the Bizy interface cannot assert their own privileges. Internal parameters that control things like write permission are stripped from anything a client sends, and the acting member and company are always taken from the authenticated session.

Access to sensitive data by Bonusly personnel is restricted by role, and policies are reviewed at least every six months.

Automated authorization checks run on every code change, covering the Bizy interface alongside our web application and public API, and they verify that data access is company-scoped and that write-capable operations are properly gated.

We also run a suite of adversarial tests against our production branch every day, with alerting on failure. These tests attempt the attacks a reviewer would want us to have tried, including asking Bizy for another company's data by explicitly naming that company, attempting to read password hashes and authentication tokens, attempting to write data through a read-only interface, and attempting to execute code inside a database query. The suite fails if any attempt succeeds.

Every inbound message is screened for prompt-injection attempts and passed through content moderation before Bizy acts on it. Content from connected sources that trips the injection screen is discarded before it reaches the model.

Bonusly maintains SOC 2 Type II compliance, GDPR and CCPA compliance, and compliance under the EU-U.S., Swiss-U.S., and UK extension Data Privacy Frameworks. Our security program is overseen by a cross-functional team including our CTO, who also serves as Data Protection Officer.

Individuals can access, update, or delete their personal information on request, and administrators can manage user data directly in the admin console. We notify global administrators by email at least 30 days before any change to our data privacy policies takes effect.

For compliance documentation and downloadable certification reports, visit https://bonusly.com/security

If your IT or security team has questions this article does not answer, contact your Customer Success Manager or reach Bonusly Support at [email protected]. We are happy to talk directly with security reviewers.

Related reading: "Privacy at Bonusly" and "Bizy for Slack" in this Help Center, and our privacy policy at https://bonusly.com/privacy-policy