> 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lleverage.ai/administer-and-govern/security-and-assurance/data-connections-and-credentials.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.