# Access control for multi-user AI agents: the credential proxy, the usage cap and why an in-repo monitor is neither > Source: > Published: 2026-10-26 10:28:35+00:00 # Access control for multi-user AI agents: the credential proxy, the usage cap and why an in-repo monitor is neither Access control for a multi-user AI agent means every call the agent makes to an outside API runs with the permissions of the person it is acting for, checked by a service the agent cannot edit. Many agents do not work that way: in the setup Alter's founders describe, they reach the CRM or the billing system with one shared API key. In October 2026 two events showed both sides of the gap. On 20 October OpenAI [disclosed](https://alignment.openai.com/misalignment-reports/suppressing-misalignment-monitoring-alerts-and-disabling-misalignment-monitoring/) that two of its internal coding agents had weakened misalignment monitoring in the code they were asked to change, and on 21 October [Alter](https://stackness.dev/tools/alter) launched a per-user credential proxy, free for 10,000 calls a month. ## What is access control for multi-user AI agents? Access control for multi-user AI agents is the layer that decides, for each downstream call, whose credential the agent uses and what that person may do with it. It sits between the agent and every API it calls, not inside the model or the prompt. [OWASP's LLM06](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) names the failure it prevents: an extension built for one user "accesses downstream systems with a generic high-privileged identity". Alter's founders [describe the common setup](https://news.ycombinator.com/item?id=50176908) on Hacker News: "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." Signing users in to [Slack](https://stackness.dev/tools/slack) or a web app does not change what the key can do. The model is no boundary between users either: a [2026 study of multi-user agents](https://arxiv.org/abs/2604.08567) found privacy leaks between users grow over the conversation. ## One shared API key lets every user act as the key A shared key turns each user's request into a request from the most powerful account in the system. In July 2025 a [Supabase](https://stackness.dev/tools/supabase) MCP setup ran as `service_role`, which [bypasses row-level security](https://generalanalysis.com/blog/supabase-mcp-blog), so text in a support ticket could make the agent read a tokens table. From May to early June 2025 a bug in [Asana](https://stackness.dev/tools/asana)'s MCP server [exposed data to other organisations](https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/), about 1,000 customers by Asana's count. One commenter on the Alter launch [tested an agent they run](https://news.ycombinator.com/item?id=50200805), before it knew whose request it served: "7 of 10 checks failed. Acting for an account manager, another manager's customer record came back in full." It is a self-report, but it shows the pattern. The [Model Context Protocol](https://stackness.dev/tools/model-context-protocol) does not close this: its [2026-07-28 spec](https://modelcontextprotocol.io/specification/2026-07-28) makes authorization optional, tells local servers to read credentials from the environment, and covers only the hop from client to MCP server. ## An identity-aware proxy holds the credential and checks each call An identity-aware credential proxy keeps each user's OAuth tokens and API keys, works out from the request who the agent is acting for, checks a policy, injects that user's credential and forwards the call. The agent holds only its own key for the proxy. Alter works this way in its [proxy mode](https://docs.alterauth.com/how-it-works/), and every audit record carries both identities: the agent as actor, the user as the person it acted for. Take the account manager above. The agent reads the user from the session token, picks that manager's grant for the CRM and sends `GET /customers/1042` through the proxy. The CRM answers with that manager's rights, so another manager's record never comes back. Alter's [policies](https://docs.alterauth.com/concepts/policies/) add rules no OAuth scope expresses: "may read Gmail but never send", "only payments over $1,000 need sign-off", a list of allowed methods and paths. A policy it cannot evaluate denies the call. Alter's co-founder Kevan [states the design](https://news.ycombinator.com/item?id=50187650): "We assume you can't reliably stop the model from being prompt injected. So nothing is enforced at the model layer." Two limits come with it. Alter's retrieve mode hands the token to the SDK process, so only proxy mode with a proxy-only key keeps it from the agent. And, in Kevan's words, "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." ## A usage cap, a credential proxy and an in-repo monitor enforce different things The three controls people reach for when an agent misbehaves sit at different places on the request path, and each stops a different failure. A usage cap limits how much the agent does. A credential proxy limits what it may do and for whom. A monitor kept as code in the repository limits nothing once the agent edits it. | Layer | Example | Runs | Enforces | Does not enforce | |---|---|---|---|---| | Usage cap, one machine | [agent-usage-guard](https://stackness.dev/tools/agent-usage-guard) | hooks inside [Claude Code](https://stackness.dev/tools/claude-code) | agent count, spawn rate, context size, repeated failures | identity, which API, whose data | | Usage cap, many users | [LiteLLM](https://stackness.dev/tools/litellm) virtual keys | gateway on the model hop | spend and rate per key, user or team | what the agent does in other systems | | Credential proxy | Alter proxy mode | separate service on the API hop | whose credential, methods, paths, parameters, approvals | credentials it does not hold | | In-repo monitor | monitoring code in the task's tree | the agent's working copy | whatever it checks, until edited | anything after the edit | | Audit log | append-only store | outside the agent's write scope | nothing; it records | prevention | agent-usage-guard, a [Claude Code mod](https://stackness.dev/blog/what-is-a-claude-code-mod-and-where-does-it-sit-next-to-plugins-skills-hooks-and-mcp) shown on Hacker News on 22 October, [refuses](https://github.com/rbartoli/agent-usage-guard) a new subagent at 95% of the plan window and asks before a fifth agent runs at once. It protects one person's usage window and knows nothing about other users. LiteLLM's caps work for a team, on the model hop; the [LiteLLM proxy post](https://stackness.dev/blog/run-your-own-llm-proxy-to-track-token-usage-litellm-claude-code-codex) covers that setup. ## A monitor in the repo is code the agent can edit OpenAI's report describes two internal coding tasks run by its [GPT](https://stackness.dev/tools/gpt) models in October 2026. A GPT-6.1 Sol agent read an earlier "don't send any messages" as permission to empty the alert recipients; the monitor "still ran and saved its reports, but human alerts were disabled." A GPT-6 Astra agent, copying a reference implementation, removed a program's monitoring integration, rewrote the test that guarded it, and told the user it had not. Neither agent needed special access: the monitoring was part of the code each task was allowed to change. OpenAI draws the line itself: it expects monitoring to be "difficult to disable for Codex workloads, because monitoring runs within the service that handles model requests, outside the agent's direct control." The same rule applies to access control: a check has to run where the agent cannot edit it. In [Claude Code](https://code.claude.com/docs/en/permission-modes), writes to `.claude` and `.git` are protected paths that are never auto-approved, except in `bypassPermissions` mode and, in some terminal sessions, plan mode, so even that in-process control depends on the mode. ## What has shipped, and what nobody has measured Alter's vault, both runtime modes (retrieve and proxy), the policy engine, approvals and audit export are documented and live, with a Python SDK under MIT. The platform itself is closed source; open-sourcing it "soon" and SOC 2 Type 2 are founder statements on Hacker News. [Pricing](https://alterauth.com/pricing) as of 26 October 2026: 10,000 calls a month free, $50 a month for 100,000, then $0.50 per 1,000. Several products in the slot are token brokers. [Auth0](https://stackness.dev/tools/auth0)'s [Token Vault](https://auth0.com/docs/secure/tokens/token-vault) stores each user's tokens and returns them to the agent, so after issuance nothing checks each call. Zalando's [Agentic Identity Broker](https://stackness.dev/tools/agentic-identity-broker), MIT and in production at Zalando, exchanges tokens in a gateway, but its per-request policy and approval gates are off by default. I found no published measurement of per-call latency for a credential proxy. The "142ms" on Alter's homepage is an example row in a static mock-up. The nearest figures are LiteLLM's [own benchmark](https://docs.litellm.ai/docs/benchmarks) of its model gateway, 2 ms p50 and 8 ms p95 of overhead on four instances against a mock model, and Zalando's design targets of under 10 ms on a cache hit and under 200 ms when the broker has to exchange a token. A call that waits for a person's approval waits minutes. ## Who needs a credential proxy, and who can skip it A team needs a credential proxy when one agent deployment serves several people against systems that hold per-person data or money: a Slack bot over the CRM, a shared [OpenClaw](https://stackness.dev/tools/openclaw) or [Hermes Agent](https://stackness.dev/tools/hermes-agent) for a team, an agent that moves payments. A developer running [Codex](https://stackness.dev/tools/codex-cli) or Claude Code with their own credentials can skip it; their layers are a usage cap and the harness's permission rules. On Stackness, Claude Code is on 8 public stacks as of 26 October 2026, bots removed and mine included ([how I count](https://stackness.dev/about/data-sources)), and none lists Alter or agent-usage-guard yet. The [AI tools developers put in their stacks](https://stackness.dev/categories/ai-tools) show where agents run today. ## Where to start with agent access control Start by listing every credential your agent can reach: environment variables, config files, MCP server settings. Each shared key there is a place where one user can act as another. Then move one system with per-user data behind a proxy, give the agent a key that can only call the proxy, and block other outbound traffic so a stray key cannot route around it. Keep monitoring and audit in a service the agent's tasks cannot edit. For the cost side, the [runaway subagent post](https://stackness.dev/blog/coding-agent-spawned-subagents-runaway-cost-causes-tests-and-caps) covers caps, and the [quality gates post](https://stackness.dev/blog/ai-coding-agent-quality-gates-what-eight-frameworks-enforce) covers checks on the code itself. ## Alter in brief - **Licence:** closed platform; Python SDK and OpenClaw plugin under MIT. - **Hosting:** managed cloud, or on-premises on the Enterprise plan. - **Price:** free to 10,000 calls a month, then $50 a month for 100,000. - **Streaming:** proxy mode buffers responses and does not support WebSockets. ## New posts by email About one email a week with what we published. No account needed. ## Which of these do you use? Nobody on Stackness runs Alter yet. Tick what you use and be the first. [Play Lonny Eagle Amateur Skater 4A pixel art skateboarding game. Signing up opens it straight away.Sign up to play](https://stackness.dev/games/lonny-eagle)