User level separation, while it has improved over the years, was not originally designed assuming unprivileged users were malicious, and even today privilege escalation bugs regularly pop up. If you are going to use it as a sandboxing mechanism, you should at least ensure the sandboxed user doesn't have access to any suid binaries as these regularly have exploits found in them.

No I'm fairly certain almost nobody does that.

I run mine as it's own user and self host the model. Unlike most services the ai service user has a login shell and home directory.

What's its preferred shell and window manager?

It just uses bash. I haven't been giving it an X session yet although I probably will start at some point since the newer models can handle it.

Thank you for a serious answer to a facetious question.

An agent can be designed to run with permissions of a system/bot account; however, others can be designed to execute things under user context, using OAuth to get user consent.

VMs are common, consider going that additional step. Once you have one agent, it's natural to want two agents, and now they will interfere with each other if they start running servers that bind to ports. One agent per VM solves this and a lot of other issues.

That seems hardly sufficient. You are still exposing a massive attack surface. I run within a rootless docker container.

Same with the browser agents, they are used in a browser where you‘re also logged into your usual accounts. Means in theory they can simply mail everyone something funny, do some banking (probably not but could work for some banks) or something else. Endless possibilities

I'd have to follow some kind of tutorial, or more realistically, ask the AI to set it up for me ;)

I only run AI within docker containers so kinda?