> 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/administer-and-govern/security-and-assurance/data-connections-and-credentials.md).

# Data, connections and credentials

Keep operational data and system authority in the product surfaces intended for them, and review the external authority behind each Connection.

Operational context and system authority are different things and should be stored accordingly.

Use the dedicated product surfaces for their intended purpose:

* **Connections** for authorised access to external systems;
* **Secrets** for sensitive values;
* **Variables** for reusable non-secret configuration;
* **Files, Tables and Knowledge** for operational context and data;
* **API Tokens** for programmatic access to the Lleverage API.

Do not put passwords, API keys or other credentials into Skill instructions, prompts, ordinary Files or Workflow content merely because those places are convenient.

## Review the full authority path

A Connection is only the Lleverage side of an authority chain. When approving a production use case, also inspect:

* whose user or service identity is connected;
* what that identity can read or change in the external system;
* which actions Lleverage exposes from that Connection;
* whether the authority is broader than the use case requires;
* who can revoke or replace the external authority;
* whether the Connection is project- or organisation-scoped.

## Delegated access has multiple gates

Shared resources are a useful example of why external permission and Lleverage configuration must be reviewed separately.

For Outlook shared mailboxes, Exchange delegation, Microsoft OAuth scopes and the mailbox address used by the action are separate pieces. Granting a user mailbox access in Exchange does not create or upgrade the corresponding Lleverage Connection. Conversely, enabling shared-mailbox scopes in Lleverage does not grant Exchange access.

Service-to-service App Registrations use another authority model again: the external Azure application permissions determine what the service identity can reach. Treat that as deliberate infrastructure, not merely a different sign-in button.

## Prefer explicit operational identities

For long-running background processes, decide whether the authority should belong to an individual user or a managed service identity. Consider what happens when the employee leaves, a password or consent is revoked, or the process expands to additional resources.

The right choice depends on the external system and process. The important part is that the identity and its authority are intentional and reviewable.

## Treat credentials as privileged configuration

Credentials should not travel with ordinary project content. This matters especially for Skills, prompts and files that may become part of Agent or Workflow processing context.

Keep secret material out of screenshots, documentation examples and support messages. When support needs to identify a credential, use the provider, Connection, project and error context rather than pasting the secret value.

For Outlook's current delegated/shared-mailbox setup, see [Outlook](/administer-and-govern/control/connections/outlook.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/administer-and-govern/security-and-assurance/data-connections-and-credentials.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.