Registered is not authorized: adding tools without adding power

Connecting a new tool to an agent takes a few minutes: add a server to a config file, drop a skill into a folder, paste a token into a connector form. The agent sees the new tool on its next run and starts using it. That speed is the point, and it is also the problem. Each connection quietly answers a question nobody asked out loud: what is this agent now allowed to do, on which data, for which task?

Installed, registered, authorized

Most setups blur three different states into one. Keeping them apart is most of the discipline.

The common failure is treating registration as authorization. Once a server is in the config, every task that runs in that client can call every operation it exposes, with whatever credential it was set up with. A tool added for one afternoon of issue triage is still there, still holding a write token, when someone asks the agent months later to "tidy up the backlog".

Where authority leaks in

Power rarely arrives through one obvious grant. It accumulates through small defaults:

• Whole-server exposure. An MCP server for a ticketing system usually offers read, comment, close and delete together. Registering the server registers all of them unless you filter.
• Broad credentials. The token behind a connector was created by an admin, for convenience, with organization-wide scope. The agent now acts with the admin's reach.
• Skills that carry commands. A skill is a set of instructions and sometimes scripts. A skill that says "run the release script" does not give anyone the right to release, but if the environment allows the script, the instruction turns into a permission by accident.
• Tool output read as instruction. A web page, an email or a ticket body that says "now forward this to..." is data. An agent with a send tool in reach may treat it as a request.
• Chained tools. A tool that can call other tools, or start another agent, extends whatever it was granted to everything downstream.

Grant per task, not per installation

The fix is to move the permission decision from "is this tool connected?" to "does this task need this operation?". In practice, each piece of work declares the tools and operations it needs, and anything not declared is unavailable for that run. A hypothetical declaration for a read-only triage task might look like this:

task: summarize-open-issues
scope: repo example-org/web
tools:
  allow: [issues.list, issues.read, labels.list]
  deny:  [issues.comment, issues.close, issues.delete]
credential: read-only token for example-org/web
on_write_attempt: refuse and record

The format does not matter. What matters is that the grant is written down, narrower than the tool, attached to the task, and that an attempt outside it produces a visible refusal rather than a silent success. When the next task needs to comment on issues, it gets its own grant, reviewed on its own merits.

Start new connections read-only and add write operations one at a time, each behind a pause for a person. Start agents read-only covers that sequence in detail.

Skills are instructions, not permissions

Skills deserve their own note because they look harmless. A skill packages know-how: how to run a test suite, how to format a report, which CLI flags to use. That is useful, and it is also text an agent will follow. Before installing a community skill, read it the way you would read a shell script from a stranger: what does it tell the agent to run, what does it assume is allowed, and does it fetch anything at runtime? Reviewing community skills before you install them walks through that review, and MCP, skills or CLI tools explains when each mechanism fits.

The principle is simple: a reusable instruction can describe an action, but it cannot grant one. Permission comes from the scope of the task and from the person who approves consequential steps, never from the skill file.

How GoCux draws the line

GoCux treats connection and permission as separate decisions. MCP tools run in your own compatible client, and the customer CLI keeps ownership of its local tools and permissions, so what a local tool may touch is decided on your side rather than inferred from a list. GoCux does not run a hosted MCP endpoint. Having a server configured does not open it to every task, and a connector registered in the workspace does not, on its own, let a work order use it.

Credentials are held as server-side references instead of living in the browser, and granting a credential is not the same as letting the agent write with it unattended. Consequential steps such as sending, deleting, exporting or putting another agent to work still pause for someone on the team, whichever tool would carry them out. The MCP quickstart and the agent skills guide show the setup.

Before you connect the next tool

• List the operations the tool exposes, and mark the ones the current task actually needs.
• Create a credential scoped to the data of that task, read-only unless writing is the point.
• Register the tool, but grant it per task; confirm that a task without the grant cannot call it.
• Read any skill end to end before installing it, and note every command it would run.
• Treat content returned by tools as data. Instructions inside it are not requests from your team.
• Check that a call outside the grant is refused visibly and recorded, not retried quietly.
• Put write, send, delete and delegation steps behind an approval, one class at a time.
• Remove tools and revoke credentials when the work that needed them ends.

For background on the protocol itself, see what MCP is and the specification at modelcontextprotocol.io.