Hacker News Reader

Comment by avikonduru | Hacker News Reader

How do you handle permissions when the downstream service only offers a shared API key? For example, two sales reps can use the same CRM endpoint but should only access their own accounts. Does Alter check record ownership, or does the developer still need to supply that logic?

View on HN

Measured on an agent I run, before it knew whose request it was serving: 7 of 10 checks failed. Acting for an account manager, another manager's customer record came back in full. Acting for first-line support, who may not send email, it sent one. What fixed it was putting the ownership rule at the one door every call goes through, the tool server, not in the records service, which only ever sees the server's key. Every call carries two tokens, the agent's and the person's, both checked by the API server.

The agent may do only what both are granted, and a customer outside the person's own is answered exactly like one that does not exist, so nobody can enumerate by asking. The gap I still have: the model gateway behind it knows only the agent, so one person can spend the whole agent's token budget.

We allow end users to add API keys directly via the alter connect SDK. If the API key needs to be shared then developers can map it on their end using the grant ID abstraction that we provide. Feel free to go through the docs here: https://docs.alterauth.com/concepts/credentials/

> We allow end users to add API keys directly

This seems like a bad idea to me these days. Companies doing this make themselves a target and then get hacked like OpenCode. Customer accounts get drained or bills run up.

Run your own gateway behind a firewall / vpn. I personally use GoModel + Tailscale.

https://news.ycombinator.com/item?id=50133401 (OpenCode hacked story)

Yeah we've put most of our effort so far into security, this part especially. Keys are encrypted in a dedicated secrets vault and once saved nobody can read them back, not even the dev who set them up. In proxy mode the key never even reaches the agent, we inject it on our side and only into requests going to hosts that are allowlisted for that provider. Every use gets checked against policy and logged with who used it and on whose behalf

Every change we ship gets scanned for supply chain attacks and goes through static code scanners too. We've been pen tested by two separate firms and we're in the observation period for SOC 2 type 2, details are at trust.alterauth.com. We're also planning open sourcing the full platform soon so you'll be able to look at the code yourself.

> nobody can read them back

how are they sent to the upstream vendor?

it's bad practice to upload such important keys to new vendors, OpenCode has their certs and trust page too, they got their user keys hacked

Hey! Great question. So here when we say nobody can read them back we mean no user/developer can read them back. During the time of the request the backend code retrieves the credential from the vault and auto injects it in the request path.

We will be open sourcing our codebase soon so you can examine the code yoursef!

Reply on news.ycombinator.com