Security

Security you control

Autonomous IT support only works if you trust the guardrails. SuperIT is supervised by default, fails safe to approval, and logs every proposal and execution. You define what runs without a human.

See controlsRead FAQ
SuperIT acting confidently and safely over the environment's data

Security controls

Supervised by default

Pilots start conservative: read-only diagnostics, internal notes, engineer-driven. Autonomy expands only as you switch it on, at the pace you are comfortable with.

Inherits the user's permissions

The agent acts as the signed-in user it is helping. It can never do something that person couldn't do themselves. Targeting admin accounts is rejected outright.

Allowlist & blocklist controls

You define exactly what the agent is allowed to do. Everything else is off-limits by default. Anything unrecognised fails safe to "needs approval", never to "run it".

Approval workflows

Sensitive actions require explicit sign-off. Nothing high-risk happens without a human saying yes.

Isolated tenants

Every customer runs in an isolated tenant with per-device credentials. One client's data can never bleed into another client's responses.

Full auditability & alerts

Who did what, when and why: every proposal, policy check, approval and execution is logged. Get alerted when sensitive configuration, like global admin, changes.

Encrypted, end to end

Our RMM agent meets industry-leading security standards. All data between device and backend is encrypted in transit and at rest.

Your data stays portable

Export your data in a usable format at any time. No lock-in, ever.

Data handling

No shared model training

Customer data is used to deliver the service, not to train public models.

Isolated tenants

Each client runs in an isolated tenant with per-device credentials.

Encrypted and portable

Data is encrypted in transit and at rest. Export your data anytime.

Data residency

Deployment options for data-residency requirements are scoped on enterprise plans.

Common questions

How can you safely let an AI run commands on our machines?

Security is the one thing we never compromise on, and it is built in layers, like an onion. There is a hard, system-level filter of dangerous commands that nobody (not an engineer, not the agent) can override; static analysis of every command before it runs; an allowlist and blocklist you control (we ship read-only and non-mutating by default); and, most importantly, the agent inherits the permissions of the person it is talking to, so it can never do something that user could not do themselves. Anything beyond that requires explicit human approval.

Can we lock specific things away from the agent, even from ourselves?

Yes. Beyond the allowlist you control, certain system-level commands are hard-blocked and cannot be enabled, even if a human explicitly asks. Credentials and sensitive configuration (like passwords in your documentation tool, or Microsoft 365 global-admin) are kept out of the agent's reach, and higher-risk actions route through approvals with alerting.

Can the agent be tricked or manipulated into doing something it shouldn't?

We assume it can be tried, whether through a crafted ticket, a malicious email, or a clever end user, and we design so that manipulation cannot escalate. It does not matter why the model proposes a command, because every command passes the same checks regardless. The syntactic layer parses what a command actually does (catching injection tricks, encoded payloads and dynamically-assembled commands). The policy layer resolves it against your allowlists with "needs approval" as the fail-safe default. Execution runs with the permissions of the user being helped, so even a fully "jailbroken" agent could not do anything that user could not already do themselves. Locked credentials stay out of reach, and the audit trail records every proposal, including the blocked ones.

How is our data handled?

SuperIT runs on Google Cloud's Vertex AI in an isolated tenant, with data encrypted in transit and at rest. We are a model-agnostic harness over the leading frontier models (Anthropic, Google and OpenAI), and we can change which models we use as their performance changes.

We're an MSP. How do you keep each client's data separated?

Strict multi-tenancy is built into the architecture from day one. Every customer environment is an isolated tenant; every device connects with its own scoped credentials; and the agent only ever reasons over the client context the conversation belongs to, so one client's data can never bleed into another client's responses. Every action (who or what did it, when, against which endpoint, under which policy) is in the audit trail, so you can answer "who touched this machine" with evidence, not trust.

Where is our data hosted? Can you meet data-residency requirements?

We host in Australia and the United States, and because we run on Vertex AI we can pin inference to a specific region where you need it. If you have strict residency requirements (for example regulated, government or law-enforcement clients), tell us and we will configure the right endpoints. For us that is a configuration change, not a major engineering lift.

Do you have security certifications?

We are working toward ISO 27001 and SOC 2 compliance. Our controls and documentation are in place and we are progressing to formal audit. In the meantime we are happy to share our security and trust documentation and walk your team through the architecture, and we run a bug-bounty program because we would rather you try to break it.

Ask us the hard questions

Security is how the product is built. Book a demo and walk through allowlists, approvals and audit with your CTO.

Book a demoView pricing