The Gate Health check

When the AI says nothing, refuses, or can't find a file, the cause usually sits earlier in the chain than the symptom. The Health check walks that chain 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. Every check is read-only and recorded in the audit trail.

Run it

1. In the Gate console, open Health check → Run all checks.
2. Fix the row marked Start here first; later rows often clear on their own once it is fixed.
3. To follow one person end to end (their AD account, groups, tools and each mapped drive), use Test this person.
4. Each row links to its page here. Copy report gives you the whole result as text for a ticket.

Results: OK fine · Check works, needs a look · Problem broken, fix this · Info or Skipped not in use here.

Gate

• Database: Gate asks its database a trivial question.
• Audit chain: Every audit row carries a hash of the row before it.
• Guardrails: Shows how your rules are being applied: learning mode (no rules yet), dry run (rules recorded but not enforced) or enforced..
• SIEM streaming: Looks at each streaming destination you added and whether its last delivery worked..
• Data filter: Runs a test card number and Social Security number through your data filter to prove it redacts them before text reaches a model..
• License: Checks that this organization may use Gate: a license file on the on-prem editions, the monthly subscription on the hosted edition.

Active Directory

• Connected: Whether this Gate is connected to your Active Directory domain.
• Gate's service account: Asks the domain controller for a Kerberos ticket as Gate's own account.
• Directory lookups (LDAP): Looks up the directory over an encrypted, Kerberos-signed LDAP connection, the way Gate reads people and groups..
• People and groups sync: When Gate last copied people and groups from AD, whether it worked, and whether the regular sync is still running.

Sign-in

• Windows sign-in (Kerberos): Checks that the HTTP/ service name for Gate's address is on Gate's account, so browsers on domain PCs can sign people in with their Windows logon..
• NTLM (older PCs and apps): Only when NTLM is turned on: checks that a domain controller can verify NTLM answers for Gate, and that relay protection can read the certificate browsers see..
• Chat app talking to Gate: Whether a chat app (Open WebUI, or another client) has a company connection to Gate and has recently asked Gate for tools..

Apps and files

• App: (each connected app): One row per app you connected (each is an MCP server Gate fronts).
• File shares: service broker: Windows Server edition only.
• File shares: delegation: To open a file share as a person, Gate needs Active Directory's permission to ask for that person's ticket to the file server (constrained delegation with protocol transition), limited to your file servers and domain controllers.
• File shares: SYSVOL policy access: Gate learns each person's mapped drives from your Group Policy drive maps, which live in SYSVOL on the domain controllers.
• File shares: Access-Based Enumeration: For each share someone has mapped, checks whether Windows Access-Based Enumeration (ABE) is on.

Person

• Gate account: From Health check → Test this person: whether the person's Gate account is active, their role, and how they sign in..
• Active Directory (live): Looks the person up in AD right now (not the last sync): are they linked, still in scope, and enabled?.
• Groups Gate uses: The role and groups your guardrails see for this person, compared with their live AD groups..
• Tools their AI gets: Applies your current rules to this person and lists exactly which tools their AI is shown..
• Share (each mapped drive): For each drive Group Policy maps for this person, asks your rules and then Windows itself, by listing the top of the share as them (names are not returned, only allowed or refused).
• Recent activity: When this person's AI last used Gate, and through which client..