> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/run-operations/agent/agent-context/access-and-approvals.md).

# Permissions and approvals

Understand what gives the Agent authority to act and where approval is required.

The Agent can only act through authority that exists for the current run.

Three questions matter:

1. **Can this person and run use the capability?**
2. **What does the external account behind the Connection allow?**
3. **Does this particular action require a human approval or decision?**

## Your access comes first

A web Agent session runs inside one Project.

Slack and Microsoft Teams can also run without a fixed Project, but a Channel does not grant access merely because someone can see or post in it. The Agent only resolves eligible capabilities from Projects the acting user is authorised to access.

Pin the conversation when work should be constrained to one Project.

## The connected account still has real permissions

A Connection can represent authority such as:

* which mailboxes can be read or sent from;
* which ERP companies or records can be accessed;
* which CRM objects can be changed;
* which files or folders can be opened.

A Skill or prompt cannot create broader authority than the connected account actually has.

## A Skill does not grant permission

A Skill tells the Agent **how and when** to use a capability.

Adding a Skill does not grant a new system permission, removing a Skill does not revoke the underlying Connection, and changing instructions does not bypass access controls.

## Approvals can happen at different points

Different human boundaries serve different purposes:

| Boundary                       | What it means                                                             |
| ------------------------------ | ------------------------------------------------------------------------- |
| **Connected action approval**  | A particular external-system action needs approval before it executes.    |
| **Skill-level approval**       | Use of a capability in a Skill is configured to ask first.                |
| **Agent question or approval** | The current foreground task needs information, judgement or confirmation. |
| **Workflow Request**           | A durable assigned human handoff inside a Workflow.                       |

If a write-access approval is pending, you can answer that decision with a typed reply. The approval still exists; the message does not bypass it.

![An Agent approval gate before a data-changing action is allowed to run.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FuOSw0W0BWiV0IYPwuixU%2Fagent-approval-before-write.png?alt=media)

## Shared and personal authority can differ

Some Connections are shared with a Project; others can be personal where supported.

Do not assume that a capability available to one person is automatically available to every Project member or background Workflow.

## Verify consequential actions

For high-impact work, verify the post-condition in the system that owns it.

Examples:

* the ERP order exists with the intended values;
* the email was sent from the intended mailbox;
* the file was written to the intended location;
* the record was updated under the right customer or company.

The Agent's activity helps explain what it attempted. The business system proves what happened.

Builders and administrators who need to configure Connection ownership, enabled actions or approval policies should use [Connections](/administer-and-govern/control/connections.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.lleverage.ai/run-operations/agent/agent-context/access-and-approvals.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.