> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/sfp-server/security-and-compliance/security-and-compliance.md).

# Security & Compliance

sfp server includes change-control and audit features: approval gates on release execution and other sensitive operations, append-only audit trails, and a compliance export over the approval record. This section documents what is recorded, how the controls work, and how to retrieve the evidence.

## Single-tenant by design

Every sfp server instance serves exactly one organization. The control plane (API), the execution plane (workers), the database, and the queueing infrastructure run as one isolated stack — there is no shared compute or shared data plane with any other customer.

* **Self-hosted** deployments run entirely on infrastructure you provision and operate. Your data never leaves your network boundary unless you configure an integration that sends it somewhere.
* **Cloud-hosted** deployments run as a dedicated instance per tenant. Isolation is at the instance level, not at the row level of a shared database.

Three properties follow from this:

1. **Trust boundary.** Everyone with access to an instance is a member of the organization it serves. Authorization inside the instance is role-based (`member`, `owner`, application tokens) — see [Authentication & Security Architecture](/flxbl/sfp-server/architecture-overview/sfp-server-architecture-overview-beta/authentication-and-security-architecture.md).
2. **Fixed network egress.** All traffic to registered Salesforce orgs — DevHub, production, sandboxes — originates from the instance's egress IP addresses. Org access can therefore be restricted to those addresses on the Salesforce side. See [Restricting Salesforce Org Access by IP](/flxbl/sfp-server/security-and-compliance/security-and-compliance/restricting-salesforce-org-access-by-ip.md).
3. **Audit data residency.** Audit records are stored in the instance's own database; retention and archival are controlled by the operator.

## Contents

| Page                                                                                                                                                    | Covers                                                                                                                                                          |
| ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Release Approvals](/flxbl/sfp-server/security-and-compliance/security-and-compliance/release-approvals.md)                                             | Per-environment approval gates on release execution, segregation of duties, approval channels (web UI, GitHub, Slack, Azure DevOps), and the approval lifecycle |
| [Audit Trails](/flxbl/sfp-server/security-and-compliance/security-and-compliance/audit-trails.md)                                                       | Append-only audit logs for credentials, secrets, environment access, and approvals; how to query them; the SOX compliance export                                |
| [Restricting Salesforce Org Access by IP](/flxbl/sfp-server/security-and-compliance/security-and-compliance/restricting-salesforce-org-access-by-ip.md) | Locking DevHub and production access to your server's egress IP using Salesforce profile login IP ranges                                                        |


---

# 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.flxbl.io/flxbl/sfp-server/security-and-compliance/security-and-compliance.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.