> 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/reference/technical-and-support/runtime-and-security/security-and-performance.md).

# Security reference

A conservative technical reference for reviewing access, credentials and data authority without substituting product documentation for formal assurance.

Security in an operational automation is not one setting. It is the combination of **who can access the Project**, **which systems Lleverage can reach**, **what authority those Connections carry**, **where sensitive values are stored**, and **who can change the configuration**.

For the broader IT and buyer review path, start with [Security and assurance](/administer-and-govern/security-and-assurance.md).

## Use the intended authority surfaces

Keep credentials and operational context separate:

* use **Connections** for authorised access to external systems;
* use **Secrets** for sensitive values;
* use **Variables** for reusable non-secret configuration;
* use **API Tokens** for programmatic access to Lleverage;
* use Files, Tables, Knowledge and other Intelligence surfaces for operational context rather than credentials.

Do not hardcode passwords, API keys or other secrets in Workflow content, Skill instructions, prompts or ordinary project files.

See [Data, connections and credentials](/administer-and-govern/security-and-assurance/data-connections-and-credentials.md) for the review model behind this separation.

## Review effective authority, not only the label

When a Connection or credential is introduced, check the external account behind it as well as the Lleverage configuration. The relevant questions are what it can read or change, who controls it, how it is revoked and whether its authority is broader than the operational task requires.

The same principle applies to project access: product roles are one part of governance, while the organisation still needs to decide who should own, operate and approve the underlying process.

## Formal assurance is separate

This page deliberately does **not** state certification, legal, encryption, retention or contractual commitments that have not been verified for the current service.

For procurement, audit or security review, use current assurance material supplied by Lleverage rather than treating an old GitBook statement as evidence. [Architecture and assurance review](/administer-and-govern/security-and-assurance/architecture-and-assurance-review.md) explains what to gather alongside that formal material.


---

# 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/reference/technical-and-support/runtime-and-security/security-and-performance.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.