// the find
ThinkWatchProject/ThinkWatch
Self-hosted AI API and MCP gateway for organizations: SSO and RBAC, per-user identity for MCP tool calls, PII redaction and tool-call guards, rate limits, budgets, cost accounting and audit logs.
ThinkWatch is a self-hosted gateway that sits in front of model providers (OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI) and MCP servers, adding OIDC sign-in, RBAC, rate limits, budgets, PII redaction, tool-call inspection and ClickHouse audit logs. It is aimed at platform and security teams who need to control which people in an organization can spend on AI and what their agents can do through MCP tools.
The most distinctive part is per-user identity for MCP: each user's own upstream OAuth grant or personal token is used for tool calls, so the upstream's audit log shows the real person, and tokens are encrypted at rest. The guards start in observe mode on new installs, so a team can see what would be redacted or blocked before anything in a request changes. The test tree lists more than sixty integration test files under crates/test-support/tests, covering mock providers, Postgres and ClickHouse fixtures, failover, streaming, and authz, which is a better sign than the feature list alone. One port accepts OpenAI Chat, OpenAI Responses, Anthropic Messages and Gemini requests and converts them to whatever the upstream speaks, which matters for mixed client fleets.
The license will be the first obstacle for an adopter. This is Business Source License 1.1, not an OSI open-source license, and production use above 10 million billable tokens or 10,000 MCP tool calls a month needs a commercial license. Two defaults deserve a second look: rate limits fail open when Redis is down unless security.rate_limit_fail_closed is set, and all three guards ship in observe mode, so out of the box nothing is actually redacted or blocked. Redaction skips base64 payloads, and the rules are phrases, regular expressions and code points, so a determined caller can route around them; the protection is only as good as the rule set someone maintains. The operational footprint is heavy for one team, since PostgreSQL, Redis and ClickHouse all have to run, and the guard crates come from a separate repository (ThinkWatch-Core), which means guard fixes depend on that project's release cadence.