Where a rule check has to sit.
A rule check stops only the actions that pass through it. A script or a manual change that reaches the same system needs a check of its own.
You can tell an agent a policy in its instructions, but telling a model a rule doesn’t enforce it. Enforcement needs a separate check that the action has to pass. In Fibric’s design, the agent writes its proposal as a plan, and code checks the plan before any connector is called.
So the question for any deployment is which routes can change the target system, and whether each one passes a check. A well-checked agent does nothing to stop an unrelated script, a manual change or another product’s API from changing the same system.
Authority and uncertainty.
When an approval or a permission is missing, the action should stop. An uncertain result is a different problem: the other system may have accepted the request even though its reply was lost. The receipt, and any later check of the result, should keep that uncertainty instead of marking the action done.
This research aims to make those limits explicit and testable. It describes a reference design, not a safety guarantee: how safe a deployment is depends on which routes exist, which rules are set, how each connected system behaves and what has been tested.