Comment by rcarmo
1 day ago
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 the keys it has access to, whether they come from encrypted SQLite locally or from the Azure Key Vault via REST. It can't tell the difference, and different agents on different K8s containers (or other IAM entities) see different things depending on their key vault access.
It's literally 100 lines of Bun Typescript (150 for the cloud version).
And believe me, you don't want to reinvent IAM in your keychain/secrets management. Let the provider do it for you, that's what they are there 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).
> And believe me, you don't want to reinvent IAM in your keychain/secrets management. Let the provider do it for you, that's what they are there for.
On the other hand, be careful what platforms you lock yourself into. I'm not saying "don't do it", just carefully evaluate all trade-offs by doing that. Turns out letting someone else handle your auth wholesale isn't always worth it long-term, but again, very "case by case" situation.
[dead]