Acidni AI Gateway — Help

Getting yourself and your clients running. Back to the control panel

Start here

Which guide is yours, and the five things that must all be true before anything works.

Acidni staff running the platform: read 'For platform administrators'. An MSP setting up for itself and its customers: read 'Set up your own MSP', then 'Onboard a client'. A client organisation of an MSP: read 'For client organisations'.

Everything can be done two ways: in this web console, or from your AI assistant. Connect the assistant to https://mspai.acidni.net/v1/mcp, sign in as an administrator and say 'check my setup status'. It shows a checklist and does the next step with you.

Five things are checked, in this order, on every request. One: the organisation is onboarded, meaning its Microsoft Entra directory id or Google Workspace domain is on an MSP or client record. Two: the licence agreement is accepted for it at /license. Three: the person holds a role, and that role is allowed the connector — access is deny by default, and administrator roles are not allowed connectors automatically. Four: the organisation is licensed for the connector. Five: something can answer — a credential saved on the hub for a cloud system, or an online site gateway for a system inside a network.

When something does not work, one of those five is false. 'Set up a connection' in the console, or 'check my setup status' in the assistant, tells you which.

For platform administrators

Acidni staff only. Take an empty platform to an MSP that is onboarded, licensed and able to carry on alone.

  1. Sign in as a platform administrator

    • Open /platform and sign in with Microsoft using an account listed as a platform administrator.

    You’ll know it worked: The bottom left of the sidebar shows your name with Platform.Admin.

    Watch out: 'No administrator role' means the sign-in worked but your email is not on the platform administrator list. That list is the PLATFORM_ADMIN_EMAILS variable on the production deployment. A refused sign-in is recorded under System errors with who tried and why.

  2. Create the MSP

    The MSP record ties a Microsoft or Google directory to a tenant. Nobody from that directory can sign in until it exists.

    • Organizations → Add MSP. Enter the name, a short tenant id, and the MSP's Entra directory id or Google Workspace domain.
    • For Acidni's own organisation the tenant id must be 'savitas', the name the hub gives its home directory.
    • Set a contact email.

    You’ll know it worked: The MSP appears in the Organizations table.

    Watch out: The directory id is a GUID from the Entra admin centre (Overview → Tenant ID), not a domain name.

  3. Grant the MSP its first administrator

    • Users & roles → Grant roles. Give the person's email MSP.Admin, and reader if they will also use connectors.
    • Microsoft users can be given roles by security group on Directory access instead. Google users always need a grant by email.

    You’ll know it worked: They can sign in to /platform and see their own organisation.

  4. License the MSP

    • Organizations → open the MSP → Licence. Choose a package, or tick connectors one by one with a level each, and press Issue licence.
    • From your assistant instead: admin.license_tenant with a tier or an explicit list of connectors.
    • Or send the MSP to /pricing: a card payment issues the entitlement automatically.

    You’ll know it worked: Organizations shows an entitlement for the tenant, and Permissions gains a column per licensed connector.

    Watch out: A connector nobody is licensed for has no column on Permissions. An empty Permissions page on a new platform means no licences yet.

  5. Allow roles to use connectors

    • Permissions: tick the connectors each role may use.
    • For connectors that can change things, choose whether a role's changes need approval (the default) or run automatically.

    Watch out: Administrator roles are not allowed connectors automatically. Tick them, or grant the person reader as well.

  6. Have the licence accepted, then hand over

    • The MSP's administrator accepts the agreement at /license.
    • Give them the console address, the connector address https://mspai.acidni.net/v1/mcp, and this guide.

    You’ll know it worked: Their assistant answers 'check my setup status' with a checklist of what is left for them to do.

Set up your own MSP

Do this once. It gets you signed in, licensed, connected to your PSA and RMM, and using it from your AI assistant before any client sees the product.

  1. Sign in and accept the licence

    Everything below happens at mspai.acidni.net/platform, and nothing answers until the agreement is accepted.

    • Go to /platform and sign in with your Microsoft or Google work account.
    • Open /license, read the agreement and accept it.
    • You need the MSP.Admin role (Gateway.Admin is the older name and still works); Acidni grants it when it onboards you.

    You’ll know it worked: The sidebar loads and your name appears at the bottom left.

    Watch out: If you are told you hold no administrator role, your sign-in worked but you hold no role. Ask Acidni to grant you one under Users & roles, or to map your Microsoft security group on Directory access. 'This directory is not registered' means the directory id Acidni holds for you is wrong: send them your Tenant ID.

  2. Check your organisation record

    Your directory id is the only link between your Microsoft or Google tenant and this platform. If it is wrong, nobody from your directory can sign in.

    • Open Organizations and click your MSP.
    • Confirm the Entra directory (tenant) id or Google Workspace domain matches yours.
    • Set a contact email — clients see it as the reply-to on their setup email.

    You’ll know it worked: The record saves and your colleagues can sign in.

    Watch out: The directory id is a GUID, not your domain name. Find it in the Entra admin centre under Overview → Tenant ID.

  3. Connect your cloud systems

    ConnectWise, Autotask, Halo, NinjaOne, ClickUp, IT Glue and ScalePad are reached by the hub itself. Nothing has to be installed.

    • Open PSA & RMM access and choose the system. The page lists the fields it needs.
    • Create a dedicated integration account on the vendor's side with the least access the work needs.
    • Enter the values and save. From an assistant, ask for the secure link instead and type the keys on that form.
    • Thread has no service account: each technician connects their own at /connect/thread. NinjaOne offers the same at /connect/ninja. QuickBooks Online is connected once per organisation by an administrator at /connect/quickbooks-online.

    You’ll know it worked: The system shows as configured and lists which secret fields are set.

    Watch out: Never paste a key into a chat; if you have, rotate it. Each secret is stored as its own secret in the platform's Key Vault (the page shows the names) and is never displayed again here. Acidni can read one back from the vault if you lose it.

  4. Install your own gateway, if you have systems inside your network

    File shares, QuickBooks, FileMaker and a NAS are not cloud services. A small gateway on your network reaches them. Run one for yourself before selling it — it is also how you demo.

    • Go to Gateways and click Download MSP gateway installer.
    • Copy the archive to a Windows server, or any machine running Docker, at your office.
    • Run install.ps1 (Windows) or ./install.sh (Linux) and accept the licence.

    You’ll know it worked: Within a minute the gateway appears in the Gateways list as online.

    Watch out: The download contains a live enrollment token that expires in 24 hours. The gateway makes only OUTBOUND connections — no firewall rule, port forward or public address is needed.

  5. Turn on the gateway's connectors

    • Open your gateway → Connectors, tick the systems it should reach, and Save.
    • Then open the Configuration tab and fill in each connector's settings.

    You’ll know it worked: The connector count rises and the Connectors page lists it under 'Running on'.

    Watch out: Passwords and keys for systems behind a gateway are not stored here — they go in the gateway's .env on site. The panel deliberately shows those fields as 'set in .env' rather than an input.

  6. Decide who may use what

    • Users & roles: grant your staff a role by email, usually reader.
    • Permissions: tick the connectors each role may use, and for connectors that can change things choose 'need approval' or 'run automatically'.

    You’ll know it worked: A colleague signs in and sees only the tools their role allows.

    Watch out: Access is deny by default, and administrator roles are not allowed connectors automatically.

  7. Connect your AI assistant

    • In Claude, ChatGPT or another assistant, add a connector pointing at https://mspai.acidni.net/v1/mcp.
    • Sign in with the same work account. /connect has the exact clicks for each assistant.

    You’ll know it worked: The assistant lists tools named after your systems, such as connectwise.list_tickets.

    Watch out: Seeing only two generic tools means the rest were filtered out. Check, in order: is the licence accepted, does your role allow the connector, is your organisation licensed for it, and is there a saved credential or an online gateway to answer?

Onboard a client

Repeat per customer. About ten minutes, most of it spent waiting for their server to pull the image.

  1. Create the client record

    • Organizations → Add a client. Enter their name and a contact email.
    • Add their Entra directory id or Google Workspace domain if their own staff will sign in.
    • Leave 'Email setup instructions' ticked to send them a plain-English welcome.

    You’ll know it worked: The client appears in the Clients table and the confirmation says the email was sent.

    Watch out: If it reports 'Email NOT sent', mail is not configured — the client was still created. Send the instructions later from the client's own page.

  2. Decide what the client's own staff may see

    A client's staff use a separate connector and see only what you expose. This is not the same as what your technicians can do for that client.

    • For each of tickets, assets, invoices, SLAs and quotes choose off, view or actions. Everything starts off.
    • Choose whether their requests (open a ticket, request a quote, request a meeting) wait for your approval or go straight through.
    • From an assistant this is admin.set_client_exposure.

    You’ll know it worked: A client user connected to the client gateway can read the areas you switched on and nothing else.

    Watch out: A client user can never use your ConnectWise, Autotask or other PSA connection directly, whatever roles they hold. Those connections see every one of your customers, so the gateway refuses. What they do see comes through the client gateway, for their own company only.

  3. Link the client to their company in your PSA

    This is what makes the client gateway show real records. Without a link a client sees nothing.

    • Organizations → open the client → PSA company link. Type that customer's company id in your ConnectWise, Autotask or Halo and press Save link.
    • The card says whether look-ups are live, from which system, and for which areas. From an assistant: admin.set_client_psa_links, then admin.client_feed_status.
    • A saved credential for that PSA is also needed, on PSA & RMM access.
    • Tickets, assets and agreements are served as summaries. Invoices and quotes are not available through the client gateway yet.

    You’ll know it worked: The card shows 'live from' your PSA, and the client sees their own tickets without your internal notes.

    Watch out: A wrong company id shows one customer another customer's records. The gateway asks the PSA for that company only and drops anything that comes back for a different one, and refuses a company already linked to another client, but it cannot know the id you typed belongs to the wrong customer. Check each link.

  4. Send them the installer, if they have systems to reach

    The bundle carries a live credential, so hand it over the way you would a password.

    • Open the client and click Download installer.
    • Send the archive over a channel you already trust with credentials.
    • Have their technician run install.ps1 on the server that can see their data.

    You’ll know it worked: The client's gateway shows online in Gateways.

    Watch out: Do not email the archive to a public address. Each download mints a NEW token, so an old bundle cannot be replayed — regenerate rather than resend if in doubt. Asked for through an assistant, the token is withheld from the chat and shown once on a link you sign in to.

  5. Choose what their AI can reach

    • Open their gateway → Connectors and tick only the systems they agreed to.
    • On the Configuration tab set the share path, company id, host names and so on.
    • On site, put any passwords or API keys into the gateway's .env file.

    You’ll know it worked: Ask the AI client a question that needs that system and confirm real data comes back.

  6. Tell the client how to connect

    • Give their staff the client connector address: https://mspai.acidni.net/v1/bridge/mcp. The same address is safe for every client.
    • If they have their own IT person, grant Client.Admin (or Client.Audit for read-only) under Users & roles.

    You’ll know it worked: One of their staff signs in from their own directory and sees only their own organisation.

    Watch out: A client's roles always come from you. Their own directory cannot grant them anything.

For client organisations

You are a customer of an MSP that uses this gateway. How your staff connect, what they can ask, and how to run a gateway at your site if you are asked to.

  1. Connect your AI assistant

    • In your assistant, add a custom connector with the address https://mspai.acidni.net/v1/bridge/mcp.
    • Sign in with your own work account (Microsoft 365 or Google Workspace) and approve.

    You’ll know it worked: The assistant offers one tool to look things up and one to raise a request.

    Watch out: 'This directory is not registered' means your MSP has not added your organisation yet, or you signed in with a personal account. Ask your MSP.

  2. Ask about your own account

    • Tickets, assets, invoices, service levels and quotes: ask in plain words, for example 'what tickets do we have open?'.
    • You see only your own organisation, and only the areas your MSP has switched on.

    Watch out: An area that answers 'not available' is a setting on your MSP's side, not a fault. Tickets, assets and agreements come from your MSP's own ticketing system once they have linked your organisation to your company record there; if everything answers empty, that link is missing. Invoices and quotes are not available yet.

  3. Raise a request

    • Open a ticket, request a quote or request a meeting by asking the assistant.
    • If your MSP reviews requests first, the assistant says it is waiting. Nothing is sent until they release it.
    • Once released it becomes a ticket for your company in your MSP's ticketing system, and the assistant gives you its reference.
  4. Run a gateway at your site, if your MSP asks

    Only needed when the assistant should reach something inside your network, such as a file share or QuickBooks.

    • Copy the installer your MSP sent to a machine that stays on, runs Docker and can see those systems.
    • Run install.ps1 (Windows) or ./install.sh (Linux) and accept the licence.
    • If asked for a password for one of your systems, put it in the .env file in the installer's folder on that machine. Do not email it.

    You’ll know it worked: Your MSP confirms the gateway shows online, usually within a minute.

    Watch out: The installer's token expires 24 hours after your MSP downloaded it; ask for a fresh one rather than reusing an old file. The gateway only connects outward, so no firewall rule is needed, and your passwords never leave your site.

If your MSP has made you a client administrator you can also sign in to /platform to see your own gateway, review your organisation's usage in the Audit log, decide approvals that fall to you, and accept the licence agreement. A client auditor sees the same, read-only.

Never type a password or an API key into the assistant. Everything asked is logged with your name — which tool, when, and whether it was allowed — but not the content of questions or answers.

Connect ScalePad

Acidni is a ScalePad integration partner. Read each client's Core and Lifecycle Manager data, and create initiatives with a second person's approval.

  1. Save the API key

    • In ScalePad, create an API key on a dedicated integration administrator.
    • Here, open PSA & RMM access and save it on the ScalePad card, or ask your assistant for the secure link.

    You’ll know it worked: The ScalePad page shows the API key as saved.

    Watch out: A ScalePad key is not scoped: it can read the whole account. That is why nothing is visible here until you map a client.

  2. Test the connection

    • Open ScalePad under Connections and press Test connection.

    You’ll know it worked: It says it reached ScalePad, whether Lifecycle Manager is available, and lists your ScalePad clients with their ids.

  3. Map each client

    A mapping is what lets a role see one client's ScalePad data. Without a row, nothing is granted.

    • In Client map choose the gateway client and the ScalePad client.
    • Name the roles that may see it (reader by default) and press Save mapping.

    You’ll know it worked: The client appears in the map as active, and scalepad.list_clients in your assistant returns it.

    Watch out: Map by id from the test list, not by name. One gateway client maps to one ScalePad client.

  4. Decide about writes

    • Leave writes off to keep ScalePad read only.
    • Press Turn writes on to let an assistant propose an initiative. Each one still waits for a second person to approve it, and lapses after 30 minutes.

    Watch out: An initiative that timed out after it was sent is marked 'outcome_unknown' and is never retried. Use Look it up, check ScalePad, then Record outcome.

Using it day to day

Asking questions, making changes safely, and what 'queued for approval' means.

Ask in plain words. For a customer question the assistant first finds the company, then reads tickets, contacts, configurations, time or agreements. For totals and history it uses the assessment dataset rather than paging the PSA. It can search document titles across IT Glue and file shares. Each result says whose account reached the vendor: your own, or the MSP's shared integration account.

Some tools change things: create a ticket, add a note, log time, update a ticket, reboot a device, create a ScalePad initiative. Ask for a preview first — a dry run shows exactly what would be sent and sends nothing.

A change either runs at once or waits for approval, depending on what your administrator chose for your role under Permissions. If it waits, the result says 'queued' and gives an id. Nothing has reached the vendor yet. An administrator releases or rejects it on Write approvals, and a released change runs as the person who asked, so the vendor's own history names the right technician.

A pre-flight check reads every change before it runs and can hold one for approval even when your role runs changes automatically. A tool marked for human review, such as creating a ScalePad initiative, always waits for a second person and expires if nobody decides within 30 minutes.

Handoffs: ask the assistant to 'check with' someone and that person is notified by email, Teams or Slack and answers on a page; the assistant relays the answer in their words. Who is asked is set under Who decides what.

If a tool fails or returns less than you expect, ask 'is anything broken?'. The assistant reads the gateway's own error log before concluding the data is not there.

Where credentials live

What is stored, where, who can read it back, and what never goes through a chat.

Credentials for cloud systems the hub reaches itself — ConnectWise, Autotask, Halo, NinjaOne, ClickUp, IT Glue, ScalePad — are entered on PSA & RMM access or on a one-time form the assistant links you to. Each secret value is stored as its own secret in the platform's Key Vault, named for your organisation, the system and the field. The page lists those names.

Nothing here, and no AI assistant, ever shows a saved secret again. If you lose one, an Acidni administrator with access to the vault can read it back for you, and the vault records that it was read.

Credentials for systems behind a site gateway — a file share's service account, a QuickBooks or FileMaker login — live in that gateway's .env file at the site that owns them. They are never sent to the hub; the configuration pages refuse a field marked secret.

Nothing secret travels through a conversation in either direction. You type a credential on a form on this site. A value the platform makes for you — an enrollment token, the installer's token line, a webhook signing secret — arrives as a one-time link: open it, sign in as an administrator of that organisation, and the value is shown once.

If an assistant ever asks you to paste a key, refuse and ask it for the secure link. A key that has been pasted into a chat should be treated as disclosed and rotated.

Give the AI safe access to file shares

How to let an agent read company files without letting it change them.

Do not try to constrain the AI on the user's PC. An agent running there inherits that user's permissions, so “please do not delete things” is a prompt, not a control.

Put the access behind the gateway instead, and give the gateway its own identity. Create a dedicated Active Directory service account (for example svc-acidni-ai) that is NOT any employee's account, and give it READ-ONLY NTFS rights to exactly the folders the AI should see.

Mount that share into the gateway read-only. The service account's password lives in the gateway host's mount configuration — never in this panel, and never on the hub.

Four independent layers then stop a write, and any one of them is sufficient: NTFS permissions on the server; the read-only mount; a connector that exposes only search, stat and read, with no write tool to call; and path confinement to the configured share, so '..' cannot escape it.

For the agent's own working files, give each user a separate writable location — a personal AI drive — that is not your production share. The AI then reads company files and writes drafts somewhere harmless.

Who can do what

Four administrator roles, each strictly inside the one above it, and the roles ordinary users hold.

Platform administrator (Platform.Admin, Acidni) — the whole platform: every MSP and every client. Held by Acidni staff only.

MSP administrator (MSP.Admin) — their own MSP and all of its clients: connect systems, onboard clients, install gateways, set permissions, release approvals, review the whole tenant's audit trail. This is the role an MSP's own staff hold. (It was previously called Gateway.Admin; that name still works.)

Client administrator (Client.Admin) — one client site and nothing beside it. For a customer who has their own IT person: they can see their own gateway and review their own usage logs, but cannot create clients, act for the MSP, or see any other customer.

Client auditor (Client.Audit) — the same view as a client administrator, but strictly READ-ONLY. For someone who needs to review usage logs without being able to change anything. The restriction is enforced on every request, not per screen, so it cannot be worked around.

Everyday users hold a user role such as reader, and see only the connectors Permissions allows that role. An administrator role does not by itself allow any connector: tick it on Permissions, or grant the person reader as well.

A client's own staff are client users. They use the client connector, see only what the MSP has exposed for their organisation, and can never use the MSP's own PSA connection.

A client's roles are always assigned by you, never taken from their own directory — an administrator in their tenant cannot grant themselves access to yours. Even a mistaken grant cannot promote a client user beyond their own site.

What the platform does and does not do

The answers clients ask for before they will sign.

Every request is checked: who is asking, whether their role allows the tool, whether their organisation is licensed for the system, and whether a client user is staying inside their own organisation. Anything not allowed is refused.

Reading is the default. The file connectors expose search and read only — there is no write, move or delete for an agent to call. Tools that change things in a PSA or RMM exist, are listed separately, can be previewed without sending anything, and wait for a person's approval unless an administrator has chosen otherwise for that role.

Gateways make only OUTBOUND connections. No inbound firewall rule, port forward or public IP is required at any site.

Every tool call is logged — who asked, which tool, when, and whether it was allowed — and kept for twelve years. The log does not hold the content of requests or results. Users see only their own entries; an MSP admin sees their tenant.

Credentials for systems behind a gateway stay on that gateway, in its .env file. Credentials for cloud systems are held in the platform's Key Vault, one secret per field, and are never shown in the console or to an assistant.

Each gateway gets its own signing key, so a credential taken from one site is useless at another.

One organisation cannot see another's records, credentials or audit trail, and one MSP cannot see another MSP's clients.

When something is wrong

The failures we actually see, and what each one really means.

A gateway shows 'never connected' — it was enrolled but has never checked in, so the installer probably did not finish. Run it again on the server and watch for errors.

A gateway shows 'offline' — it ran before and has stopped. Check the machine is on, Docker is running, and outbound HTTPS to mspai.acidni.net is allowed.

The AI client lists only two generic tools — the connector tools were filtered out. Confirm the licence agreement is accepted, your role is allowed the connector on Permissions, your organisation is licensed for it, and a credential is saved or a gateway is online for it.

'This Microsoft directory is not registered' or 'this Google Workspace domain is not registered' — the directory on the organisation record does not match the one you signed in from. Fix it on that organisation's page.

'No administrator role' — sign-in worked, but you hold none of MSP.Admin, Client.Admin or Client.Audit. Ask an administrator to grant one under Users & roles.

A PSA tool says no key is configured — no credential is saved for that system. Add one on PSA & RMM access.

A change says 'queued' and nothing happens — it is waiting on Write approvals for an administrator to release or reject it.

A client user is refused with 'client scope' — by design. A client cannot use the MSP's own PSA connection; expose what they need through the client gateway instead.

A call is refused with 'secret_refused' — something that looks like a password or key was sent as part of the request. Use the secure link, and rotate the value if it was real.

A connector returns sample data — it has no credentials, so it serves a clearly-labelled reference dataset rather than pretending. Fill in its settings and, on site, its .env.

Common questions

Does the AI need a hole in our firewall?

No. The gateway only makes outbound connections to the hub, and the hub answers through that same connection. Nothing dials in.

Can the AI change or delete our files?

No. The file connector exposes search, metadata and read only — there is no write tool to call. We also recommend mounting the share read-only with a dedicated read-only service account, so the server itself would refuse a write.

Can the AI change things in our PSA or RMM?

Only through tools built for it — create a ticket, add a note, log time, update a ticket, reboot a device — and only for a role an administrator has allowed. Each can be previewed first, and waits for a person's approval unless the administrator chose otherwise.

Where do passwords and API keys live?

For systems behind a site gateway: in that gateway's .env file, at the site that owns them, never on the hub. For cloud systems such as ConnectWise or NinjaOne: in the platform's Key Vault, one secret per field, entered on a form here and never shown again in the console or to an assistant.

I lost an API key I saved here. Can I get it back?

Not from the console or an assistant. An Acidni administrator with access to the platform's Key Vault can read it back for you, and the vault records the read.

Do our clients need Microsoft accounts?

Only if their staff will sign in themselves, and Google Workspace works as well. Add their Entra directory id or Google domain to the client record and their users are confined to their own organisation.

How do we add a connector to a site that is already running?

Tick it on that gateway's Connectors tab. It applies on the next heartbeat, within about a minute. Shipping brand-new connector CODE needs a 'docker compose pull' on the gateway.

What happens if a client's server is switched off?

The gateway shows offline and its tools stop resolving. Nothing is lost; it reconnects by itself when the machine comes back.

Can we see what the AI has been asked?

Yes — the Audit log, filtered to what your role may see. Every call records the user, the tool, the time and the decision, not the content.

Can we do the setup from Claude or ChatGPT instead of this console?

Yes. Connect the assistant to https://mspai.acidni.net/v1/mcp as an administrator and ask it to check your setup status. Every action here is also a tool there; secrets still go through a form on this site, never the chat.

Still stuck?

Open Help & Support in the control panel and send us a request — it reaches us with the page you were on, and you get a reference to quote.