Skip to content
NewApp Watch: know when an app is running again
Sockit

Where your data goes, and who can change what

Sockit installs on a server you run, so your directory, telemetry and AI conversations stay on infrastructure you control. Every change to a machine goes through a separate write agent, under role-based access.

  • Self-hosted

    One Docker bundle on your own server.

  • Read and write split

    Telemetry and change run as separate agents.

  • Role-based access

    Actions are checked on the server against the caller's role.

  • Your AI key

    No model is called until you add one.

Runs on your own server

The whole platform installs from one Docker bundle onto a server you run, so the data stays where you put it.

Installed by one script
It sets up Postgres, Redis, the API server and the web console together.
You decide where it runs
Agents report to your server's address. Where it lives, who can reach it and how it is backed up stay your decisions.

Separate agents for reading and changing

Each endpoint runs a read agent and, where you want actions, a write agent. The two run with different permissions.

The read agent changes nothing
It reports event logs, installed software, processes, network flows and the logs of watched applications.
The write agent acts on request
Uninstalling software, installing Windows updates, restarting services and managing local accounts go through it, and only under role-based access.
Auto-Recovery has limits
It acts only where a policy exists: 3 tries in 10 minutes, then a cooldown, then a Case for a person. A policy that hits 10 machines in 15 minutes pauses itself, and any environment can turn it off.
Scripts are pinned
A recovery script runs only if it matches its SHA-256 hash and passes a deny-list. Patching and uninstall support dry runs.
Native packages
Windows: MSI, deployable by Group Policy, running as a Windows service. Linux: .deb and .rpm for x64 and ARM64 under systemd. macOS: .pkg under launchd.

Access follows your directory

People and their reporting lines come from Active Directory or Entra ID, so what someone can see is decided by structures you already maintain.

Roles and capabilities
Pages and actions are gated by capabilities granted through roles, and checked on the server rather than just hidden in the console.
Manager scope
The Manager role sees its own reporting subtree, resolved from the directory, and nothing outside it.
Approvals
Access requests for new joiners go to an approver, who approves or denies them before anything is granted.
Tamper-evident audit log
Admin actions go into an append-only log that can't be edited or deleted. Each entry carries a SHA-256 hash of the one before, and the console checks the chain, so any change shows. Sign-ins have their own audit, and a workspace policy can make multi-factor authentication mandatory.

How the AI uses your data

The AI runs on a provider key you supply, for Claude, Gemini or DeepSeek. Until you add one, nothing is sent to any model and the rest of the platform works as normal.

Same access as the person asking
The assistant answers with the asker's own access. A manager's question is answered from that manager's subtree.
Confirm before it acts
The assistant carries out admin tasks only after you say yes, within your permissions. Deleting something means typing its name.
Every tool call recorded
The AI tool audit lists each call the assistant made, including the ones access rules blocked before they ran.
Evidence kept with the verdict
AI verdicts on Cases carry their confidence, numbered reasoning and the log lines they were based on, for review.

What the agents collect

The collection list is short and specific, so a review can check it line by line.

Machine
Event logs, installed software, running processes and network flows.
Applications
Log files of watched apps, and app crashes: from the event log on Windows, the systemd journal on Linux and crash reports on macOS.
Network
Firewall drops, recorded by process, destination and port.
Patching
Installed and pending updates on Windows, macOS and Linux, rescanned every six hours.

Questions security teams ask

Where does our data live?

On the server Sockit runs on. When you self-host, that is your own machine: the bundle includes its own Postgres and Redis, so directory data, telemetry, Cases and audit logs are stored there.

Can the read agent change anything on a machine?

No. It only reports. Changes go through the separate write agent, and only for people whose role allows them.

What does the AI see, and where does it go?

Only what the asking user is allowed to see. Prompts go to the provider whose key you configured, and to nobody until you configure one.

Can we run Sockit without AI?

Yes. Inventory, the org graph, detectors, Cases, routing and remote actions all work without a model. Classification, triage and the assistant wait until you add a key.

Which directories are supported?

Active Directory over LDAP or LDAPS, and Entra ID through Microsoft Graph.

How do we roll the agents out to all our machines?

On Windows, by Group Policy using the MSI. Linux machines take a .deb or .rpm package and macOS a .pkg, or one enrolment command copied from your workspace.

See it for yourself

Look around the demo console, then talk to us about the architecture, the agents and where data goes.