> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.shieldtp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Availability and approvals

> Control which tools can run interactively or in unattended Forge workflows.

Forge separates the broad access granted by roles from the surface-specific controls used at run time.

<img src="https://mintcdn.com/shield-9b0e0d30/M11Y9TQNwXQQD6-m/assets/diagrams/safety-layers.svg?fit=max&auto=format&n=M11Y9TQNwXQQD6-m&q=85&s=7b433cbf97a241a3a398db0a20f2af8a" alt="Diagram showing organization role and tool access as the base boundary, with Chat mode and approvals for interactive work and Availability for background work." width="1200" height="610" data-path="assets/diagrams/safety-layers.svg" />

## Availability

Availability determines whether a tool can run in a particular product surface. Depending on the system and rollout, surfaces can include:

* Chat
* Copilot
* Custom Agents
* Helpdesk
* Project Plans

Enable a tool only where the workflow needs it. A write tool appropriate for a technician in interactive Chat may still be inappropriate for an unattended Custom Agent.

## Interactive approvals

Approvals are organization-wide policies for tool calls made while a person is present. A tool can:

* run without an extra prompt;
* require approval;
* be locked to a mandatory policy.

In Chat, Ask mode is read-oriented. Full access can expose allowed write tools. When approval is required, the user reviews and allows or denies that specific call.

## Background work

Custom Agents, AI Engineer, and project-planning workflows can run without a user at the prompt. They do not wait for interactive approval policy. Configure their tool boundary with Availability and the underlying role, system, scope, and tool access.

<Warning>
  Setting “require approval” for a tool does not protect a background surface. If the tool should not run unattended, turn off its Availability for that surface.
</Warning>

## Recommended review

<Steps>
  <Step title="Start from the role">
    Confirm who or which workflow should have any access to the system.
  </Step>

  <Step title="Classify the tool effect">
    Distinguish reads, protected reads, reversible writes, external communication, and high-impact changes.
  </Step>

  <Step title="Enable only the required surfaces">
    Keep background Availability off until the unattended workflow has been tested.
  </Step>

  <Step title="Configure interactive approval">
    Require a decision where a human should inspect the target or content immediately before the call.
  </Step>

  <Step title="Test the effective boundary">
    Use a representative non-admin user and a dry run or safe target.
  </Step>

  <Step title="Review the Audit Log">
    Confirm write outcomes are visible and attributable.
  </Step>
</Steps>

All layers can narrow access. None of these settings can grant a capability that the provider, connection, catalog, or organization role does not already support.