Give an AI agent read access to what it needs to investigate, and keep write access separate: a named action, a named target and an approval. Being able to read an issue should never allow changing it.
Why the two are separate
Reading is how an agent learns. Writing is how it affects the world. A mistake in reading wastes a few minutes. A mistake in writing can send a wrong message to a user or put a wrong change in your code. The two deserve different rules.
What read access should say
Read access names which account, workspace, repository or environment the agent may read, and how fresh that data is. An agent that reads stale data should say so and lower its certainty.
What write access should say
Write access names the action, its target and the approval it needs. "May write to the repository" is too wide. "May open a draft pull request on this repository after a person approves the change" is a rule you can check.
Approvals that name the exact change
An approval should describe one change: what it is, where it applies, which environment, who it reaches, how risky it is and how to undo it. If anyone edits the change afterwards, the approval should stop applying and the change should return for review.
When a permission is revoked or a tool fails
Show it, and stop the work that depends on it. A silent fallback hides the fact that something no longer works. Keep credentials out of the browser, the logs and the prompts a model reads.
How SylvieSI draws the line
SylvieSI reads user messages, code and error data after you connect each tool. Writing is narrower. On GitHub it creates branches and draft pull requests, only after approval, and it never merges. In Linear it creates issues. In Slack and Gmail it replies on the channel the user used, after the fix has been checked. Each connection shows its state, its permissions, who authorized it and the time of its last health check, and you can disconnect any of them.