Source: https://docs.amadalis.ai/developers/governed-tools/

# The copilot's governed tools

Use this guide when working with **Copilot**, the AI assistant, in the site admin. It cannot publish without your approval: the platform requires an approval grant from the person signed in before applying that proposed change.

Checked against the product’s code on 7 November 2026.

**The model proposes; the platform authorizes.** A model response is a proposal to call a tool with declared inputs and validation rules. The platform decides whether the person signed in may use it and whether the proposed change can proceed.

This page explains the rules a customer can expect. It is not an API for calling the copilot from an external agent.

## One action, from request to result

1.  You ask for a result, such as changing a headline or publishing a page.
2.  The platform checks your permissions and validates the proposed input.
3.  It prepares a preview of the change.
4.  A consequential action stops at an [approval card](https://docs.amadalis.ai/reference/glossary/#approval-card).
5.  Your approval authorizes that prepared action. The platform checks that the person and the relevant state still match.
6.  The result includes a [receipt](https://docs.amadalis.ai/reference/glossary/#receipt) and, when supported, **Undo**.

An expired approval or a changed target can require a new preview. It is better to read a fresh card than to approve a description of a page that has since changed.

For requests in a connected business application, the copilot runs any needed record lookup before preparing the change that depends on it. The change still waits for your approval. If the lookup results do not identify the record, the copilot can ask which record you mean. A failed lookup stops that plan without saving the change.

## What needs approval

| Action | Expected boundary |
| --- | --- |
| Create or edit ordinary page content | Writes a draft. Publishing remains separate. |
| Publish, take offline or delete | Requires approval. |
| Change consequential settings, consent policy or crawler policy | Requires approval. |
| Export or erase visitor data | Requires approval and the relevant permission. Erasure has no undo. |
| Schedule publication | Approves the exact future publication once. Editing the content through the Composer or the copilot afterwards cancels that schedule. |

For pages and posts, the publish check runs before a schedule approval card, again when you approve and again when publication is due. A refusal at the due time cancels the schedule without publishing the draft or its changes. If the check cannot finish, publication waits for another check. Approval does not bypass these checks.

These rules govern what the copilot does. A person’s own **Publish** click in EmDash’s editor publishes at once, as their explicit act. Anything the copilot publishes always pauses for the approval card.

A consequential tool cannot register without an approval requirement. The platform checks the approval from the person signed in. Prompt wording does not replace those checks.

The available tools also depend on your role and the site’s enabled [capabilities](https://docs.amadalis.ai/reference/glossary/#capability). Ask the copilot **“What can you do?”** to get the current set for your site and role.

## Read the card

Before deciding on the card:

1.  Check the object.
2.  Check the scope of the change.
3.  Read the consequence.
4.  Read the reversibility line.

Refusing the card leaves the proposed action unapplied. A card that is not answered within five minutes expires without approval. A timeout or server restart never becomes approval.

An Admin role is not permission for the model to approve its own work. The copilot cannot install or update plugins. It also refuses to switch off or remove the platform’s own plugins.

Credentials belong in the relevant account or integration form. For actions such as SSO setup, the copilot opens the secure account control rather than collecting the secret in chat.

## Undo has a scope

An Undo is tied to the change it reverses and can expire. A newer change can make an earlier Undo refuse instead of overwriting newer work. When the reversal itself changes what visitors see, it can require approval too.

Some changes have no operation that puts the earlier state back. The approval card must not promise reversibility without an implementation. Read [Known limitations](https://docs.amadalis.ai/trust/known-limitations/) for the current gaps.

The account’s [Security log](https://docs.amadalis.ai/reference/glossary/#security-log) and the site’s copilot [Activity](https://docs.amadalis.ai/reference/glossary/#activity) are separate records. Each Security log entry is linked by a SHA-256 checksum to the previous entry in the platform’s audit log. Its [tamper-evident checks and limits](https://docs.amadalis.ai/account/activity/#understand-verification) are separate from the site’s Activity record. An approved change goes ahead even if its Activity record fails to save; the failure is logged on the server. The change keeps any Undo it offered on its receipt.

## External automation

EmDash’s MCP endpoint is disabled on Praxis sites. Personal API tokens cannot write through EmDash’s API. The [public machine files](https://docs.amadalis.ai/developers/machine-readable-site/) offer content for reading. Reads with a personal API token must also pass the team’s [API token checks](https://docs.amadalis.ai/account/site-access-and-settings/#personal-api-tokens).

The internal tool registry does not establish a supported external write endpoint. Discuss a required integration with Amadalis before depending on one.

For the request inventory by customer area, read [What you can ask the copilot](https://docs.amadalis.ai/reference/copilot/).