Security overview | Documentation

Performance Blocks handles sensitive employee performance data: observations, summaries, conversations, objectives, and signals from connected systems. This page describes how the platform protects that data and what controls you have as an organization administrator.

The information here covers the platform as a whole and applies to both Team and Agentic plans unless noted otherwise. For setting up specific controls (SSO, 2FA, notifications), follow the linked sub-articles.

Tenancy model

Every customer is provisioned as an organization. An organization is the top-level boundary for data, configuration, billing, and access.

Logical isolation

Each record in the database is tagged with the owning organization and queries are filtered by that organization on the server before any results are returned. There is no UI path that lets a user query, list, or fetch records belonging to a different organization. This isolation is enforced in three layers:

The session resolves a single organization context for the authenticated user.
Every database access helper requires that organization context to be passed in.
A lint rule rejects code that attempts to read the organization id directly off the session bypassing the helper.

You should treat each organization as its own walled garden. There is no shared "global" storage of customer business data, and there is no cross-tenant lookup feature for end users.

Multiple organizations per user

A single email address can belong to multiple organizations (for example, a consultant who works with two customers). When that user signs in, they choose which organization to enter. The session is then scoped to that organization, and switching organizations requires returning to the picker. Data from one organization is never returned in a request authenticated against another.

Sub-processors and infrastructure

Performance Blocks runs on a small set of cloud sub-processors. Customer data lives inside those services and is not duplicated to third parties beyond what is required to provide the service. See Data and privacy for the current list and for guidance on requesting a Data Processing Agreement (DPA).

Authentication

Authentication is the question of who is making a request. Performance Blocks supports two primary methods.

Email and password

Available on both plans. Users sign up with an email address and password (or accept an invite). Passwords are hashed using a modern, salted, slow hash function before they are stored. The plain-text password is never written to logs or stored in any form.

A magic-link option is supported for first-time signup so that the user does not have to choose a password before verifying their email. After the user signs in once, they can set a password from the account settings page.

Password reset uses a single-use, time-limited token sent to the verified email address. Resetting a password invalidates existing sessions on other devices.

Single sign-on (SSO)

Available on the Agentic plan. SSO lets your organization delegate authentication to your identity provider so that account lifecycle, password policy, and multi-factor enforcement happen in one place. SAML 2.0 and OIDC are both supported. See SSO setup for the full configuration walk-through.

When SSO is enforced, password login is disabled for that organization (with a configurable break-glass admin account). New users provisioned through SSO arrive in the directory with their identity attributes already mapped.

Two-factor authentication (2FA)

Available on both plans. Users can enable a TOTP authenticator app and download backup codes. Org administrators can require 2FA for all members. See Passwords and 2FA.

Sessions

Sessions are issued after successful authentication and are bound to the browser. They are stored in an HTTP-only, secure, same-site cookie so that JavaScript on the page cannot read or exfiltrate them. Sessions can be revoked by the user from the account settings page or by an org administrator from the member list.

Idle and absolute session timeouts are applied. When a session expires, the user is redirected to sign in again with no loss of in-flight unsaved work for most surfaces.

Authorization

Authorization is the question of what an authenticated user is allowed to do. Performance Blocks uses a role-based model with three primary roles plus two override flags.

Roles

Role	Capabilities
`employee`	Manage own observations, conversations, objectives. View shared content. View own profile.
`manager`	Everything `employee` can do, plus team views, summaries, feedback flows, and approving direct reports.
`org_admin`	Full configuration: directory, billing, security, integrations, knowledge base, audit logs.

A user can hold more than one role at a time. Roles are stored as an array per user so that, for example, a manager who is also an org admin can switch context without re-authenticating.

Server-side enforcement

Role checks happen on the server in the load functions and form actions of every protected route. Hiding a UI element on the client is treated only as a UX improvement, never as a security boundary. If a user crafts a request directly to an endpoint they do not have access to, the server returns a 403 and writes an audit log entry.

For organization-scoped routes, the server resolves the user's organization context and verifies membership before any data is read or written. Account-owner-only actions (such as transferring ownership or canceling the subscription) carry an extra check and a confirmation step.

Within an organization, finer-grained sharing controls determine who can see a particular observation, summary, or conversation:

Observations default to private to the author and are shared explicitly with managers, peers, or HR.
Summaries are visible to the subject, their manager, and any administrator who has been granted HR access.
Conversations are private to the participants by default.
Objectives can be marked private, team-visible, or org-visible.

These settings are described in the workflows that produce each artifact; the security model applies the same way for all of them: the requesting user's organization and role are checked, then the per-record sharing list is checked, then the request is satisfied or rejected.

Encryption

In transit

All connections to Performance Blocks use HTTPS with TLS. HTTP requests are redirected to HTTPS at the edge. HSTS is set so that compliant browsers refuse to connect over plain HTTP.

Connections from Performance Blocks to its sub-processors (database, object storage, AI providers, email) are also encrypted in transit.

At rest

Customer data is encrypted at rest by the underlying infrastructure providers using industry-standard symmetric encryption (typically AES-256 or equivalent). Database storage, object storage for file attachments, and key-value caches all encrypt data at rest by default.

Performance Blocks does not currently provide a customer-managed key (CMK / BYOK) option. If your organization has a key-management requirement, contact sales before purchasing.

Secrets and tokens

Application secrets (database credentials, API tokens for sub-processors, signing keys) are held in the platform's secrets store and exposed to the application only through environment bindings at runtime. Customer-visible secrets such as API keys (Agentic) and webhook signing secrets are stored hashed and shown to the user only at the moment of creation.

Application security controls

Several controls are baked into the application code itself.

Input validation

Every form action and API endpoint validates incoming data against a schema before doing anything with it. The validation rejects unexpected fields, type mismatches, and values outside allowed ranges. This is enforced uniformly through a small set of helpers so a developer cannot accidentally ship a route that trusts raw form data.

Validation errors are returned with descriptive messages so the user can fix the input. They are also recorded with their request context for security monitoring; a sustained burst of validation failures from one IP triggers rate limiting.

Cross-site request forgery (CSRF)

State-changing requests must originate from a trusted origin. The application checks the request Origin (or Referer as a fallback) header against a list of allowed origins before processing. Cross-origin POSTs are rejected with a generic error and an audit log entry.

This protection sits in addition to the same-site cookie attribute on the session, so a request from another origin cannot ride on the user's session even if the user is signed in.

Output sanitization

Any user-authored prose that is rendered as HTML (rich-text fields like observations, conversation messages, and summaries) is sanitized server-side. The sanitizer strips <script> tags, JavaScript-bearing attributes (onclick, onerror, javascript: URIs), and any tag not on a small allow list. The same sanitizer is also applied to imported HTML (e.g. content pasted in from external editors).

Rate limiting

Sign-in, password reset, signup, API requests, and Henry chat are rate-limited per user and per IP. Rate limits are configured to allow normal use while making automated abuse expensive. When a limit is hit, the response carries a Retry-After header and the event is recorded.

Dependency management

The application's third-party dependencies are tracked. Critical and high-severity vulnerabilities raised against those dependencies are triaged within one business day and patched as soon as a fix is available, ahead of the next scheduled release if necessary.

Audit logging

Performance Blocks records audit events for sensitive actions: sign-in attempts, role changes, member invitations, integration connect and disconnect, API key creation and revocation, billing changes, content deletion, and admin overrides.

Audit log entries are immutable. They are not editable from the UI and the database foreign keys use a RESTRICT policy so they cannot be cascade-deleted when a referenced user is removed. Org admins can view and export audit logs from Audit logs.

What the audit log captures for each event:

timestamp (UTC)
actor (user id and email at time of event)
action verb
target (record type and id)
IP address and user agent
result (success or failure with reason)

If you connect a SIEM or want a recurring export, talk to your account team about webhook delivery options on the Agentic plan.

Content moderation and AI safety

Performance Blocks is a performance management product, so most of the content is written by employees about employees. The platform applies several controls to keep that content safe.

User-submitted text is sanitized before being rendered. Rich text editors strip script tags and event handlers, and rendered HTML uses the same content security policy as the rest of the app.
File attachments are validated by inspecting their bytes (magic numbers) rather than trusting the file extension. Disallowed file types are rejected at upload.
AI-generated content (summaries, suggested observations, Henry replies) is grounded against the requesting user's own organization data. Henry's knowledge base is scoped to the organization that owns it; it cannot read another organization's data.
The AI provider sub-processor receives prompts and context for the request only. Performance Blocks does not authorize the provider to use customer content to train base models. See Data and privacy for the full statement.

Network and platform

Performance Blocks runs on Cloudflare's global edge platform with a managed PostgreSQL database. Practical implications for IT teams:

DDoS protection and a managed WAF sit in front of the application.
The application has no inbound IP allowlist requirement; outbound integrations from your network only need to reach standard HTTPS endpoints under the performance-blocks.com domain (and sub-domains).
There is no on-premises component. There is nothing to install on employee devices for the core product.
Service availability and incident history are published on the public status page maintained at the company URL.

Browser support

The web app targets the current and previous major versions of Chrome, Edge, Safari, and Firefox. Internet Explorer is not supported. Mobile Safari and Chrome on iOS/Android are tested for the read-and-respond use cases. If your organization standardizes on an older browser, contact your account team before purchasing so we can confirm the relevant features work as expected.

Content security policy

The application sets a strict Content Security Policy that disallows inline scripts, third-party frames, and arbitrary remote script sources. If your organization layers an additional egress proxy, ensure it does not strip or rewrite the CSP header — doing so will break legitimate features (rich-text editing, charting).

Outbound webhooks

Outbound webhooks (Agentic plan) include a signature header so your receiver can verify origin. Verify the signature before acting on the payload; an unsigned or wrongly-signed request should be rejected. The signing secret is set per webhook destination at creation time and can be rotated at any moment.

Logging and monitoring

In addition to the customer-facing audit log, the operations team relies on internal logs to keep the platform healthy.

Application logs record requests at the path level along with status, latency, and minimal context. They do not include the body of user-authored content.
Error reports capture stack traces with scrubbed request context for any unexpected exception. Personal data is removed before submission to the error monitoring sub-processor.
Database query logs are captured for slow queries and sampled traffic so the team can investigate performance regressions.

These internal logs are accessible only to the operations team under role-based access control. They are retained on a short rolling window and never shared with third parties beyond the named sub-processors that ingest them. None of these internal logs are routed to advertising or marketing systems.

Compliance posture

Performance Blocks does not publicly claim a specific certification on this documentation page. For the current state of SOC 2, ISO 27001, GDPR, HIPAA, and other compliance programs, contact your account team or sales contact directly. They can provide:

the current letter of compliance or audit report under NDA,
the latest sub-processor list,
the standard Data Processing Agreement (DPA) for execution,
security questionnaires (SIG, CAIQ) and the most recent penetration test summary.

If your procurement process needs a vendor risk review, request the security packet at the start of the evaluation rather than at contract signing — that gives both sides time to handle questions.

Reporting a security issue

If you discover a vulnerability or have a credible suspicion that customer data is at risk, report it to the security contact published on the company website. Do not file a public GitHub issue and do not attempt to demonstrate the vulnerability against another customer's data.

When you report, please include:

A description of the issue and the affected feature or URL.
Steps to reproduce, including any account or organization ids that you used (your own).
The impact you believe it has.
Whether you have shared the report with anyone else.

Performance Blocks acknowledges security reports within one business day and provides updates as the investigation proceeds. Researchers who report responsibly are credited (with permission) once a fix has been deployed.

Backups and disaster recovery

The managed PostgreSQL provider runs continuous backups with point-in-time recovery within the standard window of the service. Object storage for attachments is replicated within the provider's region by default. Configuration data and secrets are versioned in the platform's secret store.

Recovery objectives reflect the underlying providers' commitments rather than separate Performance Blocks SLAs. For your specific RPO and RTO requirements (e.g. 1-hour RPO, 4-hour RTO), discuss with your account team during evaluation — they can confirm whether the stack as configured for your tenant meets the requirement.

A disaster-recovery test is performed periodically by the operations team. Customers do not need to take any action. Test outcomes can be summarized for customers under NDA on request.

Operational practices

The platform's design only goes so far; routine operational hygiene is what keeps your tenant safe day to day. The recommendations below are the ones that org admins ask about most often.

Member onboarding

When you invite a new member, the invite email contains a single-use token that expires in 7 days. Re-sending an invite revokes the prior token. If a token expires without being accepted, the slot remains in your seat count but no account exists yet — clean up unused invites quarterly to keep the directory tidy.

For senior or sensitive roles, send the invite while you are on a call with the recipient and have them accept on the call. That way you catch a misdirected email immediately.

Member offboarding

Deactivate departing members on or before their last day. Deactivation revokes all sessions, removes the member from the active directory, and prevents new sign-ins, while preserving the audit trail of what they wrote and shared.

If your HRIS integration is connected on the Agentic plan, departures can be propagated automatically — when an employee is marked terminated in the source system, the corresponding Performance Blocks account is deactivated on the next sync. See your HRIS integration page for the sync cadence.

If the user requests permanent deletion under privacy law, follow the procedure in Data and privacy — deactivation and deletion are different operations with different consequences for historical records.

Periodic access review

At least once a quarter, review the list of org_admin users at Settings -> Members. Confirm that every admin still needs the role, and that the count is at least two (so there is no single point of failure for your tenant).

Also review API keys and integrations on the Agentic plan: revoke any key whose owner has left or whose purpose is no longer relevant, and disconnect integrations that are no longer in use.

Incident response readiness

You should know in advance how your organization will respond to a Performance Blocks incident. The minimum:

A documented break-glass admin account (see SSO setup).
A named owner on your side for vendor incidents — the person who will be paged and who will coordinate with your account team.
A predefined channel (Slack, email distribution) for status updates so the operations team can reach you quickly.
A subscription to the public status page so that you know when the platform is having a degraded incident before your members do.

Shared responsibility

Performance Blocks operates the platform; your organization operates the access to the platform. The split looks like this in practice.

Performance Blocks is responsible for	Your organization is responsible for
Patching and maintaining the application and its dependencies.	Inviting and removing the right people; reviewing access regularly.
Encrypting data at rest and in transit.	Setting and enforcing your password and 2FA policy (or delegating to SSO).
Isolating tenants in the database and at the application layer.	Choosing visibility (private/team/org) appropriately on each record.
Monitoring the production environment for security events.	Acting on the audit log; investigating internal anomalies.
Operating the AI provider relationship; preventing model training.	Deciding whether AI is enabled for your tenant; reviewing AI-generated content before publishing.
Notifying you of incidents and material sub-processor changes.	Notifying your members of relevant changes you make to the policy.

Glossary

A short reference for terms used throughout the security documentation.

Tenant / organization: the top-level container for one customer's data, members, and configuration. The two terms are used interchangeably in this documentation.
Member: a user who belongs to an organization, regardless of role.
Role: a label that controls what a member can do. The platform defines employee, manager, and org_admin.
Account owner: the member who originally created the organization or has had ownership transferred to them. Has a small number of additional permissions over org_admin such as transferring ownership and canceling the subscription.
Sub-processor: a third party that processes customer data on Performance Blocks' behalf to deliver the service. See Data and privacy.
Break-glass account: an administrator account intentionally exempt from SSO so that recovery is possible when the IDP is unreachable.
Audit log: the immutable record of sensitive actions taken in the tenant. See Audit logs.
JIT provisioning: just-in-time creation of a user record on first SSO sign-in, as opposed to pre-provisioning via invite or SCIM.

What to do next

Configure SSO if you are on the Agentic plan: SSO setup.
Set password and 2FA policy for your organization: Passwords and 2FA.
Review what data is stored and your rights over it: Data and privacy.
Tune notification routing for your team: Notifications and channels.
Review historical events and admin actions: Audit logs.