How SylvieSI controls what it does

Agents investigate and propose. People approve. Controlled services carry out the approved action. Then SylvieSI checks the result.

Limits

SylvieSI holds no security certifications, and no external security audit has been carried out. The section “What we have not done” lists these limits.

Every finding has a source

SylvieSI keeps the sender’s message and where it came from. It notes how fresh the data is and what is missing.

Approvals name the exact change

A proposal is not permission. A person approves what will change, where, and how risky it is.

Policy decides, not a model

Product policy sets what is allowed, and controlled services carry it out. A model’s judgment does not.

Results are checked

SylvieSI confirms the effect where it happened. A response from a provider is not a result.

Six boundaries that do not change

Merging: No automatic merge.
Deployment: No silent risky deploy.
Your pages: No arbitrary generated JavaScript on your pages. Only approved, versioned catalog components, shipped by SylvieSI.
Your systems: No unrestricted proxy to your origin.
Data, payments and access: No autonomous change to your database schema, payments or authorization.
External effects: SylvieSI never claims an external effect (a sent message, a created issue, a release) before the provider confirms it.

What agents can and cannot do

A suggestion and an action in the outside world carry different responsibility. An action must stay within its approved limits.

Agents read and propose

Read messages, code and error data.
State how certain they are and what is missing.
Suggest the next piece of work.

Controlled services act

Check permissions and limits.
Require the approval that policy demands.
Confirm the effect and save it to the audit history.

Rules every agent follows

Proposals only: Agents write drafts. Only controlled services change anything, after policy and approval.
Sources required: Every claim cites a stored source. Output with a missing or unknown source is rejected.
Certainty is computed: A model’s wording can reach Probable at most. Verified needs a passed reproduction or a direct trace match, plus a person.
Workspace users: Messages, emails and code comments cannot change an agent’s tools or permissions.
Minimal data: Secrets are never sent to a model. Personal data is reduced before a model call, following your privacy setting.
Budgets: Each run has limits on tokens, time and tool calls. When one is reached, the run stops and says so.
When a model is down: The run fails with a clear message and the Case keeps its earlier state. SylvieSI shows no invented finding.
Every run is saved: Each run keeps its inputs, tools used, outputs, sources and cost.

Seven roles control access

Owner: Full access to the workspace.
Admin: Manages sources, policies and access.
Product: Works with messages, Ideas, evidence and experiments.
Engineering: Works with Cases, Work and Changes.
Support: Works with messages and drafts of replies.
Reviewer: Decides approvals in their area.
Viewer: Read-only access.

A role change takes effect on the next request. A removed member loses access at once. The last Owner cannot be removed. The person who asks for a high-risk change cannot approve it alone.

How data is handled

Workspace separation: Each workspace’s data is separated in the database with row-level security.
Credentials: Connector tokens are encrypted with AES-256-GCM and kept out of the browser, the logs and model prompts.
Signed identity: Messages from your product carry a signed identity with a short expiry. A message cannot be replayed.
Retention: You set how long evidence is kept. Expired evidence is removed automatically.
Export and deletion: You can freeze a workspace, export its data, or request deletion after a grace period.
Model providers: SylvieSI works with more than one model provider. You choose the model for each role in Settings.

What we have not done

Certifications: SylvieSI holds no SOC 2, ISO 27001 or similar certification.
External audit: No external security audit has been carried out.

Questions to ask any vendor, including us

Evaluate the actual implementation in your own environment. Do not rely on a product statement.

Access and separation: Which data is read? How is separation enforced and tested?
Credentials and data handling: What is stored, for how long, and how are credentials protected?
Write actions: Which actions only read, which can change something, and what approval is required?
Recovery and audit history: Which recovery steps have been tested, and what shows the result?

This site makes no claim of SOC 2, ISO 27001 or HIPAA compliance, no uptime commitment and no guarantee of rollback.

Request an evaluation

Approve one exact action and check its effect

An approval names the exact change. If the change is edited, the approval stops applying.

Before the action

Review the target, the environment, the expected effect, the risk and how to undo it. A changed action returns for review.

During the attempt

Permissions are checked against your environment. An AI suggestion cannot widen access or stand in for approval.

After the action

SylvieSI keeps the attempt, the response from the tool and any independent check. A tool’s acknowledgement is not saved as success.

Follow a proposed change