Alter Explained: Access Control for Multi-User AI Agents

Alter's founders introduced their multi-user agent access-control platform on October 21. It proxies API calls, checks whose authority an agent is using, and applies policies before the request reaches another service. For teams connecting agents to customer systems, the useful distinction is between signing someone in and controlling what happens next.

The Launch HN announcement describes a free tier of up to 10,000 requests and usage-based pricing beyond that. It does not specify the paid rate or the free allowance's reset period. The founders also describe an LLM gateway with guardrails as coming soon, not an available part of this launch.

Why signing in is not enough

Imagine a support agent used by several employees through Slack. Each employee has an identity, but the agent accesses the customer database using one broad service credential. Authenticating the person in Slack does not automatically restrict the database request to that person's permitted customers.

That mismatch is the problem Alter addresses. The permission check needs to happen where the action happens, rather than depend entirely on the model remembering instructions about access.

This also changes what an audit needs to record. Knowing which model generated a tool call is less useful than knowing which person, agent and grant authorized the resulting operation.

How Alter's proxy and policies work

Alter's platform documentation describes a credential vault, a policy engine, agent identities and human approval gates. In the full-proxy mode, Alter adds the downstream credential to the outgoing request and returns the provider response. It also supports an in-process retrieval mode, so keeping secrets outside the agent depends on choosing and enforcing the appropriate path.

Policies can restrict methods and endpoints, inspect parameters, redact fields or require review. A request held for approval is frozen and checked for integrity so the reviewed operation is the operation that executes. These are documented product behaviors, not results from an independent security test.

For the support example, a read-only lookup and a refund should not inherit the same permission merely because both use the same billing integration. The policy can treat them as different operations, with a human gate on the consequential one.

Giving each agent limited access

The scoped-agent guide separates provisioning an agent from binding credentials to it. An operator creates the identity and capability allowlist, then connects an operator-managed secret or a user's delegated OAuth grant. The running agent uses its own key rather than the application's entire credential store.

Delegation can narrow permissions and expiry for another agent. The child grant cannot broaden either boundary, and revocation cascades through its descendants. This matters when a coordinator asks a specialist agent to perform one step: the specialist should receive the access needed for that step, not everything the coordinator can use.

A developer still has to map the application's business rules into those controls. Having a valid credential does not by itself answer whether a particular employee may access a particular customer record.

API permissions do not automatically isolate memory

The most useful question in the launch discussion concerned shared agent memory. An API call can be properly authorized while the information it returns later enters a context that another user can read.

Alter's memory integration guide defines a private boundary using the verified application, acting agent and represented user. It provides a scoped store wrapper and requires live identity resolution for operations. Developers retain responsibility for additional sharing rules and for keeping the raw store outside the agent's unrestricted reach.

A namespace label is not an authorization credential. The docs explicitly distinguish the two. If an agent can bypass the wrapper and query the underlying database, adding identity-aware namespaces does not fix that separate access path.

What developers should evaluate

Alter is most relevant when one agent service acts for several people across external systems. Before adopting it, a team should trace one complete operation: authenticated user, delegated grant, policy evaluation, provider request, stored result and later retrieval.

That exercise exposes the real integration work. A proxy can make downstream actions easier to control, but the application still needs coherent boundaries for outputs, memory and shared conversations. The useful test is whether the same identity remains meaningful across all of them.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn agent infrastructure and product updates into clear stories developers can understand and share.

Book a 30-minute call.