Security & controls

One set of rules for your team and AI agents.

BearScope runs your support floor on one system, so an AI agent and a person are held to the same rules. Real data only. Every action checked before it runs. Each tenant walled off from the next. A receipt for everything. It does not add safety as a feature. It inherits it from Fibric, the platform it runs on.

Built on Fibric.  The same rules the platform enforces for itself.

Real data only Every action checked Walled-off tenancy Full receipts
Action receipt · RB-90417 Checked
Action conversation.reassign · status.send
Target thread 5821 · reopened billing
Tenant northwind-goods · reseller harbor
Grounded live conversation + scoring data
By j.ruiz · 14:02 CT
Ran once handled once, no replay
✓ Checked against policy · Receipt #RB-90417
01 Real data only

A placeholder can never pass as a real metric.

A live operations view renders real data or it renders nothing. There is no in-between where an estimate quietly fills a gap and someone, a person or an agent, acts on it.

✓Tagged at the source. Any fallback the data layer produces is tagged source:"fallback", so a placeholder is structurally incapable of masquerading as a measured number.
✓Empty over wrong. If the real number is not available, you see an honest empty state, never a confident guess on a live conversation.
✓Grounded answers. Radar answers from your connected sources only and cites them, so "no estimates" is a property you can check, not a promise.
Data layer · source tagging Live
MetricSource
SLA at risk this hour live query · rendered real
Conversations scored today (412) scoring engine · rendered real
Churn rate no connected source · not shown fallback · hidden

A value with no connected source is tagged fallback and withheld. It never reaches a person or an agent as a metric.

02 Every action checked · fail-closed

The same rules veto an agent and a person alike.

The AI never acts directly. It can only propose a validated plan. The system checks that plan against your policy, and if anything fails the check, the action does not run. A policy you set can veto an AI agent's action the same way it can veto a person's. Fail-closed: the default answer is no.

✓Policy can veto anything. A rule you set can stop any action before it ever touches a customer, no matter who proposed it, the AI or a person.
✓You confirm what matters. Sensitive actions wait for a person's explicit confirm. Nothing runs on the AI's say-so alone.
✓Handled once. Click twice and it still runs once. A retry or a replay never doubles a customer message or a refund.
The system · deciding what actually runs
P
Proposed by agent AI
Refund a duplicate charge on thread 5821
✓
Policy check
Allowed: refund $38 to the customer of record, under the $50 cap → pass
×
Counter-example, blocked person
Refund $240, billing dispute proposed elsewhere → vetoed, over cap and a dispute. Fail-closed: handed to a person.
✓
Executed · runs once
Refund issued once · handled once, key RB-90417
03 Walled-off tenancy

Every row carries a reseller and a tenant. Isolation you can prove.

Tenancy is the spine, not a setting. Every record and every row carries a reseller id and a tenant id, and the data layer scopes each query to the caller's tenant. One tenant's conversations cannot be read by another, because the row itself refuses it.

✓Enforced at the row. Row-level security on Aurora, with the tenant set on every connection. App bugs cannot leak across tenants because the database scopes the read.
✓Reseller-aware. A reseller can serve many tenants, each provably walled off from the next, on one platform.
✓White-label safe. Your customers share infrastructure but never a row. Nothing of one tenant's conversations touches another's.
Aurora · tenant-scoped read
-- every connection sets the tenant guard
SET app.tenant_id = 'northwind-goods';
SET app.reseller_id = 'harbor';
-- the query you write is automatically scoped
SELECT verdict, scored_at FROM qa_scores;
-- RLS appends: WHERE tenant_id = app.tenant_id
✓ 412 rows for northwind-goods · 0 rows from any other tenant, ever
04 Full receipts

Every action is logged, explainable, and auditable after the fact.

When BearScope does something, a person or an agent, it leaves a receipt: what it did, to whom, on whose authority, grounded in which data, and the key that guarantees it happened exactly once. You can audit any action months later.

✓Who, what, when, why. Agent or person, action, target, timestamp, and the data the answer was grounded in are all on the receipt.
✓Proof it ran once. The receipt carries the key that proves the action was handled once and not replayed.
✓Exportable. Pull the full receipt trail into your own audit system over CSV or API.
Receipt trail · last 3 actions Audited
Action conversation.reassign · status.send
Target thread 5821 · reopened billing
✓ Checked · by j.ruiz 14:02 CT · #RB-90417
Action refund.issue
Target thread 5793 · $38, under $50 cap
✓ Checked · by agent Jenny 11:18 CT · #RB-90402
Action conversation.handoff
Target thread 5771 · billing dispute → person
✓ Checked · by agent Jenny 09:54 CT · #RB-90388
Security posture

The infrastructure under the rules.

The rules are the headline. Underneath them, the boring, important things are in place too.

Data & encryption
In transit✓ TLS 1.2+
At rest✓ AES-256, KMS-managed keys
Tenant isolation✓ Row-level security
Data residencyUS (AWS, account-isolated)
Access & identity
Team & reviewer auth✓ Cognito, MFA available
SSO / SAMLEnterprise plan
Least privilege✓ Scoped IAM per service
Source connections✓ Read-scoped tokens
Operations & resilience
Action logging✓ Receipt on every action
Runs once✓ One owner per conversation
Backups✓ Point-in-time restore
Secrets✓ AWS Secrets Manager
Safety & compliance
Real-data guarantee✓ Fallback tagged + withheld
Action policy✓ Fail-closed by default
Audit export✓ CSV / API
SOC 2 Type IIIn progress

Need our security questionnaire, DPA, or a deeper architecture review? Ask in your walkthrough and we will share them.

Because it runs on Fibric

BearScope does not have to be trusted to be good. The system under it keeps it safe.

Fibric is the platform: a system that senses a tool, reasons with a base model, and acts safely, running once even if retried and fail-closed. BearScope is one product on it. The rules are Fibric's, honored on every request, so a person and an AI agent are held to the same rules without BearScope hoping it remembered to apply them.

/ One record shape

Every record carries reseller_id and tenant_id. Tenancy is in the shape of the data itself, so isolation is not something the app remembers to do.

/ Propose, then decide

The AI proposes a validated plan; the system decides what actually runs. The intelligence is advisory; the action is checked, whether an agent or a person proposed it.

/ Runs once even if retried

One owner per conversation, and every action runs once even if retried. These are built into Fibric, not BearScope code. A double-click or a retry can never double a reply, a refund, or a reassignment.

/ Capability, not vendor

Integrations are connectors behind a capability. Swapping Kustomer for Zendesk is config. No vendor is wired into the trust path.

See it on your real data →