the token is thrown away after one GET /user

🤔 i'm not sure what the point is then? would there be an env var like ALLOWED_USER=enyst?

Two options: • a default app that sits there and can do it, if people want to use it • they can provision their own. It's simple enough, it doesn't need perms, scopes, stuff

not complete role based access control but provding an access and identity layer

Now, nobody is stopping humans from using API keys, but comparatively, it’s a bad experience to paste plaintext keys, to go on a plane and button on your phone and say “ugh I forgot to mess around with keys for this browser so I can’t access my OpenHands”

Hmm, yea I can see that pain point. Keys can be a pain. But that is what password managers are for?

if we can't enforce that's definitely an issue

The trickiest thing here is that this is actually, to my mind, about securing access for the human who stood up an OpenHands agent-canvas on a machine. Let me bluntly honest about what I fear: I fear that in a week or three after we’d implement this “RBAC” proposal - sorry for the scare quotes -, then people will rewrite the docs. There’s a page with a comparison table between OpenHands and

enterprise

. I’m pretty sure that page says “multi-user” and “RBAC” in the

enterprise

column. Then when rewriting it… I fear that it will tell everyone in the world: “yes, the OSS has RBAC, but it’s not secure, if you want actual access control you buy the commercial product”

It's possible to define good products by drawing the line at single user (or single-ish) / multi-user. I worry that it’s not a good direction to draw it at security…

This is current PR on “accessing OpenHands on another browser”

It looks terribly insecure to me. Giving people plaintext keys in 2026, when Claude tells me that OAuth first showed up in 2007 😅 It seems to me like telling them that OpenHands can be secure too, alright, but not for them. I’m sorry.

Can we consider a Login with GitHub, as an optional ability, minimal, totally minimal, just enough to click twice on iPad instead of messing with plaintext keys? The key would remain an option, agents need keys

as well as inheriting agent canvas instances people have already invested in

e.g. you could give Enterprise a read-only key to all your existing canvas instances, and it can aggregate usage statistics across them. or an admin key, and it can enforce certain LLMs to be used, or disallow certain MCPs

I mean, the minimal way to give read access to automations execution seems to be this: instead of a link to 401, a trajectory download. Or a mirror. Or a HF link… right?

I think UI is nice, though I… am not sure about the complexity it brings. When this ^ was executing as a workflow in GitHub Actions, the trajectory was under the shape of a log. It was, well, okay - and agents can read them/download them. Read for the world. 😇

Robert, I welcome your explanations, but I think I’m… a bit more confused than I was when we started this discussion, and that’s saying something. 😅 The rule you present here surely doesn’t seem to me what the RBAC proposal says… 🤔 • “no ownership” vs. “user identity” • “anyone with a read key can read everything” vs. “restrict workspaces to admin-configured trusted roots” • “anyone with a read key can read everything” vs. “keep arbitrary paths admin-only” or “route enforcement” • “no ownership” vs. “short lived tokens” I think maybe this comes from `Run[automations]`: I mean, you’re saying only

read

and

admin/write

.

Read

on everything should be achievable thinky spin But in the RBAC proposal there is also

Run[automations]

, which means the agent’s ability. Maybe that’s what confuses me: running automations, specially interactive ones like Slack, seems difficult to limit, involves quite a lot of complexity, and if successful, then I think the cost is kneecapping the agent. (maybe Slack shouldn’t be conceptualized as an “automation”) On the other hand, if we add

Run

, and it doesn’t do what the doc says it does, then I’m sorry, my concern is the false sense of security; it’s precisely that people will hear something and get something else.

letting

read

do anything that could cause a change in server state would be misleading

I'm not sure where

Run[automations]

is coming from

I do think we eventually want a

run

role, which can have conversations and trigger automations, but not e.g. modify secrets but right now (IIUC) there's no way to start a conversation without reading secrets (which is terrible and we should fix)

I'm not sure what "Restrict workspaces to administrator-configured, symlink-aware trusted roots." is, that seems like maybe AI trying to be helpful

I guess maybe preventing a

read

token from being able to view every file on the machine?

The secrets issue seems different than this, and I think maybe it works now to receive automatically at start only secrets configured in the Agent Profile

Or if you meant something else, how should a conversation work without reading secrets?

Yes, I think it aims to prevent

read

and/or

run

from accessing outside its working directory

IIRC in the past, we concluded this was not really enforceable for the agent, as long as it has bash

I think the frontend does a lot of

execute_bash

too, which we'd want to prevent for

run

users

although I guess they could just tell the agent

execute this bash

so maybe that one isn't important