> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noclick.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tool permissions
> Lock the actions a connected account allows, and approve each locked call before it runs.
Every connected account carries its own approval rules. They apply wherever that connection is used: agents in your workflows, your [coordinator](/getting-started/coordinator), and any [MCP client](/mcp/setup) holding your NoClick key.
An unlocked action runs the moment something asks for it. A locked action runs nothing until you approve that exact call.
## Set the rules
Go to **Settings → Credentials** and click the shield labelled **Tool permissions** on the connection's row.
The **Use without approval** row sets everything at once.
| Choice | What it does |
| ------------- | ----------------------------------------------------------------------------------- |
| **Read-only** | Reading actions run without asking. Every other action on the connection is locked. |
| **All** | Every action runs without asking. Lock individual ones below. |
| **None** | Everything is locked, including actions the service adds later. |
**Read-only** picks from the actions the connection knows about today. **None** is the only choice that also covers new ones.
Search the list with **Search actions** and click the lock beside any action. The counter reads `N locked · N unlocked`.
Click **Save rules**. The button reads **Saved** once there is nothing to save.
Only the connection's owner can edit the rules. Anyone else sees "The connection owner manages these rules".
## Locks in the node settings
A node wired into an agent as a [tool provider](/agents/tools) shows a lock beside each operation you allowlist, so you can change what needs approval without leaving the workflow. The locks belong to the connection, not to the node, so the same rule applies everywhere that connection is used.
Changing a lock saves on its own, separately from which operations the agent is allowed to call.
## Approving a call
A locked call stops before it reaches the service and waits for you. Nothing has run at that point.
The request shows up under **Needs you** on the [Dashboard](/getting-started/dashboard), reading ` · Review this call before it runs`. Open the row and you see the action and the exact arguments it would send, then **Approve once** or **Decline**. **Manage rules** goes from there to this connection's permissions page.
| Rule | Detail |
| -------------------------- | --------------------------------------------------------------------------------------------------------------- |
| What an approval covers | One call, with exactly those arguments. A second attempt needs a second approval. |
| How long an approval lasts | 30 minutes from your decision. |
| How long a request waits | 24 hours, then it expires unreviewed. |
| Changing the rules | Any pending request on that connection is invalidated, because it was raised under the rules you just replaced. |
| Declining | The caller is told the action was declined. A workflow run waiting on it ends in an error. |
| Pending at once | Up to 100 requests per connection. |
Option lookups count too. Where a connection has any restriction, loading a dropdown's choices from the service also asks for approval.
## What agents can and cannot change
An agent or an MCP client can **add** restrictions to a connection, for example when you tell your coordinator to always ask before it sends email. It can never take one off.
Removing a lock happens only on this page, signed in as the connection's owner. Your coordinator can send you a link to it, but saving the change is yours to do.
A restriction is a rule, not a reminder. Asking your coordinator to remember that it should check with you first is a [memory](/getting-started/coordinator), and a memory does not stop a call. Lock the action to stop it.
## Next steps
Connect a service with OAuth or an API key.
Wire a node into an agent and allowlist its operations.