oh waveq Looking for Feedback 👀 -> Role-Based Access Control for the Agent Canvas - This is a minimal outline on RBAC within Agent Canvas. This would ideally allow us to have user identification for shared team instances and generally support a stronger shared remote team instance of OpenHands. TLDR: • Support provisioning API keys per user with permissions to access a remote canvas instance: Read, Run, Admin • Add UI/UX for user<>conversation, user<>automation etc.

Shared teams instances?

Yep! So if you install on a VM and want to use it with your team (like we're doing with the OSS instance)

I have very strong feelings about this. I don’t want to say “either in, or out” 😅, but we haven’t yet solved the basics

Ah gotcha. I'm not sure about a full auth layer like that. I like the simplicity of this but really want to hear community feedback to see where folks feel

Since just about forever, Robert and folks were totally convinced that OpenHands should remain single user. I know this may seem difficult to believe, but I actually thought about it a lot, back and forth, with multiple occasions, and my conclusion was that real, secure auth would be worthwhile, but multi-user is a too big lift

The API path was Robert's idea actually. I was also bringing up that I thought we needed to provide coverage for some multi user use-cases and he pointed me toward this kind of API based path which I was pretty excited about. It doesn't require a third party dependency but gives you the ability to setup remote backends with some basic permissions and user mapping.

- Store named credential metadata, keyed hashes, expiry/revocation state, parent/delegation relationships, and audit records in the Agent Server.

This doesn’t sound right: • if they’re in the agent box, I would think of them as accessible to the agent. • maybe encrypted, but… oof. We’re just trying to get rid of encrypted saves, since it’s very error-prone (encryption key needs sent all over the code, higher complexity, misses)

I think of this as a good starting point for adding boundaries and attaching identity to them. Anyone who can talk to an agent could probably find a way to extract something they aren't supposed to. But as a single user nothing really changes. You could opt in to providing a boundary to those you want to give keys to so there is a minimal layer of access and logging. Right now there is no step between OSS single player and Enterprise deployment which limits the day to day usefulness of canvas for a lot of folks. Its complete full access or nothing and everyone acts as the same user. With provisioned keys there is at least a way to show multi user existence without requiring a complete user auth system which is an entire can of worms.

Can you please give me some example(s) of usefulness for multi user? While the issue starts by talking about “teams”, it actually refers mostly to Automations

> example(s) of usefulness for multi user? Being able to add a user logging layer gives visibility on who does any kind of CRUD. Create a conversation, add an MCP, enable/disable something. I know in the OSS instance we've been reaching for this because there is no way to debug if something happened because someone else fiddled with that canvas instance or if it is a new bug. Once the user based actions are being logged we could also show when an agent changes something vs when a user changes it too. So agent profiles could be pulled in to the conversation. > Can of worms User auth then means supporting some kind of emailing solution or relying on some other bigger library to manage it. *usually

Ah, thank you, that doesn’t seem a worms thing to me 😅 For the record, I should apologize for giving the impression that this one is major…

agent

One more relevant problem, in my view, is precisely that for a single user nothing changes, apparently. And yet we would add a big bunch of code handling more long-lived static keys (and some short ones) into the sdk. Just now, just when looking into this, I found a security leak. Vasco is fixing a couple others. Simon is working on redesigning custom secrets. Robert had posted a download with keys. And we have a bunch of tickets about cleaning up the code design, which is full of inappropriate data structures and responsibilities leaking into too many places. It’s a whack-a-mole before we manage to bring the codebase back to sanity. Sorry, I feel strongly about this, and I don’t think adding more complexity now is quite the right way. Moreover, the story of the boundary between OpenHands and enterprise gets messy, and I think there is a better way. Will come back on this.

I think there could be some really good value for a single user but that wasn't the focus in this breakdown. I think we could introduce a single user profile with this as well which would let you see content/actions done by you the user vs those done by an agent. There are some really nice personal profiles out there in other apps that I'd like to incorporate. Instead of the github user name it would be your github user name.

I left two comments on the proposal. Yes, well 😅 your github user is one of the things we’d get from e.g. Login with GitHub. I would love it if we secure at least that one user, before multi-user. 🙏