Enterprise
Identity, access control, deployment inside your own boundary, and exportable evidence — the controls a security review asks for.
This section answers the questions a security review actually asks: who can sign in, who can change what, where the data sits, and what you can hand an auditor. Every page below is one control deep — link to it directly from a questionnaire response.
Single Sign-On
Configure a supported Clerk enterprise connection for hosted sign-in, or workspace-aware OIDC on a self-managed install.
SCIM provisioning
Clerk directory-sync configuration, Sentisec provisioning boundaries, and the explicit steps required for offboarding.
Roles and permissions
Two roles, one table, no ambiguity about who can change the workspace.
In-VPC deployment
Run the whole platform inside your own network boundary.
Log exports
Forward findings to your SIEM; pull evidence for an auditor.
Deployment options
Hosted, self-managed, in-VPC, air-gapped — and how to choose.
Enterprise controls
Confirm identity connections, deployment requirements and support scope for your installation. The controls below have separate configuration and lifecycle boundaries:
- Federated sign-in through a configured enterprise connection.
- Directory integration through Clerk where enabled. Sentisec handles creation events; offboarding also requires explicit API-key revocation. See SCIM boundaries.
- Deployment inside your own boundary, including fully disconnected environments.
- Your own key management. On a self-managed install, the key that encrypts workspace credentials lives in your secrets manager and never leaves your control.
- Configurable content retention. You choose how long request and response bodies are kept; after the window, the bodies are removed while the usage record — model, tokens, cost, latency, verdict — stays intact, so pruning never rewrites your history.
- A named engineering contact for incident response.
What you can show an auditor
Three artefacts, each answering a different question.
| Artefact | Answers | Where |
|---|---|---|
| Audit log | Who changed the workspace, and when. Append-only; Sentisec never updates or deletes a row. | Audit and metrics |
| Session record | What an agent did on a given run, step by step, and what Sentisec decided at each step. | Sessions |
| Forensic evidence | A signed, content-hashed record of a specific incident, verifiable without trusting the API that served it. | Log exports |
Evidence records carry compliance tags — framework, control, label — so a record can be pulled by the control it evidences rather than by timestamp. EU AI Act Article 12 and the NIST AI Risk Management Framework are the two catalogues mapped today; the tagging is catalogue-agnostic, so a framework you are audited against can be added.
Data handling in one paragraph
Requests are inspected in flight. What is kept afterwards is your choice: full content capture, or metadata only — model, token counts, cost, latency, verdict — with no prompt or response bodies stored at all. Provider credentials are encrypted at rest and are never returned by any endpoint, including to the operator who set them.
Support access to stored content is a door, not a default. Sentisec staff cannot read a request body incidentally: revealing one requires a written reason, and the audit row naming the staff member, the record, and the reason is committed to your workspace's audit log before the content is returned. If that write fails, the reveal fails. On a self-managed install the door does not exist at all, because we are not in your network.
Related
- Security — posture and certifications
- Deployment — hosted vs. self-managed
- API — the surface enterprise tenants build against