Launch HN: Alter (YC S25) – Access control for multi-user agents (alterauth.com)
If you’ve built an internal agent people use through Slack, you may have experienced this scenario: everyone signs in with their own account, but the agent connects to the CRM or billing system with one shared API key, so the agent can do anything that the key can do. User-level authentication in Slack does nothing to control what the agent can do in an external system like the CRM or billing system.
Here’s what Alter does:
-It acts as a proxy and manages downstream credentials for every API request that an agent takes;
-It takes identity into account for every action the agent does. Automatically take into account the end user identity of the person that the agent is taking actions on behalf of.
-It enforces fine grained runtime policies and records compliance grade audit logs.
Here’s a demo video: https://www.youtube.com/watch?v=9ZqPU14ipGE
We started this because we saw first hand how hard it is to build agents in regulated industries. To unlock the true benefits of agents we need to allow agents to take actions, sometimes actions on behalf of end users. I (Srikar) was working at Goldmans and I saw how prohibitively expensive it was for me as a developer to write my own custom auth to enable multi-tenancy in agents and to allow agents to have strict policy controls as they act on behalf of end users. My co-founder, Kevan, is a second time founder and was previously working on a database startup. He has experience building and selling deep tech into highly regulated environments. So this problem seemed like a natural fit for the both of us.
Building and maintaining custom auth for multi tenant agents was challenging. But so was ensuring that the solution we developed was secure, scalable and keeping track of security grade audit logs. As a result we realized there needs to be a separate product category for this that enables developers to easily build secure multi user agents that can actually take actions in an enterprise. Some of the real-world use cases we’ve seen include:
We have built a multi user open claw for our own team using Alter that saved us countless hours on our GTM effort. Link here:https://github.com/AlterAIDev/openclaw-alter-plugin
We have multiple startups who have used our platform to build their own secure internal agents for everything ranging from SRE agents to back office agents dealing with Quickbooks and payroll platforms like Rippling. It has saved developers countless hours both in terms of building and maintenance. We also have a defense contractor building air gapped agents for marine corp using Alter.
Under the hood, the value that we provide is that we do a lot of the plumbing that no one wants to do. We support hundreds of providers, all manually tested end to end. Reliability is our biggest priority. We have built this in a way to allow developers to custom build their agents however they see fit. Everything ranging from custom policies, agent delegation, user attribution, audit logs needed for compliance to a LLM gateway with guardrails (Coming soon)
Building a security product is hard. We have learnt that in order to build a truly secure product, security thinking has to pervade every part of the development process. We have embraced shift left security. Every PR that is pushed out is continuously checked for supply chain attacks, potentially dangerous code patterns etc.
Our business plan revolved around usage based pricing. There is a free tier up to 10k requests and then a pricing tier starting beyond that. We would love it if people configured their APIs and OAuth credentials, tried out t...
57 comments
[ 2.8 ms ] story [ 52.5 ms ] threadOne aspect of multi-user agent security, which I think is underexplored, is how context from a higher-privileged session might "leak" into a lower privileged session. Suppose the CEO of a company uses your shared openclaw agent and the agent writes sensitive data (investor emails, for example) to its memory. My understanding is this is not protected by Alter. Then a contractor uses the same agent and can read that same memory. It seems to me that a better agent harness for this kind of multi-user use case is needed; the standard ones like openclaw and claude code simply are not designed for it. Would love your thoughts!
Feel free to go through the docs here if you have more questions: https://docs.alterauth.com/guides/propagate-identity-to-memo...
I am the founder of Substrate, a project that lets you inspect what is in the memory and select what each agent sees.
Do you separate memory per user with your harness?
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)
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.
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
We will be open sourcing our codebase soon so you can examine the code yoursef!
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.
What we hit building exactly that, rooms where humans and bots are peers: you can't scope a token to an agent, you have to scope it to an (agent, room) pair, and then decide what happens to the derived artifacts. Tool output, file handles, and the memory blob the agent writes back all outlive the session and get replayed into the next one.
So how are you handling derived state? Is agent memory a new principal holding the intersection of the rights of the sessions that fed it, or does it just inherit and you rely on the model not to act on stale context?
The right way to treat the agent is not as a delegated agent but rather an agent that takes the least privilege possible out of all the people in the channel
In scenarios where an agent and humans are peers we recommend giving separate agent identities to the agent and treat them as separate privileged users and give them permissions based on their identity and not based on the identities of the users in the channel.
We support standlone agent identities that dont require end users as the principals. Can read about that here: https://docs.alterauth.com/guides/give-an-agent-scoped-acces...
How do you handle an agent that has valid authorization but has been prompt-injected?
We assume you can't reliably stop the model from being prompt injected. So nothing is enforced at the model layer. Enforcement happens at the proxy, which sits between the agent and the downstream API and is the only thing holding the credential. The agent never sees the key, so an injected agent can't exfiltrate it or route around the deterministic policy.
For irreversible actions you stack three things:
1. Method/endpoint restrictions. "This agent may only GET under /instances/*" means a DELETE never reaches the provider. For infra agents we'd push read-only by default and allowlist the few mutations you need.
2. Human-in-the-loop on the dangerous ops. Approval can be required conditionally: on DELETE, on specific operations, or when a parameter matches (resource outside the allowed set, etc). The request is frozen server-side, so what the approver sees is exactly what executes. The agent can't swap the payload after the yes.
3. Audit logs on every call, including denials, with the agent and end-user identity attached. So you can see the agent tried a DELETE it wasn't allowed, on whose behalf, and with what body.
Basically we treat every call like a compromised laptop: don't assume it behaves, scope the credential, and gate the risky actions behind a second party. Would love to hear more about your setup.
We are planning to do the policy check as much determistic as possible with OPA rules and so on, but we also have the policies in place at cloud level
On the compliance subagent, the one thing I'd watch is that it reads the same untrusted context as the agent, so it can be injected too. We treat the model as advisory only. We have an AI review rule that rates a request's risk, but it can only escalate to a human approval. It can't deny, and it can't allow anything the deterministic rules didn't already allow, so a fooled reviewer costs you an extra approval, never a bad action. Your impact-level classification maps pretty directly onto that.
Really good point about using the same context for the compliance, currently it's a separate subagent but read rules/policies and then check against the other agent proposal, no possible to inject since we control totally via a rail the prompt for the compliance subagent but it's true that it checks policies so it's not deterministic (works pretty well but not deterministic) so that's we are targeting checking that policies deterministically with OPA and then the compliance will only add to the final result some other checks that need to be LLM inferences.
So it's pretty similar to yours, you have any other additional harness to be as much determistic as possible?
The real value of alter comes in when you want to give your agents access to end users credentials. When agents act on behalf of end user as a developer you have to manage multiple credentials and more importantly manage the mapping relationship between end user identity and the credentials.
Also, as agents take actions the problem of non deterministic actions become more pronounced. With alters policy guardrails any chance of actions taking negative actions is mitigated.
Lastly, the full compliance trails of what the agent has done ends up being quite valuble especially as agents take more autonomus actions!
For a security-centric product, how would I trust your fully vibe-coded product if I can't see the source code?
We are currently in the process being fully SOC2 compliant and have gotten pen tested twice from two different companies and have found no issues. You can explore the full extent of our security process and pen test results here : trust.alterauth.com
Separately would say it is a bad assumption to make that a product is vibe coded without trying it out. As mentioned in the post we adopted a lot of security processes as a part of our SDLC including consistent scans for supply chain attacks, and static code scanners (SAST).
We also do a pen test at a yearly cadence
You've put it behind a very typical AI-generated UI; like the many that come up every day. In your case, it's an auth product and it matters more. Besides, It's difficult to try your product without handing you the keys to the kingdom.
> We are currently in the process being fully SOC2 compliant
You're getting a Type I attestation first, I presume? That is of limited value in itself, and is mostly about getting to Type II. If you already have Type I complted, you could mention that on the website. "Regulated industries" have long sales cycles and evaluations, and you'll find it difficult to start those conversations without a more reassuring website.
Regarding SOC2, in the process of getting SOC2, Type 2 compliant. As you may know there is 3 month waiting period before the auditors give a SOC2 certification so currently in the waiting period for that
On your three controls:
- Per-action caps: rules can match request params numerically, so "deny if amount > 5000" works today.
- Approval above a threshold: same matching drives human approval, e.g. "require approval on payments where amount > 1000". The approver sees the exact frozen request that will execute.
- Rolling daily budget: not built yet. Today we have per-agent quotas that count calls per minute/hour/day, but nothing that sums amounts across calls. We have the pieces (amount parsing per call, per-window counters, approvals), so it's a natural next rule type.
What happens if the agent agent can bypass the proxy?
So say the agent goes around us and hits the API directly. It has nothing to authenticate with, and the provider returns a 401. It also can't use us to leak the credential: for API-key credentials, we only inject them into requests going to hosts you've allowlisted for that provider, so pointing the call at its own server gets blocked before the key is attached.
To make it airtight, mint the agent's Alter key with proxy-only permission. We also have a mode where the SDK fetches the token for each call, but that's a separate permission and a proxy-only key can't use it.
Where it does break down is credentials we don't hold. If someone leaves a personal API key in the agent's environment, the agent can use it directly and we'll never see that traffic. Locking down outbound network access closes that gap, but that's on your infra side.
short answer is no, the policy engine doesn't know where an argument came from across calls. each call is judged on its own: which agent, which end user it's acting for (plus the delegation chain), which grant, which operation and the params on the request. so in your example the contractor's send passes if their policy allows it
we put the controls at the two ends instead of following the data through the middle - write side: the CEO's grant posting into a shared channel is its own call, so you can require approval for it or just deny it - send side: we parse sends into recipients, so a contractor can be limited to emailing inside the company domain, or anything external needs a human approval on the exact frozen request
every call is audited with the agent, end user and grant, and calls in the same run share a trace id. your case spans two sessions though, so the thing linking them is the slack message itself, not a trace
your noise point is honestly why we haven't done taint tracking yet, the "user typed the address but it was also in tool output" case is exactly the hard bit. it's a really interesting scenario though, we'll look into whether it makes sense for us to support this kind of thing natively.
Asking because I keep running into this with agents that talk to other people's agents, and the audit part worries me more than the permissions part.
Each agent can delegate a subset of its permissions. So if agent A started with the users permissions, it can delegate all of user A's permissions or a subset of user A's permissions.
In your case specifically the agent can delegate part of the permissions it has to the other agent to do part of the job. It can be as granular as you want it and its fully audited!
We have seen this explicitly become a problem for agent deployments like the ones you described. A lot of our initial users have built multi user, multi channel agents and need to keep track of end user identity through out that interaction. If you are interested in using alter for your concierge agents let us know! Would love to help out and onboard you ourselves.
We integrate with IDPs and allow agents to send little sign up links within chat interfaces so your agent can know exactly who its chatting with and enforce end user permissions and memory segregation
A few things to sanity-check / ask about in any solution:
1. *Where is authorization enforced?* If the CRM/billing side only sees one API key identity, then the enforcement has to happen before requests leave your system (an authorization gateway), not “inside the agent” at best-effort level.
2. *Do you achieve least privilege per user?* Ideally: user-specific tokens (scoped OAuth, per-user API tokens, or a token exchange that mints short-lived credentials with constrained scopes). If not possible, you need an explicit mapping of user → allowed operations → resource set and block everything else.
3. *Strong auditability / attribution (“who did what?”).* You want logs that can answer, after the fact: user X initiated action Y on resource Z at time T, and which policy decision produced it. If all you record is “the shared credential called endpoint /charges”, you’ll struggle when banks/investors/auditors ask for evidence.
4. *Confused-deputy and prompt-injection controls.* Multi-user agents are basically “capability routers” for untrusted inputs. You need to treat the agent as potentially tricked and ensure policy checks are independent of the model’s output. Practical controls: structured tool calls, server-side validation of parameters against policy, and disallowing free-form “apply changes” operations.
5. *Resource-level authorization, not just action-level.* “User can update invoices” isn’t enough—you usually need “user can update their invoices/customers.” That implies resource ownership/tenant mapping and consistent ID normalization.
6. *Approvals and reconciliation for high-risk actions.* For destructive or money-moving operations, require an approval step and keep a reversible trail (request → approval → execution → final receipt).
If you’re replying to the “shared key” scenario, I’d be curious how you handle: - user-to-resource mapping (tenant/customer ownership), and - whether every outbound request is intercepted for policy checks with deterministic logs, rather than relying on the agent’s behavior.
Most “access control for agents” demos skip one of those, and that’s where incidents come from.
- every outbound request goes through our proxy. the agent never holds the downstream credential so there's no path around it, and policy is evaluated deterministically there, not by the model. every call gets an audit row, denials included, with the agent, the end user it was acting for, the delegation chain, the grant, the operation, and the policy decision plus which rule produced it. so "user X did Y on Z at T and here's why it was allowed" is answerable after the fact
- User to resource mapping, honest answer is it depends on the credential. Where the provider supports it we push per-user oauth, so each end user connects their own account and the provider's own ownership checks apply. that's the cleanest least privilege - With a shared key we can't know who owns invoice 123 unless something tells us. what we do have is rules on the operation and its params (methods, paths, ids, recipients, amounts), so you can pin a user or agent to specific resources. but we don't keep a general ownership graph of your customers' data, that mapping still lives with you or the provider
On the rest: agents can only ever get a subset of the user's permissions (delegation narrows, never widens), money moving and destructive ops can require human approval on the exact frozen request, and our ai review can only escalate to a human, never allow something the rules didn't