Connect an AI
Point any AI assistant at Gate and it works as you. It can only see and do what you already can; everything it does is logged under your name.
Your Gate endpoint
One URL for every client. Authenticate with a personal token (below), or with your Acutis session when the client is Carlo.
What this AI can do as you
A live check against the rules in force: exactly which apps and actions an assistant gets when it connects as your account.
Open WebUI · your local AI
One connection for the whole company: Open WebUI tells Gate who is chatting with a signed, five-minute identity, and Gate runs every tool call as that person. Nobody pastes a token. Needs Open WebUI 0.6.31+ and a Gate account with the same email for each person.
Just me, no admin
- Admin Panel → Settings → External Tools → +, type MCP (Streamable HTTP)
- URL: the endpoint above; Auth: Bearer → your personal token
Only for a one-person Open WebUI: a shared Bearer token makes everyone who chats there act as you.
Claude Desktop
Claude Desktop reaches remote MCP servers through mcp-remote. Add this to claude_desktop_config.json (Settings → Developer → Edit Config):
Cursor / VS Code
Create .cursor/mcp.json in your project (or .vscode/mcp.json for Copilot):
Carlo (Acutis AI)
Carlo on the Floor already runs as your account. Gate adds the audit row and the policy check to every tool call Carlo makes, no setup.
My apps
Every app your AI reaches uses your own sign-in or key, never a shared one. The AI can only do what you can already do in that app. Connect once; it is stored encrypted and only ever sent to that app.
Windows file shares
checkingThe AI opens these shares as the person asking, with their own Windows file permissions: if they cannot open a folder in Explorer, their AI cannot either. Gate never uses a shared account and never stores anyone's password; Active Directory hands Gate a ticket for that person (constrained delegation). Guardrails can narrow it further, for example files://**/Legal/**.
Add an app for everyone
Any app that speaks MCP over HTTP: Microsoft 365, the HR system, finance, CRM, firewalls, monitoring. Choose how people sign into it. Own key and own sign-in mean every request carries that person's identity. Shared account is a labelled fallback for apps with no personal login.
Actions appear to assistants as shortname__action; guardrails address them as shortname://tools/<action>. Read-only actions are the ones the app marks readOnlyHint; everything else counts as a change.
Approvals
Actions a rule marked approve wait here. An approver runs them as the person who asked, with their authenticator code. Approval never changes who the action is attributed to.
Audit trail
Everything, hash-chained. Every tool call with its full arguments and result, what each person's AI was shown, failed sign-ins, and every policy, group, identity, app and token change. Click a row for the payloads and hashes. Admins see the whole organization; everyone else sees their own. The same rows stream to your SIEM from Streaming.
License
This Gate runs on a license from your Acutis account. A seat is an active person in Gate's scope (the Active Directory group you chose at connect time, plus any local accounts), so you control the count by managing that group.
This Gate
checkingLoad a license
Download the license file from your Acutis account at app.acutisgo.com, then choose it here or paste its text. Gate checks Acutis' signature on this server; nothing is sent anywhere, so it works without internet access.
Health check
When the AI says nothing, refuses, or cannot find a file, the cause is usually somewhere earlier in the chain. These checks walk it in the order a request travels: Gate itself, Active Directory, sign-in, then the apps and file shares. The first problem is marked Start here, with what Gate saw and how to fix it. Everything is read-only and recorded in the audit trail.
Whole system
not run yetTakes a few seconds. Nothing is changed.
Test as a person
pick someoneWalk one person's whole path: their account, their Active Directory account (read live), the groups the guardrails see, which tools their AI gets, and for each file share what the guardrails say and what Windows says. Shares are opened as that person read-only; file names are not shown.
Test Windows sign-in from this browser
not run yetRuns the real Windows sign-in from this PC and says who it would sign in as, by Kerberos or NTLM, without signing anyone in. Use it on a person's PC when they see a login page instead of being signed in.
Identity
Where your organization's sign-in comes from. Gate never stores passwords; it trusts the directory you already run and turns its users and groups into the people the guardrails talk about.
Google Workspace
available"Sign in with Google" for your whole domain. People sign in with the account they already have; MFA is enforced by Google.
Active Directory
checkingWindows sign-in from any domain-joined PC: no login page, and no password ever sent to Gate. People and their groups (nested included) come from AD and stay in step with it; someone disabled in AD is disabled here, at the latest by their next sign-in. The service account password is used once to derive Gate's Kerberos keys and is never stored.
Browser setup: one Group Policy
Edge and Chrome only send a Windows sign-in to sites you allow. Run this once on a domain controller (it creates and links one GPO), then people get signed in on their next policy refresh. Open Gate by its DNS name, not an IP address.
ADFS / SAML
in buildFor organizations that front everything with ADFS or another SAML provider. One relying-party trust; the assertion's user and groups become the person. On-prem systems still get called as them through protocol transition.
Microsoft Entra ID
in buildOpenID Connect sign-in and Entra groups for cloud-first and hybrid organizations. Pairs with Active Directory below for the on-prem half.
Okta
in buildOpenID Connect sign-in and Okta groups. Also the path for Cross App Access, so cloud apps that support it receive the person's identity directly.
RADIUS
in buildUsername and password checked against your existing NPS or FreeRADIUS server, with its reply attributes (Filter-Id, Class) mapped to groups. For environments standardized on RADIUS, including network and VPN teams.
Guardrails
Who may use AI on which apps, and how far it may go. A fresh Gate starts in learning mode: everything is allowed and recorded, so you build the first guardrails from what people actually did. Once you save a policy, nothing is allowed unless a guardrail says so. Block always wins over Allow; Needs approval stages the action for an approver; Break-glass runs at once but requires a stated reason. Guardrails can only make AI tighter than people's existing permissions, never looser, because every allowed action still runs as that person.
Add a guardrail
Read it as a sentence: who may do what in which app.
Try it as a person
What would Gate decide, right now, for this person? Uses the guardrails above, including unsaved changes.
Version history
Advanced: edit the guardrails as JSON
Same rules, raw. Resources are app://tools/<action>; * stays inside one segment, ** crosses them.
Data filter
What comes back from an app passes through Gate before the model sees it. These patterns are redacted (or the whole result blocked) on the way in, deterministically, and the audit row counts what was removed. Values are never stored.
Groups
Rules can target group:<name>. With Active Directory connected (Identity), each person's AD groups, nested ones included, appear here and follow AD: change them in AD and the next sync or sign-in picks it up. Add manual memberships for anything AD does not have.
Streaming
Your SIEM is the system of record; this console is for running Gate. Every audit row streams as it is written to the destinations below: syslog over UDP, TCP or TLS in JSON or CEF, an HTTPS webhook with an HMAC signature, or Splunk HTTP Event Collector. Delivery runs off the request path, so a destination that is down never slows an AI call; its last error shows here instead.
Destinations
Add a destination
Adding one asks for your authenticator code when you have one: a destination receives the whole trail, payloads included.
What gets captured
Hashes of every argument set and result are always chained. The payloads themselves are stored and streamed according to these switches. Changing them is itself an audit event.
Pull instead of push
Collectors that poll can page the trail as NDJSON with a cursor, or hold the live stream open.