Security & controls

Your work.
Protected by design.

Workspace access controls protect customer records. Supported governed actions need authority before they run. Your team can inspect the result. Powered by Fibric.

Powered by Fibric.

Real data only Governed actions Data isolation Action records
Internal record action · example Example
Action Update a work item
Target work item 5821 · customer follow-up
Workspace Northwind Goods
Context available conversation and work record
Authority authorized workspace role
Result internal record updated
✓ Governed action · operation #RB-90417
01 Real data only

A clear view of what’s known.

Live customer views use connected records. If a result is unavailable, it stays unavailable. Placeholder values cannot pass as measured data.

✓Source-aware results. The data layer distinguishes connected results from fallback values in live customer views.
✓Missing means missing. If a result is unavailable, the workspace shows the gap.
✓Evidence to inspect. Letra helps your team investigate available records and revisit saved findings.
Connected results · example Sample data
MetricSource
Shipping performance connected records · measured connected
Scored conversations available scoring results · measured connected
Churn rate no connected source · not shown unavailable

An unavailable source leaves a visible gap; it does not become a measured result.

02 Governed actions · fail-closed

Permission before action.

Fibric checks supported governed actions against their required authority and configured policy. Missing permission or a failed trust check blocks execution. Human approval applies where required for that action.

✓Scope before action. The capability, connector, and workspace permissions define what an action can change.
✓Approval where required. Configured approval requirements keep the next step with an authorized person.
✓Protection against repeats. Single-flight coordinates work on the same entity. Idempotency keys identify retries in the governed execution path.
Governed action checks · example
P
Proposed next step AI
Update the next step on work item 5821
✓
Policy check
Internal record update is supported and the caller has permission → pass
×
Different request, blocked AI
Send a customer message → blocked: this example has no enabled messaging capability. A person owns the next step.
✓
Execution result
Work item updated · operation RB-90417 recorded
03 Data isolation

Access scoped to your workspace.

Workspace records carry reseller and tenant identities. Access checks and database row-level policies use those identities to limit access to tenant records.

✓Database policies. Row-level security adds tenant scoping beneath application access checks.
✓Reseller support. Each tenant has its own data boundary within the platform.
✓White-label workspaces. Tenant identity governs record access within shared infrastructure.
Workspace access · example
Workspace
Northwind Goods
Access
Authenticated caller · assigned workspace
Database policy
Record access scoped by tenant and reseller identity
✓ Application checks and row-level policies work together.
04 Action records

A record you can rely on.

Fibric records execution results for supported governed actions. Review the operation, target, authority, and outcome before treating a proposed step as completed work.

✓Inspect the outcome. The governed execution record distinguishes the requested operation from its reported result.
✓Recognize a retry. An operation key identifies a repeated request within the supported execution path.
✓Read proposals correctly. A saved Letra discussion or shadow decision does not establish that an action executed.
Operation records · examples Example
Action Update a work item
Target work item 5821 · customer follow-up
✓ Completed · authorized internal update · #RB-90417
Proposal customer follow-up
Target work item 5793 · waiting customer
✓ Shadow decision · no action executed · #RB-90402
Request internal record change
Target work item 5771 · permission required
✓ Blocked · required authority missing · #RB-90388
Security posture

Protection beneath the surface.

Security also depends on how the service is hosted, accessed, and maintained.

Data & sources
Live metricsConnected records
Missing sourceVisible data gap
Record accessTenant-scoped policies
Source permissionsReviewed per connection
Access & identity
Sign-inManaged authentication
Workspace accessRole-based permissions
SSO requirementsReview with our team
Read and write accessSeparate decisions
Governed execution
ScopeSupported capabilities
Required checksBefore execution
ApprovalWhere configured
ResultsExecution records
Security review
Encryption & hostingArchitecture review
Retention & recoveryDeployment review
Audit export needsAvailability review
Compliance requirementsDiscuss before rollout

Contact us for a security questionnaire, DPA, or architecture review. Report vulnerabilities to security@bearscope.com.

Because it runs on Fibric

Part of the foundation.

Fibric powers BearScope’s connected capabilities and governed execution. Its checks apply to supported actions, with source access and action permissions reviewed separately.

/ Scoped to your workspace.

Workspace records carry reseller and tenant identities. Access checks and database policies use that scope.

/ Checked before it runs.

For governed actions, AI proposes a validated plan. Fibric checks the required authority and policy before execution.

/ Protected against repeats.

Single-flight and idempotency coordinate supported execution and identify repeated operations. Connector requirements still apply to external effects.

/ Connected through capabilities.

Connectors expose specific capabilities to the platform. Availability and permission depend on the connection and workspace.

Book a demo →