Security1 publisher2 min readPublished
Open-source Authorizer checks user permissions before AI search ranks company files
Authorizer, a self-hosted open-source auth server, drops files a user may not see before an AI assistant's vector search scores them. Teams can run that check inside their own login server, though its limits on AI agents rest on the maintainers' word.
The Watch · Security desk
What happened
- Vector search, the lookup that finds text similar to a question, returns close matches without checking who asked it.
- Authorizer embeds OpenFGA, an open-source take on Google's Zanzibar that records access as relationships, such as one user being able to view one file.
- Its built-in MCP server, the interface Claude Code and Cursor use to call outside services, exposes three read-only functions: profile, check_permissions and list_permissions.
- The maintainers say that MCP server runs only over local stdio and cannot be reached over a network.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- cost The filter can only drop files OpenFGA knows about, so the adopting team has to write each file's viewers into it as relationships and keep those records current.
- constraint With only read functions on the MCP interface, a confused or hijacked agent can look up permissions but has no function that grants it more.
- exposure Because teams host it themselves with accounts in their own database, the operator carries the patching and breach risk for a server that also decides which documents an assistant may read.
The leak Authorizer targets takes no skill to trigger [3]. Say a team loads a shared drive into its assistant's index. An employee asks a question, and the lookup returns the closest passages without checking whether that employee could open the files they came from [3]. The model reads whatever comes back. Help Net Security says the problem affects any team that connects an AI assistant to company files [13]. The report does not cite a leak incident or an outside test of the maintainers' claims.
Authorizer's maintainers built the permissions engine and an interface for AI agents into the same Go program that logs users in [2]. A chatbot can therefore ask whether a user may see a document before it fetches that document [2]. According to the maintainers, an agent acting for a user gets only the overlap of its own permissions and that user's [11]. Under that rule, an agent with broad rights of its own still sees no more than the person it works for, and an agent with narrow rights sees less than that person [11].
Everything else in the server is a standard login stack. It handles email and password, magic links, passkeys, social login through 10 providers and one-time codes for multifactor authentication [5]. Single sign-on runs over SAML 2.0 and OpenID Connect, the protocols used by corporate identity systems such as Okta [6]. Accounts can live in any of 13 or more databases, including PostgreSQL, MySQL, MongoDB and DynamoDB [7]. The code is free on GitHub [12].
What to watch
- An independent test of the maintainers' claims that the MCP server is reachable only over local stdio and that agents are capped at the user's permissions.
- Any release that adds write functions or a network transport to the MCP interface; either would widen what an agent can reach through it.
- How Authorizer keeps OpenFGA relationships in step with the permissions already set in the file stores an assistant indexes.