LAP

Security

Trust boundaries

The platform process and the database are trusted. Everything else is not: the language model, the documents it reads, the tools it calls and the systems it reaches. Each boundary crossing passes a control that does not depend on the model behaving well.

Platform boundary API Workers Console Database boundary row-level security per tenant Tenant A Tenant B Clients Identity Gateway Tool wrapper Retrieval filter Models External systems Documents and tool output untrusted input
Figure 1. Trust boundaries. Models, documents and external systems are outside; the platform and the database are inside; every crossing passes a control.

Identity and access

Users come from the customer's identity provider: the production profile verifies OIDC access tokens against configured issuers, and the token's issuer selects the tenant. The platform resolves who is asking and which tenant they belong to from the credential, never from the request, and binds that scope to the run. Every later check reads the same scope: the API, the queue, the database, retrieval, tools and approvals. Service identities can start work but can never approve it.

Credential Identity provider verification Principal tenant, groups, engagements Scope bound to the run checks API route Queue dispatch Database access Retrieval filter Tool wrapper Approval
Figure 2. One identity resolution, enforced at every layer.

Tenant and data isolation

Tenant separation is enforced inside the database on every table, not in application code. A request without a resolved scope sees no data at all. Budgets, usage, events and search indexes are separated the same way, and the platform's own database access cannot bypass the boundary.

Permissions and action controls

Three questions are asked at every layer: may this person read this document, run this agent, call this tool. Document access is checked inside the query, so the model is never shown text the caller may not read, and citations are verified before an answer is returned. Every tool call passes one wrapper that applies permissions, approval rules, budgets and audit. Actions with external effect are recorded so that a retry cannot repeat them.

Human approvals

Sensitive actions pause the run and wait for a person. The approver must hold the approver role and must be someone other than the requester. The pause survives restarts, a denial is recorded with the run, and a timeout fails the action rather than approving it.

Action classified approval required Pending approval durable record Decision approver role, different person Approved run resumes Denied run cancelled, record kept Expired run failed, needs review
Figure 3. The approval gate. A different person decides, and a timeout is a failure.

Auditability

Every state change, approval, tool call, external action and model cost is written to an append-only record with its tenant, run, actor and time. Each run carries a trace identifier that links the record to the traces and logs. Operators inspect runs in the console and export records through the API.

Model and data safety

Protection against prompt injection does not rely on the model resisting it. Retrieval is limited to permitted documents, tools are fixed per agent, citations are verified, usage is capped and consequential actions need a person. Agents hold no credentials, logs are redacted, and the platform runs in the customer's infrastructure, so model providers receive only what an agent sends under the tenant's policy.

Security testing

Release gates run before every release and a failure blocks it: tenant-isolation probes generated from an independent statement of the policy, a prompt-injection suite that assumes a fully compliant model, a restart and recovery drill, failure injection on external connectors, and a quality evaluation on a fixed dataset. The suites grow with every new case.