https://docs.all-hands.dev/ logo
Join Slack
Powered by
agent-server: accept conversation-scoped tokens so...
# proj-agent
c
agent-server: accept conversation-scoped tokens so one server can be shared safely github.com/OpenHands/software-agent-sdk/pull/6471 This is part of a larger OpenHands Enterprise feature which allows one to install an agent-server on bare metal and have multiple users start conversations on the agent-server without leaking user data across given the power that a SESSION_API_KEY has today. This is part of a first increment suitable for single team sharing an OS account with high trust, but lays a foundation for more robust security later.
c
I'm not sure this is the way to go. As we see in these fragments, the current PR proposes a bunch complexity and risk to the SDK codebase, when it’s useless to everybody else. Could you please tell what problem is it trying to solve? A Mac agent-server can be used like the OHE app-server uses other agent-servers, can’t it? Maybe OHE can do its thing like it does for Linux?
In my understanding, in the previous discussion on “session api key”, Robert pointed out that agent-server is not multi-user. (“no ownership”) Precisely in the sense that everyone who can read or write can read or write everything. Please don’t get me wrong, I think it’s cool to rethink whatever people like; I would appreciate to think through and clarify implications. https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1790187317485339?thread_ts=1790163570.906039&channel=C06QT0AGY4W&message_ts=1790187317.485339
c
We can run lots of conversations through a single agent-server but today always assume that those conversations are from a single user or that we don't really care what user owns them. We now want to support multi-user through a single agent-canvas server for bare metal support. (Think iOS development on a farm of MacOS boxes.) That is very feasible except that today we secure everything through SESSION_API_KEY that has access to everything on the agent-server and we even pass it to the browser. This change just allows us to have keys that are conversation scoped so that data is properly segregated. If we weren't going to do this and we were going to keep the agent-server is always single user (and large ephemeral) in an enterprise context is that we'd have to build a new system that would handle creating a pool of agent-servers on a box, handing them out and tearing them down, etc. We could build such a thing, but that is a much bigger system.
c
My proposal on this topic is: • short-lived tokens for everything, as outlined in an older Simon’s secrets redesign proposal • login with GitHub/ChatGPT, which allows us to have refreshable tokens, thus a form of short-lived tokens instead of “session api key”
I think… if those were in place, maybe you could also achieve your goal?
c
Thanks for sharing the post from Robert.
You have way more background on the various proposals an approaches to this stuff on agent-server than me so definitely open to pointers. I had originally started working on the whole agent-server pool thing for MacOS but I was trying to get a thinner slice over the finish line and this seems a pretty targeted change. I do hear you that as written, the feature isn't useful unless agent-server is governed by an app-server layer.
I read github.com/OpenHands/OpenHands/issues/17055 and some of the discussion in the linked thread. I wasn't really aware of this. Thanks. I do need to make a decision pretty quickly about whether the general direction I am headed in github.com/OpenHands/enterprise/issues/1184 is viable or a dead-end. If I need to go back to working on that tearing down and standing up agent-servers for each conversation or "user session" even though the environment isn't ephemeral--just the users moving in and out of it are, I can do that.
If you think my approach is salvageable in by aligning with some other short lived token approach, happy to move in that direction too.
c
This is • the broker / short-lived secrets redesign: github.com/OpenHands/enterprise/issues/64 • the Login with issue: github.com/OpenHands/OpenHands/issues/17635
That is very feasible except that today we secure everything through SESSION_API_KEY that has access to everything on the agent-server and we even pass it to the browser.
This seems very insecure, and the login gives a solution to it
tearing down and standing up agent-servers for each conversation or “user session” even though the environment isn’t ephemeral--just the users moving in and out of it are
Sorry I’m dense, is this one necessary? I do think that keeping non-ephemeral agent-servers is … a good direction, and in fact I have wondered if the OH Cloud could do that
If it is necessary, there is something the agent-server currently has, I think: deferred_init implies an attempted separation (ish) between what is user data, and what is not
I think the goal there… let me find it
(OK this one might be too loosely related, sorry, anyway it was github.com/OpenHands/software-agent-sdk/issues/2523 )
c
@strong-ice-84145 I've scanned github.com/OpenHands/enterprise/issues/64. There is quite a lot there. Would you mind taking a look at what I am trying to do in this PR github.com/OpenHands/software-agent-sdk/pull/6471 and see if you see any relation to this work or if I could tweak my approach to be more palatable and move in the direction you were trying to take us in?
s
yes absolutely!
c
Please let me take a step to quickly outline the picture that, it seems to me, would match how some stuff here could work
That is very feasible except that today we secure everything through SESSION_API_KEY that has access to everything on the agent-server and we even pass it to the browser.
The alternative to this is: • a user logs in with OAuth to the agent-server • http-only cookie in browser, not key Then, once he’s in • can create keys, readonly, write • those keys can read or write everything Once he’s in, also • this agent-server works with a broker service, using this identity (for all other secrets) • all other secrets are short lived or placeholders in the agent-server • revocable from the broker • broker injects the real credential at network exits All this would work with a regular agent-server, run locally or remotely. I don’t think it currently works like this on the Cloud, either, and I think maybe something going towards this would be nice.
conversation scoped so that data is properly segregated.
This doesn’t work with “no ownership”, it seems to me? Maybe what can work, is: • an agent-server’s user data (repos, secrets, trajectories) are stored separately from the boxes running agent-servers • user data is attached at runtime, to a box where the rest is done • this is the behavior related to deferred_init, if I recall this right
I just had an automation flag this PR 😅 because it’s security-related in a way. The PR does say that these conversation tokens wouldn’t actually isolate, since agents live on the same machine and they’d cross anyway. Wouldn’t it be possible to enforce that these are • long lived machines • one belongs to a team, not cross • they can see everything • but they will be able to have different keys… • maybe, after we get to the read/write enforcement, read-only is possible • and logs by key…
c
I think I am going to abandon this approach in favor a controller that handles ephemeral agent-servers on bare metal.
Open in Slack
PreviousNext
Powered by