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.