Tool Governance

Tool Governance decides, for each surface, which tools Qubit and your automations may run, which need approval and which are denied, and it lists standing approvals and recent tool calls.

Written By Chris Scaminaci

Last updated About 2 hours ago

Tool Governance decides what Qubit and your automations may do with tools. For each surface and each tool, a rule says Allow, RequiresApproval or Deny. It covers QuantumOps's built-in tools and every MCP source, not only StackJack. The same card lists everyone's standing approvals and the most recent tool calls.

Only an Administrator can open it. It is a card called Tool Governance on the StackJack Integration page, below the activation and connection cards. From MCP Sources, choose Tool governance to open the page at the card.

The card appears when StackJack is active, or when your organisation has any tenant-wide MCP source. A tenant source and a per-user source both count, and so does a disabled one. A personal source does not.

Surfaces and defaults

A surface is the place a tool call comes from. When no rule matches a tool, the default for its surface applies.

Surface	Where it applies	Default when no rule matches
Chat	Qubit chat	Tools that only read are allowed. Tools that change something need approval.
Copilot	Calls from an outside AI client that reach QuantumOps's own HaloPSA tool server. See Connecting external AI clients over MCP.	The same as Chat.
AgentRunner	Agent Runners, and a Slack or Teams routine that has no creator on record and so runs as QuantumOps itself	Everything is denied. Nothing runs until an Allow rule exists.
Pipeline	Unattended work done as a person: the research pass while tickets are processed, QBR Studio deck generation, and Slack or Teams routines that run as the person who set them up	Tools that only read are allowed. Changes are denied.

The Copilot surface is not the Copilot card on the Ticket Dashboard; it covers only outside AI clients.

On Pipeline nobody is there to approve anything, so a rule with the effect RequiresApproval acts as Deny.

Read tools and changing tools

QuantumOps decides whether a tool only reads or changes something in this order:

The Classification of the rule that matches the tool, when you set one.
What the server says about the tool. A tool marked destructive, or not read-only, counts as a change. By default, a read-only mark from another server does not make a tool count as a read.
The words in the tool's name. Verbs such as list, get, search or describe mean a read. Verbs such as create, update, delete, run or send mean a change.
Otherwise it counts as a change.

How rules are applied

Only rules that are switched on count.
A rule that matches a tool decides, in either direction. You can allow a changing tool for AgentRunner, or deny a read tool in Chat.
When several rules match, the most specific pattern wins. That is the one with the most characters other than wildcards. If two are equally specific, the stricter one wins: Deny, then RequiresApproval, then Allow.
A source whose Destructive tools always need approval box is ticked turns an Allow into an approval request for any tool the server marks as destructive.
A Deny rule beats any standing approval.

Create a rule

The screen calls a rule a policy.

Choose New Policy. The editor opens with Surface set to AgentRunner, Effect set to Allow and Enabled ticked.
Choose the Surface: Chat, Copilot, AgentRunner or Pipeline.
Choose the Effect: Allow, RequiresApproval or Deny.
Enter the Tool pattern. A * stands for any run of characters and a ? for one character. Matching ignores capital letters, and a leading sj_ is ignored on both sides.
Choose the Classification: Auto (name heuristic), Force read or Force mutating.
Optionally add Notes (optional) that say why the rule exists.
Choose Save. The page shows "Policy saved."

Pattern	Matches
`sj_ninja_*`	Every tool whose name starts with `sj_ninja_`
`halo:*`	Every tool of the MCP source whose alias is `halo`, such as HaloPSA's native MCP source
`*`	Every tool on the surface

A tool from an MCP source is written as the source's alias, a colon and the tool's name. This is also how the audit list shows it.

The table lists each rule with its Surface, Tool pattern, Effect, Class and Enabled state. Choose On or Off to switch a rule on or off, the pencil to edit it and the bin to delete it. Before you add the first rule, the table reads "No tool policies defined. The Agent Runner surface stays default-deny until you add Allow rules."

The name check reads only the tool's name. A tool whose name sounds like a query can still change something. Before you allow a tool broadly, set Force read or Force mutating on the rule so the decision does not depend on the name.

Starter rules for AgentRunner and Pipeline

When AgentRunner or Pipeline has no rules at all, QuantumOps adds a starter set the next time it needs one. If you delete every rule for a surface, the starter set is added again.

Allow for QuantumOps's own read tools. These are the HaloPSA lookups, searches of the support memory, the analytics reads, the documentation lookups, the QBR lists and reads, and the file tools that add a chart or file to a run's own conversation.
RequiresApproval on AgentRunner and Deny on Pipeline for saving a fact to the support memory, and for the requests that ask HaloPSA to add a note or update a ticket.
Deny on both surfaces for forgetting a fact in the support memory.

Review and revoke standing approvals

When someone approves a tool in chat, they can approve it for that conversation or always. Standing approvals from chat lists those answers with the User, Tool, Scope, Granted (UTC) time and an Actions column. A scope of thread covers one conversation, and always covers every conversation of that person. The User column shows the person's sign-in identifier, not a name.

A standing approval only satisfies a RequiresApproval decision. A Deny rule still wins, and a tool the server marks as destructive always asks.

To revoke one, choose Revoke on its row. It stops applying on that person's next message. When the list is empty it reads "No standing approvals."

See Approving Qubit's actions for what the person sees.

Generate Allow rules for a runner

AgentRunner denies everything by default, so a saved runner cannot act until its tools have Allow rules. Auto-provision AgentRunner rules creates them from the runner's own tool allowlist. It appears once at least one runner exists.

Choose the runner in the list.
Choose Generate Allow rules.

QuantumOps creates an Allow rule on AgentRunner for every pattern in the allowlist that does not already have a rule on that surface. The page tells you how many it created, or that every pattern already has one, or that the runner has no patterns. Each new rule is as broad as the pattern it came from, so review them afterwards.

Read the audit list

Recent tool invocations shows the 50 most recent tool calls, newest first. Choose Refresh to reload it.

Column	What it shows
When	The date and time of the call.
Surface	The surface it came from.
Tool	The tool's name.
Principal	Who or what made the call.
Effect	The decision: Allow, RequiresApproval or Deny.
Outcome	What happened, for example Executed, Failed, Denied, PendingApproval or Approved.
ms	How long the call took, in milliseconds.

The list does not show what a tool was given. An empty list reads "No tool invocations recorded yet."

Where approvals are decided

A call that needs approval waits for a person. Approving Qubit's actions lists where each kind of request is decided.

Approving Qubit's actions: what the person sees when a tool needs approval.
Agent Runners: the surface that is denied by default.
MCP sources: the sources whose tools these rules govern.
StackJack: the page this card sits on.
Approvals tab: where runner approvals are decided.
Connecting external AI clients over MCP: the outside clients that use the Copilot surface.

Was this helpful?

Still need help? Ask the team