Your people
Review membership and role assignments. Test sensitive planning and QA workflows with representative accounts.
Start from the responsibilities each person needs.Understand who can act, where data travels, and how your workspace is operated.
Make informed choices for your people, your work, and your organization.

Security is a set of controls you can understand, configure and review.
Prepare your reviewStart with the controls that protect workspace boundaries, sensitive credentials and connected access. Then evaluate the roles, workflows and configuration your team will actually use.
PostgreSQL row-level security scopes tenant data to the workspace’s database role.
Database-level tenant policiesProject roles and permission groups define access for supported planning and QA operations.
Roles, groups & explicit permissionsQA secrets are encrypted in storage and omitted from ordinary list and detail responses.
AES-256-GCM for QA secret fieldsMCP credentials support scopes, project restrictions, expiry and revocation in workspace settings.
Scoped tokens & consent-based OAuthThe right review considers both the platform controls and the environment around them.
Work through it with usWorkspace boundaries and project permissions solve different problems. Use both in your review, and treat public sharing and connected clients as deliberate access decisions of their own.

Tenant data is scoped with PostgreSQL row-level security. Within the workspace, project roles and permission groups define responsibilities for supported operations such as ticket changes and QA execution.
Review membership and role assignments. Test sensitive planning and QA workflows with representative accounts.
Start from the responsibilities each person needs.Review consent, token scopes, project restrictions and expiry before connecting an external AI client.
Grant only the access needed for the intended workflow.A public document link enables access outside the signed-in workspace. Review published links separately from internal roles.
Make the audience and sharing decision explicit.QA credentials have a dedicated secret-handling flow. The stored value is encrypted, ordinary responses omit it, and a separate reveal action checks the relevant permission.
The secret value is encrypted before it is stored.
Lists and details indicate whether a secret exists, without returning its value.
A dedicated reveal request checks the required permission before returning the secret.
Secret-field encryption is one layer. Review database volumes, file storage, backups and encryption-key handling for your deployment as well.
Give AI clients a defined way into the workspace. Choose the scopes and projects they need, review the consent they request, and keep a clear way to end access.
MCP tokens support separate scopes for reading, writing, deletion, administration and QA secret access. Optional project restrictions further narrow the intended connection.
Explore the MCP connectionSelect the capabilities the workflow needs. Treat write, delete, administration and secret access as separate decisions.
Use a project restriction where the connection only needs part of the workspace.
Choose a lifetime that fits the use case and revisit credentials that no longer have an owner.
MCP authentication checks expiry and revocation against current token records on each request.
Supported external AI clients use an approval flow with PKCE. Review the requested scopes and projects before granting access.
MCP token secret material is displayed at creation and stored as a digest. Keep the issued credential in an appropriate secret store.
Keep credentials aligned with their owners, current projects and active use. Remove access when a connection is no longer needed.
Your application’s location is one part of the picture. AI providers, email and integrations introduce additional destinations. Review the endpoint, the information sent and the applicable data terms.
Explore model choices
Self-hosting places the application on your infrastructure. A request to an external model endpoint still sends the selected context to that provider.
Illustrative data path. Email, integrations, connected clients and other services have their own destinations and terms. Review those connections separately.
A security review should include how you deploy changes, inspect activity, restore data and handle credentials. Bring the platform behavior and your operating procedures into the same conversation.
The supported in-app self-hosted update flow verifies an Ed25519-signed release manifest before applying an update.
Self-hosted deployments can use Caddy to provision public HTTPS when a valid domain and the required network access are configured.
Agent execution records and step traces provide status and diagnostic context for supported workflows. Retention affects what remains available.
For self-hosted environments, include the database, file storage, configuration and matching application secret key in your recovery plan.
The right deployment fits your organization’s requirements and capacity to operate it. Confirm the responsibilities, configuration and evidence that apply to the option you choose.
Scroll to compare both deployment options
| Review area | Leera Cloud | Self-hosted |
|---|---|---|
| Hosting & data location | Confirm the hosting region and data-handling terms. | Choose and operate your hosting environment. |
| Database & file storage | Review the available storage and retention details. | Configure storage, access and infrastructure encryption. |
| Backup & recovery | Confirm backup, retention and restoration arrangements. | Own the backup schedule, retention and restore tests. |
| Updates & maintenance | Discuss the maintenance and communication process. | Plan releases, maintenance windows and recovery steps. |
| AI & connected services | Review the endpoints and terms used by your workflows. | Configure supported endpoints and review external data flows. |
An enterprise engagement can include architecture reviews, security questionnaires and rollout planning, with responsibilities and deliverables agreed together.
Identify the workspaces, projects, documents and credentials your team needs to protect. Map who should access each workflow, which documents may be shared publicly and who owns access decisions.
Decide how Leera will be deployed and which AI providers, email services and integrations it will use. Review the endpoints, data flows and provider terms alongside your network and storage requirements.
Use representative accounts and real workflows to check project permissions, document visibility, credential access and connected-client scopes. Include administrators, team members and the AI connections you intend to enable.
Set ownership for access reviews, token revocation, credential rotation, updates and recovery. Work through the evidence your security team needs, document escalation contacts and test the routines before a wider rollout.
Choose the topics your team needs to work through. Build a practical set of questions for your deployment, then bring the brief to the conversation.
Agree the evidence you need, identify who owns each answer, and capture the follow-up actions together.
Bring us your security requirements or a suspected vulnerability. Clear context helps us get the right people involved.
Share your questionnaire, required controls and procurement process. Ask for the architecture details, available evidence and contractual information relevant to your deployment.
Contact the teamReport privately with the affected area, impact and steps to reproduce. Keep credentials and customer data out of the initial message; we can coordinate any sensitive details through an appropriate channel.
support@leera.ioNeed a specific certification, independent audit or contractual commitment? Confirm its current status and available evidence with our team during your review.
More context for evaluating access, data flows and deployment responsibilities.
Read the privacy policyLeera uses PostgreSQL row-level security for workspace data isolation, with project roles and permission groups for supported project workflows. Workspace administrators, instance administrators and project members have different responsibilities. During setup, map the permissions your team needs and validate sensitive workflows with representative accounts. Review public document links separately, because publishing a document creates a way to read it outside the signed-in workspace.
QA credential passwords, stored AI provider keys and designated instance credentials use AES-256-GCM encryption. Normal QA credential reads show whether a secret is stored; reading the value requires a separate, permission-checked reveal action. For self-hosted recovery, keep the matching application secret key with the database backup. Encryption for storage volumes, file backups and external services is part of the deployment configuration and operating plan.
Supported AI clients can connect through an OAuth consent flow, and clients that use a manual connection can use an MCP access token. Review the requested scopes and project selection before granting access. Token management lets the owner inspect and revoke their credentials, and MCP checks token expiry and revocation when authenticating requests. QA password retrieval has a separate secrets scope. Revoke unused connections and include connected clients in regular access reviews.
AI requests go to the provider and endpoint configured for the workflow. On a self-hosted instance, you can choose supported cloud providers or compatible endpoints running on your network. Review the model capabilities, access settings and provider data terms before enabling a workflow. Application hosting and AI processing are separate choices; provider retention and training terms need to be confirmed for the service and agreement you use.
Scheduled agent execution views include status and associated agent messages. Supported step-by-step AI flows also record execution traces with tool outcomes and verification results. Use the records available for your workflow to investigate behavior and review important changes. Trace retention follows the instance settings, so agree on the history your team needs and how it will be preserved as part of your operating plan.
Your team chooses and operates the application infrastructure, including the server or cluster, database, file storage and network access. You also decide which services the instance can reach. Licensing, updates, AI, email and integrations have their own connectivity requirements; paid offline licensing can be arranged for isolated environments. Define ownership for hosting, service credentials, monitoring, updates and recovery before rollout.
The Docker Compose stack includes Caddy, which can provision public HTTPS when a domain points to the server and the required ports are reachable. The Helm chart supports TLS at your ingress. Configure and verify the certificates and network path your team will use. Internal service connections and external database or storage connections need their own transport review; a public HTTPS address covers the connection to that entry point.
The in-app update flow requires verified release information from an Ed25519-signed manifest. The supported updater checks published image digests when supplied, then applies the release through its backup, migration, restart and health-check stages. Keep the database, matching secret key, deployment configuration and uploaded files together in your recovery plan. Copy backups off the host and test a restore. Returning to older images does not reverse database migrations.
Yes. Bring your questionnaire, required controls and evidence needs to the Leera team. We can work through architecture, data handling, deployment choices and contractual requirements with your security and procurement stakeholders. Confirm the current documentation and certification or independent-audit status directly during that review. An enterprise engagement can include dedicated coordination, a representative pilot and an agreed plan for the controls and operating responsibilities your organization requires.
Email support@leera.io with the affected feature or URL, the Leera version if known, the potential impact and clear reproduction steps. Include only the evidence needed to explain the issue, with credentials and customer information removed. Use this private contact route for vulnerability details so the team can coordinate the investigation and follow-up with you.
Walk through the controls, the data paths and the operating model.
Find the right foundation for your team.