Hacker News Reader

Comment by embedding-shape | Hacker News Reader

> small team's internal tool where sales and engineering collaborate but shouldn't see each other's data

Right, but wouldn't that happen by default? Lets say I slap a PHP API in front of a local Codex instance running somewhere, then let people login and chat with those, then by default nothing is shared? Sharing stuff between, is extra stuff on top, not things that happen by default, so I'm still not sure what the "duct-taping row-level access into the prompt" actually means in practice? You mean people would ask to access other's data and you want to prevent them from that?

View on HN

Exactly that. Separate sessions give you data isolation. The hard part is capability isolation, like selective collaboration (between multiple users and multiple agents).

My household runs a shared agent on Telegram, my partner and I can do everything, calendar, purchases. My kid should be on a different trust tier, can ask questions but not send emails on our behalf for example. With a prompt rule the kid can just say 'dad said its okay', but with cast the kid's ingress is wired to a permission set that never reaches certain tools.

That's the simple version. The more interesting case is building agents that collaborate across trust boundaries in real time, but that's a longer conversation.

> My household runs a shared agent on Telegram, my partner and I can do everything, calendar, purchases.

Alright, so already here you have permissions, per user, it sounds like, as you both have different chat sessions, I'm assuming?

Associated with those chat sessions, is the user, and what tools (via MCP or passed manually to the model, or whatever) it has access to at that moment.

Already here you have what's needed 100%? Why would you give/remove access via the prompt, I don't think anyone use LLMs like that in the first place?

Adding tool calls/responses is already doing something more, but instead of doing less, you suggest piling something on top of that?

Sorry if I seem slow, I'm just trying to understand what problem you're actually trying to solve here, as it sounds to me you're trying to solve something you could have just not done to begin with, then you don't have that problem anymore at all?

It sounds like you're describing two chat sessions = two agents, one chat session per agent. The agents get different tools, no shared context, no duct tape. Is this an accurate read?

The duct taping comes in when two different people share an agent, when having a shared context is useful.

The shared context use case is less common. You have to have hit that wall yourself to feel the problem. Does that track?

Yes, since you said that you're two people, then what you begin with is exactly that, right? The session sharing is something you've layered on top, with extra software, not something you basically get from a VPS+UNIX users, right?

The times I've shared contexts in such ways, then you want to share a read-only view, still with the other user not being able to add more messages, I guess you're really talking about group chats here?

> The session sharing is something you've layered on top, with extra software

Nope. If you give access to the same agent instance to multiple people, then one user can get access to someone else's data. I'm working right now for a startup facing this issue. The easiest solution is to have a separate agent instance per user, but this increases resource consumption vs having a single agent instance with proper separation between multiple users.

If you're trying to solve this problem right now you should take a look at cast and see if it addresses your problem. Would love to stress test my framework against different use cases.

Reply on news.ycombinator.com