This page is written for the person who has to approve ADIM for a production environment. It lists what runs where, what crosses your perimeter and why, which controls keep the AI from doing damage, and what we have not validated yet. If something you need is missing here, ask — we would rather answer it in writing than have you guess.
Design principles
- The AI decides; it does not execute. Model output selects a runbook from an allow-list and fills declared parameters. There is no path from model output to a shell.
- Every action is one of three recorded modes: automatic, approved by a named person, or suppressed. There is no fourth.
- Read-only until proven. Every new layer starts as investigate-and-notify. Write actions are added per runbook, scored, and gated.
- Fail closed. No valid license means no AI decisions and no runbooks. Alerts are still forwarded.
- Your data stays on your server. What leaves is listed below, in full.
What runs in your environment
| Component | What it is | Where |
|---|---|---|
| Workflow engine | n8n — runs the decision flow, runbooks, sweeps and reports | Docker container on your ADIM server; UI never published |
| Database | PostgreSQL with pgvector — alerts, incidents, timeline, operational memory, approvals, license state | Docker container, no published port |
| Actions History | Django web service — the incident dossier UI and JSON API | Docker container; HTTPS; published on your LAN only if you choose |
| Runbook access | SSH as a dedicated automation user with a key you provision; vSphere evidence via govc with a service account you create | Your hosts, your privileges |
| Zabbix | Your existing Zabbix 6.0 or newer. ADIM adds one media type, one notifier user with defined rights and one action | Unchanged, yours |
| Grafana dashboards | Six importable dashboards over read-only datasources | Your Grafana, optional |
Installation is a scripted package with steps for prerequisites, containers, database, credentials, workflows, activation and a 19-point verification. Credentials are imported by your operator, not by us. Upgrades are versioned packages with a rollback path.
What leaves your environment
Every outbound connection ADIM makes, and what it carries. Anything not on this list does not happen.
| Connection | Direction | What is sent | What is never sent | Alternative |
|---|---|---|---|---|
| AI model API (default: OpenAI and Anthropic endpoints) | Outbound HTTPS from the workflow engine; proxy supported | Alert title, severity and trigger text; host name and OS family; operating context (recent changes, maintenance state, vSphere or network object context); short evidence excerpts from runbook output; summaries of similar past incidents from operational memory | Credentials, SSH keys, API tokens, configuration files, full log files, personal data of your users | Private LLM (BigsGPT) on your hardware — inference never leaves the site. The model used for each role is configurable. |
| License service (lisans.bigsbilisim.net) | Outbound HTTPS, every 6 hours | Tenant name, package and n8n version, number of monitored hosts, number of incidents in the last 24 hours | Alert content, host names, evidence — no monitoring data | Offline lease for air-gapped sites, on request |
| Chat notifications and approvals (Telegram Bot API) | Outbound HTTPS; inbound only on the published webhook path, restricted to Telegram’s IP ranges | Alert summary, runbook name, approve / acknowledge buttons, result | Evidence bodies, credentials | E-mail only for notifications; other chat channels evaluated per project |
| E-mail (your SMTP relay) | Outbound, your relay | L2 notifications, shift and weekly reports, links into Actions History | — | — |
| GitHub issues | Outbound HTTPS — disabled unless you configure it | Improvement items found by the self-improvement loop (gap description, affected host count) | Evidence, credentials | Keep it off; items stay in the local queue and chat |
| Google Sheets | Outbound HTTPS — used only by the optional OS-update and network modules | The hostnames, maintenance windows and device inventory you maintain in that sheet | Alerts, evidence | Do not enable those modules |
There is no remote command channel. Bigs Bilişim cannot execute anything on your systems through ADIM. Support access, when you want it, is a separate agreement under your control — a VPN or tunnel you open and close.
Proxy and air-gap. All outbound calls honour an HTTPS proxy if you set one. A fully air-gapped installation needs the private LLM option and an offline license lease; both are delivered on request, not by default.
Guardrails — the engineering controls
- Allow-listed runbooks only. Each runbook is a fixed workflow with fixed commands and hard-coded API methods. The model can choose a runbook and fill declared parameters; it cannot compose commands.
- RCI — Runbook Confidence Index. Predictability, reversibility, blast radius, historical success and detection confidence give each runbook one of four levels: Autonomous, AI Recommended, Approval Required, Manual Only. You set the levels; the platform enforces them.
- Repeat gate. The same alert three times in six hours stops automation and hands the incident to a person.
- 15-minute rule. An incident that does not stabilise within 15 minutes leaves auto-remediation.
- Alert-storm gate. Parallel bursts are settled before any decision is made; a fleet-wide “no data” storm becomes one monitoring-side incident, never a wave of host restarts.
- Correlation before action. A VM alert under a failed hypervisor, an interface alert under a device that stopped answering, a datastore alert already open from another host — symptoms and duplicates are acknowledged, not remediated.
- Protected resources. Containers and services you mark as protected — databases, the monitoring stack — never restart automatically.
- Change awareness with bounds. Alerts that follow a logged change (an OS-update run, an unattended upgrade, a change you reported from chat) are closed with the evidence, within a bounded window of 2 to 24 hours depending on the change type. Resource alerts — disk, CPU, memory, container down — are never treated as expected.
- Approval integrity. Approvals come from allow-listed chat users; the approver identity is written with the action; the buttons are removed the moment an approval is accepted, so a double tap cannot re-fire it.
- Network layer: read-only, no exceptions. No port shutdown, no errdisable clear, no config rollback — not even with approval.
- Self-improvement without self-modification. Coverage gaps are diagnosed and filed as review items. Changes to workflows are made by people, versioned, and backed up nightly.
- License gate, fail closed. Without a valid signed lease the decision flow, the sweeps and chat control do not run; raw alerts are still forwarded.
Access and credentials
- Runbooks reach managed hosts over SSH as a dedicated automation user with a key you provision. That user’s privileges — including whatever sudo rules you grant it — are the ceiling of what any runbook can do; the rule set is agreed with you at onboarding.
- Zabbix access is an API token you issue, with read rights on the host groups in scope. Write operations are limited to event acknowledge / close / suppress, maintenance create / update / end, and host enable / disable on an operator’s request. ADIM does not create or delete hosts, templates or triggers.
- vSphere evidence uses a service account you create; least-privilege (read plus the specific power and snapshot operations you allow) is part of onboarding.
- Network devices: SNMP read community and a read-only CLI user; show-commands only.
- The management UI is never published. The alert webhook path is published over HTTPS (your certificate or Let’s Encrypt) with an IP allowlist. Actions History is published only if you choose, over HTTPS with secure cookies, HSTS, CSRF origin checks and rate limits on login and API.
- Secrets live in a tenant environment file on your server with root-only permissions, not inside workflow definitions. The license public key is embedded in the package and never fetched at runtime.
- Actions History users are yours: admin / operator / viewer roles, per-user language, and an explicit permission for AI narratives.
Audit trail and retention
- Every step of every incident is written to an append-only timeline — 16 step types from intake, correlation and decision through evidence, approval, execution, verification, notification and closure — with timestamps, the approver where applicable, and evidence up to 64 KB per step.
- The execution mode (automatic / approved / suppressed) and the approver are stored with each action; dashboards report the two populations separately.
- Actions History keeps 18 months live, then archives by month with a documented restore procedure. Dossiers export as Markdown and JSON.
- Scheduled database backups (Zabbix and ADIM) to a location you define are part of onboarding; workflow definitions are versioned nightly.
Continuity and exit
ADIM runs under an Ed25519-signed license lease of 14 days that your installation renews every six hours. If the site cannot reach the license service, the last valid lease keeps ADIM running until it expires. If the lease is not renewed — because the contract ended or because the site stayed unreachable — the platform enters suspend mode: no AI decisions, no runbooks, no acknowledgements; alerts are recorded and forwarded as raw notifications; the Actions History viewer stays open. Nothing is deleted. Your Zabbix, your data, your runbook definitions and your history stay on your server.
What we have validated — and what we have not
- Server and container remediation, change-aware closing, the alert-storm gate and the approval chain run in production on Bigs Bilişim’s own infrastructure, around the clock, since March 2026.
- The VMware layer is validated end-to-end — correlation, evidence, classification, chat approval, action, verification — against a vCenter simulator. The first customer deployment starts in shadow mode (decide and recommend, no actions) on real vSphere.
- The network layer is validated on a simulated Cisco IOS lab (SNMP and CLI). It is read-only by design, so vendor differences affect evidence quality, not safety.
- OS update automation has been dry-run tested on Linux and Windows hosts; live windows run on Bigs’ own servers first.
- No third-party penetration test or SOC 2 / ISO 27001 certification of ADIM exists yet. Regulated customers can run their own assessment against a pilot installation — we support that.
- Integration today is Zabbix. Other sources that emit webhooks are evaluated per project.
Security FAQ
Can the model be tricked — by an alert text or a log line — into running something?
Model output is a selection from the allow-list plus declared parameters that the runbook validates. There is no free-form execution path, so the worst outcome of a manipulated input is a wrong choice among gated, RCI-scored runbooks — which the repeat gate, the 15-minute rule and post-execution verification exist to catch.
What happens when the AI provider is unreachable?
Nothing executes without a decision, and ADIM never sits in front of Zabbix’s own alerting: the notification actions you already have keep working exactly as before. ADIM is one additional Zabbix action, not a replacement for yours.
Can we review what is sent to the model?
Yes. The prompts and payloads are in the workflow engine on your server, readable by your team; we walk through them together during onboarding.
Who can approve an action?
Only chat users you allow-list. The approver’s identity is stored with the action and shown in the dossier and the dashboards.
Can we run it without Telegram?
Notifications and reports work over e-mail alone. The approval flow is built on the chat channel today; runbooks that need an approval are simply not executed without it.
Does Bigs Bilişim have access to our systems?
Not through ADIM. There is no remote command channel in the product. Support access is a separate agreement, over a connection you control.
Questions this page does not answer: ask us, and we will add the answer here. Back to ADIM.