Security at ITAI

Keeping the AI in bounds

• Diagnosis is read-only. Every command the AI asks to run while it diagnoses is parsed on the PC with PowerShell's own parser and checked against a read-only allow-list before it can start. It runs in PowerShell's Constrained Language mode. Anything else is refused.
• Network checks are limited, with a known gap. Ping, DNS and connection tests can only reach private network addresses, your own domain, hosts named on the ticket and a short list of well-known services. Some read commands can still name another machine directly. Closing that gap is part of the independent security test we have planned, so do not rely on this list as your only barrier.
• Processes are contained. Every process a diagnosis starts, including anything a command starts itself, runs inside a Windows job object and is ended when the diagnosis ends. Each command has a time limit.
• Fixes are on by default, and can be switched off. Fixes are on for a new organization, and every fix still waits for a named person's approval (below). One of its admins, or ITAI staff with a written reason, can switch it to diagnostics only, and back. Every change to that switch is recorded with who made it and when.
• A person approves every fix. ITAI proposes each step as an exact command with a risk rating and a rollback. In the dashboard a technician has to open a step before they can select it, and their name goes on the ticket. People who can approve are your organization's technicians and admins. ITAI support staff in a support session can diagnose and advise, but never approve a fix.
• Approvals are signed and short-lived. An approval is signed with a key unique to your organization, covers the approved commands byte for byte and only the device they were approved for, and expires five minutes after approval. Each PC holds only the public key, so it can check an approval but never create one. The dashboard issues an approval once and accepts its result once. The PC does not yet keep its own record of approvals it has used, so an approval captured before it was used could be replayed on that PC until it expires; that record is planned. A step that continues after a restart you approved may resume within about a day.
• A second check reads each step. A separate AI check, with none of the diagnosis in front of it, compares each step's command with its description. It runs on a top-tier model that ITAI chooses, whichever model your diagnoses use. A step it could not check needs an explicit acknowledgement before it can be approved.
• Your PCs never talk to the AI. The dashboard makes every AI call. Each PC has its own credential, so one machine can be locked out without touching the rest.
• Privilege levels. A ticket investigates as the current user, a local admin or SYSTEM, and SYSTEM needs a confirmation every time. Investigation is read-only at every level. Today the local admin level runs with the rights of ITAI on the PC, which are the same as SYSTEM's; a stricter setting for it is built and being tested.

Your data

• Separation: logical. All customers share one database and every record belongs to one organization. Every request is checked against the caller's organization, and an automated test tries to reach one customer's data from another customer's account on every route that can reach customer data. It is not physically separate infrastructure.
• Encryption: in transit over TLS between browsers, PCs and the service. Secrets the application holds (the AI key, two-step sign-in secrets and each organization's approval signing key) are encrypted by the application, and secrets on your PCs are protected with Windows DPAPI. Organization keys are stored only as one-way fingerprints, never the keys themselves. The database and its backups rely on our hosting provider's disk encryption. The database is set to refuse connections from outside our hosting provider's private network.
• Secrets in command output: before the AI reads a command's output, and before a transcript stores it, common kinds of secrets in it (passwords, keys, tokens, recovery keys) are replaced with "[redacted]". They are recognized by their label or their shape, so a secret with neither can still get through; the read-only command rules are the first line against that.
• Ticket records: nothing in ITAI can edit a ticket's transcript, including ITAI staff and the AI. A transcript is removed only when its retention period ends or when your account owner asks for your data to be deleted. Each ticket also has a hash-chained audit record, so a change made outside ITAI shows when the chain is checked, and your admins can download their copy. Someone with direct access to the database could still change rows; a write-once copy kept off-site, planned but not yet running, is there to expose that.
• Retention: tickets and transcripts are deleted 90 days after their last activity, unless they are under a legal hold. The slim audit record (who did what and when, commands run, fingerprints of their output) is kept for 7 years. Billing records are kept as tax law requires.
• AI training: ITAI does not train AI models on your data. We are confirming the training and log-retention wording in our AI model provider's commercial terms before relying on it in a contract.
• What we collect: see the Privacy Policy.

Integrations with your tools

• Only your own admins set them up. Integrations are in Company settings, for your organization's own admins and superadmins. ITAI staff cannot set them up, and a support session never reaches them. Making or replacing the alert URL or a secret needs a sign-in within the last 10 minutes.
• The alert URL is a secret, kept as a fingerprint. The alert URL is shown once and stored only as a one-way fingerprint. An alert opens a ticket only on a PC in the organization the URL belongs to, and never adds a PC. Starting a diagnosis straight from an alert is off until an admin turns it on, and then goes through the same spend and payment checks as any diagnosis. Email alerts are on the roadmap.
• Results go out signed, to public addresses only. An outbound webhook must use https and a public address, checked after the name is looked up, and ITAI connects only to the address it checked. Redirects are not followed. Each message is signed with a secret shown to you once. A message about a ticket carries its priority, due time and the assigned person's name, never an email address. The webhook address, its secret and a HaloPSA client secret are encrypted by the application.
• HaloPSA is a first version. It is tested against a recorded copy of HaloPSA's API, not yet against a live HaloPSA.
• Your export includes them. An organization's data export includes its integration settings (never their secrets), the alerts it received and its webhook delivery log.

Signing in and access

• Two-step sign-in with an authenticator app is required for ITAI staff and for your superadmins, admins and technicians. Your admins can require it for other users too.
• Passwords are at least 12 characters and stored as bcrypt hashes. Sign-in attempts and two-step codes are rate limited, and the counts are kept in the database, so a restart does not reset them.
• Sessions last 12 hours. Signing out ends the session on our server, not only in your browser. "Keep me signed in" lasts at most 30 days on one browser and can be revoked from the Signed-in devices list. Your superadmins can forbid it for your company, or allow fewer days, in Company settings; forbidding it signs out every browser it kept. ITAI staff accounts can never be kept signed in, and a staff session ends 8 hours after sign-in, or after 2 hours without activity.
• ITAI staff access to your organization is through a support session opened with a written reason, lasting at most 8 hours. In a session staff act with an admin's access to your devices and tickets (for example running a diagnosis, retiring a PC or editing the network map), but only your own people approve a fix. Removing ITAI from one of your PCs inside a session needs the staff member to have signed in within the last 10 minutes, and shows in your staff access log. Your superadmins see the reason and can end the session, and every staff request that reaches your organization is logged where your admins can read it. Direct database access, limited to emergencies, bypasses that log.
• Legal holds: if the law requires us to keep some of your data, we place a legal hold on it. A hold is not shown in your staff access log unless ITAI staff choose to show it, because a hold can come with a duty not to tell the customer.
• Fresh sign-in for ITAI staff: ITAI's own staff-only actions that delete data, move money, change prices, credentials or sign-in security, or change who can reach your organization (other than steps that only take access away) need the staff member to have signed in with their password and two-step code within the last 10 minutes. So does opening a support session, and removing ITAI from a PC inside one. Other actions inside a support session do not ask again.

Where we are on assurance

• SOC 2: not yet. Our policies are written and mapped to the SOC 2 criteria, and ITAI has not been audited.
• Independent penetration test: not yet. It is planned before ITAI runs on customer machines.
• Cyber and professional liability insurance: being arranged. We will not run on customer machines before it is in place.
• Uptime: we do not offer a service level agreement yet.

Reporting a vulnerability

Write to security@itaibot.io. We aim to acknowledge a report within 2 business days.