Trust, security & governance

Governed by default. Not as an afterthought.

Letting an agent act in the physical world only works if it's safe by construction. So we built the trust spine first and the product on top of it. Here's exactly how Fibric keeps your operation, and your data, protected.

Real data only Fail-closed actions Walled-off tenancy Full receipts
The trust spine

Four guarantees the whole platform honors.

Every operator, every connector, every action is measured against these. They are not toggles. They are the shape of the system.

01

Real data only No placeholders

A placeholder can never pass as a real metric. If a number is shown, it is governed and traceable to a real source. When data is missing, Fibric says so, it does not invent, smooth, or guess.

  • / Every value is tagged with its source; a fallback is labelled a fallback and can never masquerade as a metric.
  • / Reasoning runs on governed real data, never on seed or mock values bleeding in from a demo.
  • / Missing data surfaces as missing, with an honest empty state, not a confident fabrication.
  • / This holds on every plan, including free. It's a property of the kernel, not an upgrade.
02

Every action vetted Fail-closed

The model proposes; a deterministic executor disposes. A policy you set can veto anything before it ever happens. When in doubt, the system fails closed, it does nothing, rather than guessing and doing the wrong thing.

  • / The LLM only emits a validated execution plan. It never reaches your systems directly.
  • / A deterministic executor checks every step against your policies before acting.
  • / Single-flight per entity + idempotency keys make a runaway flood structurally impossible.
  • / Any step that can't be proven safe is refused, not improvised. Fail-closed, every time.
03

Walled off Provable isolation

Your data is provably isolated. Nothing of yours ever touches anyone else's. Tenancy isn't a filter applied in the application, it's enforced at the data layer, so a bug in a feature can't leak across the wall.

  • / Every record carries a reseller and tenant id; isolation is row-level, not app-level.
  • / Row-level security scopes every query to the calling tenant, enforced by the database itself.
  • / A capability that forgets to scope simply returns nothing, it cannot read across the wall.
  • / Enterprise adds per-tenant audit exports and custom retention on the same guarantee.
04

Full receipts Always explainable

Every action is logged and explainable. You can always see what Fibric did, why it did it, what it sensed, what it proposed, what was approved, and what changed in the real world. No black box.

  • / Each action writes a receipt: the trigger, the plan, the policy check, the outcome.
  • / Receipts are tied to the canonical event, so the chain from sense to act is unbroken.
  • / You can replay the reasoning behind any decision, days or months later.
  • / Retention is 30 days on free, a year on Team, and custom on Enterprise.
How an action is governed

The model proposes. A deterministic executor disposes.

Between an agent's intent and a real-world change, there are four gates. Nothing skips them, which is why a wrong move, or a runaway one, can't reach your systems.

01 / Sense

Read real data

Fibric pulls governed, real-time data from your systems into one canonical event. No placeholders enter the loop.

02 / Propose

Model plans

The model reasons and emits a validated execution plan, a proposal. It has no power to act on its own.

03 / Vet

Policy disposes

A deterministic executor checks the plan against your fail-closed policies. It can veto any step. Single-flight and idempotency block duplicates.

04 / Act + receipt

Do, and record

Only approved steps run, exactly once, through the systems you already have. Every step leaves a receipt.

This is what makes the 657-message flood structurally impossible: single-flight means one action per entity in flight, idempotency keys mean a retry is a no-op, and a fail-closed policy can stop the whole plan before a single message leaves. The agent can want to do the wrong thing. It cannot.

Security posture

The controls underneath the guarantees.

Good intentions aren't security. These are the concrete controls behind the four pillars, the things an audit actually checks.

Encryption

Protected in transit and at rest

  • TLS 1.2+ on every connection, edge to data layer.
  • Data encrypted at rest with managed keys.
  • Secrets and connector credentials held in a managed secret store, never in code.
  • Enterprise: bring your own key and region.
Isolation

Walls enforced at the data layer

  • Row-level security scopes every query to its tenant.
  • Reseller and tenant id on every row and every event.
  • Least-privilege access; no shared application secrets across tenants.
  • Connectors run scoped to a single tenant's grant.
Audit

A receipt for everything

  • Every action and access is logged and attributable.
  • Receipts are append-only and tied to the canonical event.
  • Reasoning behind any decision is replayable.
  • Enterprise: per-tenant audit exports and custom retention.
Access & identity

Who can do what, controlled

  • Authentication on every surface; scoped tokens for connectors.
  • Fail-closed policies gate which actions an operator can authorize.
  • Enterprise: SSO / SAML and SCIM provisioning.
  • Approval gates for high-impact actions, set by you.
Resilience

Safe under failure and load

  • Single-flight + idempotency prevent duplicate and runaway actions.
  • The default under uncertainty is fail-closed: do nothing.
  • Swap-seams for compute, queue, and storage mean no single hard dependency.
  • A spend ceiling caps action volume, so a runaway bill can't happen either.
Data handling

We hold the minimum, plainly

  • We process only the data a connector needs to run your operation.
  • Your data is not used to train shared models.
  • Retention is yours to set on paid plans; deletion on request.
  • Sub-processors are named and limited, listed below.
Sub-processors

Who we rely on, and for what.

We keep this list short on purpose. Every sub-processor is contracted, scoped to a single function, and never receives more of your data than that function requires.

Sub-processor Purpose Data scope
Cloud infrastructure Compute, managed database, storage, and networking for the platform. Operational data at rest and in transit, encrypted, isolated per tenant.
Model provider Hosted base model that powers reasoning over your operational picture. Only the governed context a plan needs. Not used to train shared models.
Identity & auth Authentication, session management, and enterprise SSO. Account identity and sign-in metadata. No operational records.
Connectors you install Each connector reaches the system you choose to plug in, on MCP. Scoped to that one system's grant, for that one tenant, nothing wider.

Categories shown for clarity. The named, current sub-processor list and our DPA are available on request at security@fibric.io. We give notice before adding a sub-processor that touches your data.

AI transparency & ethics

An agent you can hold accountable.

Autonomy without accountability is just risk. Here's how we keep Fibric's reasoning honest, bounded, and answerable to you.

The model never has the last word

Reasoning is a proposal, not a command. A deterministic executor and your policies decide what actually happens. The intelligence is powerful; the authority is constrained, on purpose.

Every decision is explainable

For any action, you can see what was sensed, what was proposed, which policy approved it, and what changed. No "the AI decided" hand-waving. The receipt is the explanation.

No fabricated confidence

When Fibric doesn't know, it says so. It will not invent a metric, smooth over a gap, or present a guess as fact. Real data only is an honesty rule as much as a security one.

You set the boundaries

What an operator may authorize, which actions need approval, where the agent must stop, you define the envelope, and the system enforces it fail-closed. Autonomy lives inside your limits, never outside them.

Your data isn't our training set

We use your data to run your operation. It is not used to train shared models, and it stays walled off from every other tenant. What you operate is yours.

Bounded, not boundless

We don't ship capabilities we can't make safe. If an action can't be vetted, single-flighted, and receipted, it doesn't go live, however impressive it would look in a demo.

Questions about security

Trust is the product. Ask us anything.

Want our DPA, the named sub-processor list, or a security review for your team? Write to us. A real person, who actually understands the trust spine, replies.

Governed by default: real data only, every action vetted, walled off, full receipts.