Connecting an AI client without losing control

Start from what could go wrong

Giving software the ability to write to your social accounts invites four worries. It could post something you did not see. It could do more than the person who connected it is allowed to do. A leaked secret could let a stranger act as you. And a loop or a bug could hammer the service.

Each of the controls below answers one of those worries. None of them is a warning addressed to the model, because a model can ignore a warning. They are rules in the system the model has to pass through.

Two ways to connect

Some clients, such as Claude Desktop, claude.ai and ChatGPT, can be added with a URL. You sign in to NioConnect when the client asks and press Allow on a consent screen. Others, such as Claude Code and Cursor, take a key in a config file, which you create in Settings under Developers.

Both end up in the same place: an identity that belongs to a real member of your workspace. The AI and MCP pages show the exact setup for each client, and the six tools are the full extent of what a connected client can call.

It drafts by default

The tool that creates a post saves a draft unless it is given a time. A draft goes nowhere until a person opens NioConnect and sends it. There is no publish now option, no argument for it and no second tool for it. If a time is supplied, the post is scheduled for that time, and a time that has already passed is refused.

This is structural on purpose. The protocol has no confirmation step and nothing obliges a model to ask first, so the safe behaviour is the only behaviour on offer. What a draft can and cannot do is covered in what an AI draft can and cannot do.

The same pipeline, the same checks

A post created by an assistant is saved by the same code the composer uses. It is validated against each channel's rules, it passes the approval gate, it counts against your allowance, and it passes the same admission check before it is queued. If your workspace requires review, an assistant draft waits for review like anyone else's.

If a post is too long for a channel, the tool answers with a plain sentence naming the platform, the limit and the actual length, and nothing is saved. That lets the assistant correct itself, and it keeps a bad post out of the queue.

Roles, keys and who is acting

A key or a connection acts with the role of the member it belongs to, and that role is looked up on every call. Demote or remove the member and their keys and connections lose that authority on their very next use. No new kind of super user is created for machines.

A key is shown once when you create it, and only a one way hash of it is stored, so nobody can reveal it again, including us. Each key has a name and a last used time, and you can have several, one per tool, each revocable on its own. Creating and revoking keys is recorded in the audit log. A key also does not widen your plan; entitlements are checked exactly as before.

Consent you can read, and revoke

When a client connects with a URL, it registers itself and sends you to a consent screen. That screen uses your existing session, names the workspace being granted, and lists in plain sentences what the connection can see and make. Deny is a normal outcome and simply returns you to the client.

Behind the screen the details are conservative. The one time code is short lived and single use, the exchange is bound to the client and verified with PKCE, access tokens last an hour, and refresh tokens rotate so an old one stops working the moment it is used. A stolen refresh token is useful at most once, and its reuse can be detected.

Afterwards you can see every AI client you authorized and revoke any of them. Revocation takes effect immediately.

Limits on volume

Tool calls spend from a per workspace bucket, so one noisy client cannot use up the service for other workspaces. The tool that lists posts returns a page at a time with a cursor, and a cursor the server did not issue is refused. These are quiet protections, and you should rarely notice them.

What stays with you

Two things are yours to decide and are not automated away. The first is whether the workspace requires review, which you control in the approval settings. The second is whether to give a client a time at all: a client that is only ever asked for drafts never schedules anything. Telling an assistant to leave posts as drafts unless you supply a time is a sensible standing instruction, and the system backs it up by making drafts the default.

Habits that help

Use a separate key for each tool, revoke it when the job is done, and skim the calendar after a session. A draft is quick to read and quick to delete. If your client offers a URL connection, prefer it: nothing is pasted, and nothing sits in a config file. The guide to creating and revoking an API key covers the key path.