Security architecture and controls

This page describes controls built into the products today. Where something is planned rather than shipped, it says so.

Tenant isolation

Every tenant’s data is stored with its tenant id and protected by PostgreSQL row-level security in force mode. The application connects as a role that is not a superuser and cannot bypass row-level security, so a missing filter in application code still cannot return another tenant’s rows.
The tenant for a request is taken only from the authenticated session, never from the request body or URL.
Managed service providers acting in a customer tenant get a session that is re-validated on every request and recorded in the customer’s own audit log.
Shared caches and usage counters are keyed by tenant.

Cloud and integration credentials are encrypted at rest with keys bound to the tenant.
Assessment uses read-only roles. Remediation requires a second, separately granted identity, so removing it removes all write access.
ITOps360 site collectors hold their own key pair; device credentials are sealed to that collector, so the server, its database and its backups cannot recover a device password.
Jobs sent to collectors and agents are signed with a per-tenant key and rejected if unsigned, altered, expired, misaddressed or replayed.
Webhooks are signed with HMAC-SHA256, and outbound calls are checked against server-side request forgery rules (no metadata, loopback or private addresses).

Single sign-on with OpenID Connect and SAML 2.0; Active Directory sign-in over LDAPS with the domain’s CA pinned, checked by the on-site collector so domain controllers are never exposed to the internet.
TOTP multi-factor authentication, required at first sign-in for password and domain accounts (with single sign-on, your identity provider enforces MFA), and step-up required for privileged actions and high-risk approvals.
Role-based access with least-privilege defaults. API tokens carry an explicit subset of their owner’s permissions and can never approve changes.
Passwords are hashed with PBKDF2-SHA256 (210,000 iterations); sign-in is rate limited with lockout.
Session cookies are HttpOnly, Secure and SameSite, with CSRF protection on every state-changing request.

One policy engine decides every change, whether a person, an automation or an AI requested it.
Requesters never approve their own changes; critical changes need two approvers.
Changes are dry-run where possible and verified afterwards. A change that can’t be verified stays open.
Irreversible actions get extra protection. Wiping a computer needs two approvers with multi-factor authentication, and the console asks for the device name to confirm. A wipe through the ITOps360 agent can be canceled until the computer picks it up, and a wiped computer that comes back online raises a security ticket.
Changes to your directory use the separate write identity you grant. For example, ITOps360 adds a person to a Microsoft 365 or Entra security group only after one of the group’s owners approves (unless you let IT approve requests for groups without an owner), and the approver must be proven to be that owner by their directory identity, not just a matching e-mail address.

ITOps360 records every administrative action in an append-only audit trail. Each entry is hash-chained to the one before it, and the database rejects updates and deletes. Administrators can verify the chain at any time.
AI requests are audited with the feature, provider, model, prompt version, a hash of what was sent, token counts and cost.
CloudVision360 keeps a hash-chained audit trail per tenant too. When old records are removed under your retention settings, a checkpoint is left so the rest of the chain can still be verified.

The agent and collectors only run actions from a fixed, allow-listed set. There is no remote shell and no way to send them arbitrary commands.
Collectors use read-only credentials for inventory (WinRM, SSH, SNMP, LDAP). Anything an account isn’t allowed to read is reported as unknown, never guessed. Network changes, such as disabling a switch port, need a separate read-write credential and another person’s approval, and are refused on ports that connect to other network equipment.
Each agent has its own key. Pooled virtual desktops enroll with a pool token that only matches the pool’s computer names and can’t take over a computer outside the pool; an agent copied with a disk image to another computer detects it and stops reporting as the original.
A site collector that stops checking in raises a critical alert after about 10 minutes without contact, so a silent site doesn’t look healthy.
Website and certificate checks run from our cloud only against public addresses; internal addresses are checked from your own site collector.

All model calls go through the CloudVision AI gateway: tenant policy, secret redaction, data-classification routing, tool allow-lists, quotas and audit.
In our hosted service, customer data is never sent to an external AI provider. AI features use only self-hosted models; until one is available they are off and the products give their standard answers.
AI answers are computed from the tenant’s own data first and cite their sources. AI can recommend only actions the policy engine allows, and can never approve.
AI can be turned off per tenant. Private deployments run in your environment and use only the providers you configure.

Backends use only the .NET runtime libraries, with no third-party packages, to reduce supply-chain risk.
Every build runs unit and integration tests, static analysis (CodeQL), dependency and secret scanning, infrastructure-as-code checks, and a container image scan. Images ship with a software bill of materials.
Application containers run as non-root with read-only file systems and dropped capabilities.
Code reaches the main branch only through a pull request with passing checks; the repository enforces this.
Strict Content Security Policy and security headers on the website and applications.

Encrypted backups with a documented restore procedure and a scripted restore test.
Separate development, test, staging and production environments. The public demo environment uses synthetic data only and is isolated from customer environments.
Metrics and traces exported through OpenTelemetry, and health checks on every service.

Independent penetration test before general availability, with a summary available under NDA.
SOC 2 Type II and ISO/IEC 27001 programs (see Compliance on the Trust Center home page).
Code signing (Authenticode) of the Windows agent, collector and setup scripts. The release pipeline is ready and turns signing on once our certificate is issued, before general availability.
SCIM provisioning and WebAuthn passkeys.