Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

github.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#21

Post by embedding-shape »

zwigglers wrote: post #20
embedding-shape wrote: post #19

Earlier quoted context omitted.

> 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 need…

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?

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#22

Post by zwigglers »

embedding-shape wrote: post #6
zwigglers wrote: post #2

Hi HN, Yao here. Most frameworks are built for one developer, one agent. The moment a team shares infrastructure, people end up duct-taping row-level access into the prompt and hoping the model doesn't argue past it. I got tired of that. Cast is a harness for multi-user, multi-agent systems: one server, a handful of people with their own identities, a fleet of agents handling different things and talking to each othe…

> people end up duct-taping row-level access into the prompt What exactly do you mean with this? The times I've collaborated on projects where most of us are using agents, we basically placed shared files in shared repositories, just like you usually do, so any shared instructions would go there. Then you work on your thing, then eventually submit a PR, and so on. Where does the "duct-taping row-level access" come in…

[dead]

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#25

Post by GTP »

embedding-shape wrote: post #21
zwigglers wrote: post #20

Earlier quoted context omitted.

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 gro…

> 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.

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#26

Post by GTP »

rcarmo wrote: post #14
zwigglers wrote: post #12

Earlier quoted context omitted.

Fine for single-user setups. I'm solving a different layer: multi-agent/multi-user identity and routing. When multiple people with different permission levels are all talking to the same agent, env vars don't tell you who's asking or what they're allowed to do.

You're not getting it. The env vars are only exposed in the local agent runtime. The agent's identity against Azure Key Vault determines what it has access to. (and I also expand some env vars on fetch() requests for APIs that don't have hard IAM/Entra ID auth) The keychain tool has the same semantics whether we're running solo, locally, in a container, anything. The agent doesn't know anything except the handles for…

Maybe I'm not getting it either, but it looks like you're imagining a scenario where you deploy multiple instances of the agent, one per user, and then each one gets a different access level based on a key. Is this correct?

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#27

Post by zwigglers »

GTP wrote: post #26
rcarmo wrote: post #14

Earlier quoted context omitted.

You're not getting it. The env vars are only exposed in the local agent runtime. The agent's identity against Azure Key Vault determines what it has access to. (and I also expand some env vars on fetch() requests for APIs that don't have hard IAM/Entra ID auth) The keychain tool has the same semantics whether we're running solo, locally, in a container, anything. The agent doesn't know anything except the handles for…

Maybe I'm not getting it either, but it looks like you're imagining a scenario where you deploy multiple instances of the agent, one per user, and then each one gets a different access level based on a key. Is this correct?

Not imagining it, using it in prod. Not sure how you define "multiple instances" here but basically, one agent with multiple concurrent conversations. Access level is based on the point of ingress to the agent, limitations are mechanical (tool access) and semantic (affecting posture, not a true security boundary but you can inflence behavior per entrypoint).

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#28

Post by zwigglers »

GTP wrote: post #25
embedding-shape wrote: post #21

Earlier quoted context omitted.

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 gro…

> 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 separati…

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.

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#29

Post by dezsirazvan »

the read-only-by-default angle is underrated. been building an activity-log layer for agents and the moment we considered exposing write tools through MCP the security review story exploded. kept it query-only and integration went from "needs a security architecture doc" to "install the agent, done." most of the value of giving agents access to a system is just letting them read - the write part can usually go through whatever ops tooling already exists.

Re: Show HN: Tired of duct-taping access control into agent prompts. Here's the fix

#30

Post by GTP »

zwigglers wrote: post #27
GTP wrote: post #26

Earlier quoted context omitted.

Maybe I'm not getting it either, but it looks like you're imagining a scenario where you deploy multiple instances of the agent, one per user, and then each one gets a different access level based on a key. Is this correct?

Not imagining it, using it in prod. Not sure how you define "multiple instances" here but basically, one agent with multiple concurrent conversations. Access level is based on the point of ingress to the agent, limitations are mechanical (tool access) and semantic (affecting posture, not a true security boundary but you can inflence behavior per entrypoint).

in my case, we're using Docker containers to spwan Hermes instances, so it is easier to define what an instance is. And we need a container per user, because, without modifications, if multiple users talk to the same Hermes instance then they can access each other's conversations by asking the agent.
Post reply on HN