Flow
Deciding whether a request may leave
1Gather context within limits
Record, comment and field caps applied; included identifiers recorded.
2Is a provider named or defaulted?
If none resolves, fail with an explicit message rather than guessing.
3Is it configured?
Missing address or key is a configuration failure, reported as unavailable.
4Is it local or is egress allowed?
Hosted providers pass only when the default-off egress setting is explicitly true.
5Send and return text only
No write handle exists, so the result is a draft a person can act on.
Adding an AI assistant to my work dashboard happened this week. What bothered me first wasn't which model to pick. It was that every task and comment it could read could now leave my network.
The dashboard sits on top of my work task tracker. The text in there is follow-ups, due dates, and comments people wrote for coworkers. I put one model on my own network and a few hosted ones behind one interface. It can sum up a task, draft a follow-up, brief my queue, or answer a question.
Why a key in the env file doesn't count
The easy rule is: if a key is there, use the provider. I don't buy it. A key means the server can log in. It doesn't mean I said yes to sending work text there.
So I track two things. Configured means the server can reach the provider. Enabled means configured and allowed. My local model is allowed once it's set up. Hosted ones also need a separate server setting that allows outbound traffic, and that setting starts off. The status screen shows that middle case plainly: set up, but blocked by policy.
No swapping behind my back
If I ask for a provider that isn't enabled, the request fails with a clear message. It never tries the next one down the list. If I don't name a provider, my default is a hosted model, and the setting is off, the request fails even when the local model works. A fallback would send work text somewhere new without anyone choosing that.
What the model actually sees
Even when sending is allowed, the model sees a little: one task and some of its comments, or a short list of my recent tasks. Long text gets cut. Each answer lists which tasks went in.
That text goes in a marked block, and the model is told to treat it as data, not orders. I wrote a test where a task tells the assistant to ignore its rules and post something. It only checks that the warning and the bad text end up in the right places. It never runs a model, so I don't know yet if a real one listens.
What I count on more is simple. The assistant has no tools. It gives back text, marked read-only. A draft is just text until I post it.
The door for agents
Other agents get their own tool server. It only has read tools, it caps every input, and it goes through my dashboard instead of straight to the tracker. It can read. It can't make my server call a hosted model, because that tool was never added.