Business isolation
Separation lives in the database and each service identity, not in an optional model instruction.
- Row-level policies
- Non-interactive service roles
- Secrets kept out of code and models
Security before autonomy
We separate conversation, decision and execution. The model proposes; least-privilege services validate and execute; every action leaves evidence.
Discuss securitySeparation lives in the database and each service identity, not in an optional model instruction.
Every tool declares what it can read or change. Sensitive operations require confirmation, authorisation and validation.
We retain who, what, when and the outcome of relevant operations so they can be investigated, explained and recovered.
We design to minimise data, retention and exposure, using European infrastructure where the provider and channel allow it.
Frequently asked questions
The architecture separates the model from execution. The model proposes using a tool; services with restricted permissions check identity, inputs and rules before acting. Instructions written inside a message must not be able to expand those permissions.
Isolation is designed into service identity, permissions and data access, not just a prompt. Each query and action must remain within the business’s authorised context. The specific configuration and its tests are part of implementation review.
The traceability design covers who requested the action, which tool was involved, when it happened and the outcome. The goal is to explain changes or investigate failures without retaining data indiscriminately. Logging scope and retention must be defined for each implementation.
No. This page explains design and control principles; it does not claim independent certification or guarantee that incidents cannot occur. Evaluation must consider the actual configuration, providers, access permissions and tests for the implementation being used.
Aipiter