What’s in place, and what isn’t.

Here’s how a change is meant to work. First, Fibric reads the systems you’ve connected, such as your order system or your building controls. Second, an AI agent looks at what it read and proposes one specific change, with its reasons. Third, Fibric checks that proposal against the rules you’ve set, using code rather than the AI’s judgment. Fourth, the permitted request is sent, with approval where the rules require it. A recorded path keeps the connected system’s reported result.

The AI never holds the keys to your systems. It can only write a proposal. The action’s rules and permissions decide whether a proposal reaches the connected system.

The action stops. If a rule can’t be evaluated, a permission is missing or the information behind a proposal isn’t good enough, Fibric doesn’t guess. The proposal is either refused or sent to a person to decide.

This matters most when something is uncertain after the fact. If a connected system accepts a change but its reply is lost, the record says the outcome is unconfirmed instead of marking it done.

Approve it twice by mistake? It’s sent once. If the system accepts a change but its reply is lost, check the result before trying again.

This protection covers actions sent through Fibric. A script or a person changing the same system directly is outside it, which is why the records show what went through Fibric and what didn’t.

Requests carry the customer’s identity. Tables covered by the access check use it before returning records. The control table above shows the current scope; deployment review checks the tables and request paths your workspace uses.

A listing in the marketplace doesn’t mean that boundary is already in place for that system. It’s set up and tested as part of each deployment.

Then it shows as missing. BearScope never fills a gap with an invented number. Values that come from a fallback or a placeholder are labelled as such, so they can’t be mistaken for real records.

When Letra answers a question, it shows the records it used. If the evidence is thin, it says so.

Where an action has a receipt, you can see what was read, what was proposed, which rules it passed, who approved it and what the connected system reported back. Where the system supports it, the record also says how to undo the change.

A record shows what Fibric saw and did. It isn’t proof of what happened inside another company’s system, and we don’t present it that way.

Each connection gets its own account with only the access its job needs. Keys are kept in a secret store, not in code. The marketplace never asks for your passwords.

Data moving between your systems and Fibric is encrypted. How it’s stored, including any requirement for your own keys or a specific region, is written into your agreement.

You decide. Roles control who can approve an action, who can change the rules and who can see which records. You choose which actions need a person. A refund or equipment change can wait for the approver your rules name. If an approval has been recorded, you can see the name and time on its receipt.

Single sign-on and automatic user provisioning are available when they’re written into an enterprise agreement.

Not to train a shared model, unless you agree to it in writing. Retention periods and the list of subprocessors are part of your agreement.

You decide. How long data is kept, how you can export it and when it’s deleted are written into your agreement before anything is connected. Nothing about that is left to a default you didn’t choose.

Disconnecting a system stops Fibric from reading it. Records of past actions stay available for as long as your agreement says, so you can still answer questions about what happened.

Ask us for a security review. We walk through every control on this page for your deployment, show you how each one is set up for the systems you plan to connect and put the ones that apply in writing. Ask which actions are enabled, which checks they pass, and who reviews an unconfirmed result before another request is sent.

We don’t claim certifications or controls we don’t have. Where something is partly in place, we tell you which part, and when it will be ready if we know.

Email security@fibric.io with the affected address, what you did and what you saw. Leave out passwords and customer data. Our disclosure policy explains what happens after you report it.

If you’re a customer and the problem affects your deployment, use the support route in your agreement as well, so the right people are told straight away.

BearScope is live, hosted in AWS US East. In BearScope, agents read your data and people approve what happens next. Actions are being switched on one at a time, each with its own checks.

The wider Fibric platform is in managed early access. We set up each deployment with you and confirm, in writing, which of the controls on this page apply to it.