The permissions model, explained plainly
Every agent in Lyrion gets its own scope, and the default is narrower than most people expect on first look. That surprises teams who assume more access means more capability. In practice, narrow scope is what makes an agent safe enough to actually use.
Here is how to think about granting access, and why we start small on purpose.
Scope per agent, not per system
Access is granted to an agent for a purpose, not handed to “the AI” as a whole. The billing agent can see billing. The support agent can read the thread and the account but cannot issue arbitrary refunds. Each agent is shaped to its job, and its reach ends where the job ends.
This is more work to set up than a single all-powerful integration, and it is the entire point. An agent that can only touch what its task requires is an agent whose worst case is bounded.
Default narrow, widen on purpose
We start every agent with the least access that lets it do anything at all, and widen deliberately as trust builds. The opposite approach, granting broad access and trimming later, never trims, because nothing forces the review and broad access is comfortable.
Narrow by default means the uncomfortable question, “why does this agent need that,” gets asked at the moment of granting, when it is cheap to answer, rather than during an incident, when it is not.
Read is not write
We separate what an agent can see from what it can do. An agent might read an account to draft an informed reply while having no ability to change that account at all. Reading is how it gets context. Writing is a distinct, separately-granted, separately-logged power.
Conflating the two is how you end up with an agent that quietly edits things because it happened to have access for reading. Keeping them apart means context does not silently become authority.
The model your security team can read
Because scope is explicit and per-agent, the permissions model is something a security team can actually inspect: here is every agent, here is exactly what each one can see and do, here is where the lines are. There is no diffuse “the AI has access” to worry about.
That legibility is worth the extra setup. A permissions model you can read in a table is one you can reason about, defend, and change with confidence, which is more than most integrations can say.
How we would start
One queue, approvals on, one week of reading the log every morning. If reading the log starts to feel like a formality, widen the scope a notch. If it does not, the log will point at the exact place the agent needs better instructions or a tighter set of tools.