# IT-AI security and trust > How IT-AI limits an AI with root on your fleet: outbound-only agents, per-device secrets, scoped tokens, deny-list, audit, JIT admin, and known gaps. Canonical page: https://glick.run/it-ai/security.html An RMM agent can run code as root or SYSTEM on every machine it manages. Adding an AI that can call it raises the stakes. This page answers the questions a security team should ask about IT-AI, including the ones where the answer is "not yet". Facts here come from the agent's public repository and the hub's documentation, as of agent v3.9.0. ## Can the AI run commands without me? It depends on what you connect it with. - **The hub's built-in assistant cannot.** It inspects with read-only tools and an allowlist of read-only commands, then proposes a fix from a fixed, server-side menu. The fix runs only after a person clicks **Apply**. The approval gate is enforced on the hub, not in the AI's tool loop. - **Your own AI over MCP can, if you give it a write token.** A `write` token lets it run commands, install software and push files. Each call is still checked against your deny-list and written to the audit log before the device is contacted. Your MCP client (Claude Code, for example) can ask you before each tool call, but that prompt is the client's, not the hub's. - **A read-only token cannot.** The hub answers `403 this MCP token is read-only` to every write action. MCP tokens are minted per user with a scope (`read`, `write` or `admin`) and an expiry (30 days by default). The tool-by-tool list is on the [MCP page](https://glick.run/it-ai/mcp.html). ## Can you, the vendor, see my screens? No. You run the hub. Screens, shell output, files and telemetry go from your devices to your hub and to whoever you authorize on it. The agent has no hardcoded hub or vendor address: the hub URL and token are parameters you set at enrollment. There is no glick.run service in the path. ## Where is the API key? The hub's AI assistant uses an Anthropic API key that you set on the hub (`ANTHROPIC_API_KEY`). It never reaches a managed device or the browser. If you use your own AI over MCP, that AI's key stays with your MCP client. IT-AI never sees it. ## Does traffic route through your servers? No. Devices connect out to your hub over HTTPS and hold the connection open, so they need no inbound port and no public address. When a controller and a device share a LAN, traffic can go direct: the agent listens on port 8765 on its LAN addresses, over TLS with a hub-signed certificate, and each direct call needs a 60-second ed25519 capability that your hub mints only after its ownership, deny-list and audit checks. Set `HIVE_LAN=0` on the agent to turn that listener off and bind loopback only. ## How are agents authenticated? - **Enrollment** needs a personal token (`htok_…`) minted for your account, so a device is owned from the moment it enrolls. You can rotate the token. - **Per-device secrets.** On its first connection the agent gets its own secret (`hdev_…`) and uses it from then on. The secret is valid only for that device, stored in a 0600 file rather than on a command line, and kept on the hub only as a SHA-256 hash. You can revoke one device without touching the others. - **Per-user ownership.** With identity configured, a user sees and drives only their own devices, and authorization fails closed. ## How are agents signed and updated? - **Self-update is signed.** An agent replaces itself only with a binary whose **ed25519 signature** matches a key pinned in the agent, downloaded over HTTPS. A hub that lies about the checksum can delay an update but cannot install an unsigned build. - **Releases are verifiable.** Each [GitHub release](https://github.com/gitayg/haive-agent/releases) ships a `SHA256SUMS` file, a `.sig` file per binary, and a Sigstore build-provenance attestation (`gh attestation verify --repo gitayg/haive-agent`) that ties each binary to the commit and the public CI workflow that built it. - **Not yet: OS code signing.** The binaries are not signed with Apple Developer ID or Microsoft Authenticode certificates. macOS builds are ad hoc signed and not notarized, and Windows builds are unsigned, so Gatekeeper, SmartScreen or Defender may warn or block until you allow them. ## What stops a dangerous command? The hub's deny-list. In `policy.json` you can deny whole action kinds (`deny_actions`, for example `shutdown` or `exec`) and commands that contain a pattern (`deny_patterns`, for example `rm -rf`). It runs before the device is contacted, on the relay and LAN-direct paths alike, and it is re-read on every check, so an edit applies at once. Two limits: **with no policy file the hub allows every command**, and patterns are plain substring matches, so they catch careless commands better than a determined attacker. Background jobs go through the same check as commands, so they are not a way around it. ## Can someone get admin rights on a device? Through just-in-time elevation. A user asks for admin from the agent's tray menu, with a duration and a reason. The request appears in the owner's dashboard. If the owner approves, the hub adds the user to the local Administrators group and records when to remove them. A background sweep removes the grant when the window ends, even across a hub restart or while the device is offline (the removal waits for its next connection). **This is Windows only today.** ## What is recorded? The hub records each device action with who asked, whether it came from the browser or MCP, the action, the device and the full command text. A command's record is written before the command runs. **Gap:** the dashboard's audit log is held in memory and keeps the last 500 events. It is not yet written to durable storage or exportable to a SIEM. ## What happens if the hub is compromised? The hub controls every device enrolled in it, so an attacker who controls the hub can run commands on those devices. IT-AI limits what else they get: - they cannot push an agent build that is not signed with the pinned key; - one stolen device secret does not open any other device's tunnel; - devices need no inbound port from the internet; the only listener is the optional LAN-direct port on the local network, which refuses calls without a hub-minted capability. Run the hub like any other admin system: behind SSO, with `RELAY_TOKEN` set, a deny-list written, and `/x/*` (the human control surface) kept off the public internet. The agent can also be confined: `SCREEN_SHARE` limits file transfer to one folder, and `SCREEN_EXEC=0` turns remote commands off. ## Where are the threat model and the disclosure policy? - **Disclosure:** report a vulnerability privately through the [contact page](https://glick.run/contact.html). Do not open a public GitHub issue for an unpatched flaw. - **Threat model:** not published yet. This page and the [how it works](https://glick.run/it-ai/how-it-works.html) page describe the trust boundaries. ## Certifications IT-AI has **no SOC 2, ISO 27001 or other certification**, and no third-party penetration test has been published. It is self-hosted, so most controls an auditor asks about (access to the server, backups, network exposure) are yours. The `compliance_posture` check maps device settings to CIS, NIST 800-53, PCI DSS, HIPAA, ISO 27001 and Essential Eight controls. That mapping helps you collect evidence. It is not a certification. ## Not yet done - Apple Developer ID notarization and Windows Authenticode signing of the agent. - A durable, exportable audit log. - A published threat model and third-party security review. - Just-in-time admin on macOS and Linux. - A default deny-list: a new hub allows every command until you write a policy.