Enterprise trust posture, without the checklist theater.
Lamba is built as an identity core. Security controls, incident communication, and procurement-ready documentation stay explicit and testable.
Security model
These are the pillars behind Lamba's identity-first architecture.
Authentication
Authorization and session controls aligned with OIDC standards.
Data protection
Scoped tenant/project boundaries with encryption at rest and in transit.
Reliability
Status visibility, measured uptime, and change-safe rollout habits.
Observability
Audit trails and request-level traceability for critical auth paths.
Controls in operation
The controls below map directly to behavior tested in auth, webhook, and platform contracts.
Authentication practices
- Authorization Code flow with exact redirect URI matching.
- PKCE required for public clients; refresh token rotation on session updates.
- Tenant- and project-scoped roles enforced across API and console surfaces.
Data protection practices
- TLS everywhere and encrypted storage for persisted identity data.
- Strict tenant and project scoping in policy and membership flows.
- Administrative actions captured in audit trails with actor metadata.
Reliability practices
- Rate limiting, bounded retries, and explicit failure contracts.
- Degraded signals reflected in public status summaries.
- Maintenance and incident updates published through status timelines.
Observability practices
- Trace identifiers and error codes attached to problem responses.
- Webhook delivery logs with delivery outcome visibility.
- Daily health snapshots for core authentication components.
Vulnerability disclosure policy
If you identify a security issue, report it privately and include clear reproduction details. We acknowledge submissions quickly and prioritize remediation by severity.
- Initial acknowledgement target: within 1 business day.
- Severity triage with response guidance in follow-up updates.
- Public disclosure coordinated after a fix or mitigation is available.
Incident communication
Status updates are published through the public status page with ongoing incident notes and post-incident summaries.
Status page
Current service state, active incidents, and resolution progress.
Email subscribe
Incident and maintenance updates for subscribed contacts.
Postmortem timeline
Root cause, remediation, and prevention actions after impactful incidents.
Initial customer update target: within 60 minutes for major incidents.
| Category | Retention window | Notes |
|---|---|---|
| Audit logs | 7 to 365 days (plan dependent) | Retention expands with plan tier and selected add-ons. |
| Webhook delivery logs | 3 to 365 days (plan dependent) | Includes delivery status and retry outcomes. |
| Usage and quota telemetry | 30 to 365 days (plan dependent) | Used for plan-limit enforcement and forecasting. |
| DSAR and support records | As required for legal and operational obligations | Limited metadata may be retained for compliance and abuse prevention. |
Security documentation package
These references are maintained as source-controlled docs and kept aligned with the public API behavior.
Webhook signature verification
Header formats, HMAC validation, and replay protection guidance.
Incident communication model
Status updates, incident lifecycle, and postmortem expectations.
How long is data retained?
How do you handle incident response?
How do you separate environments?
How are webhooks secured?
How do rate limits work?
Security contact
For security reviews, vulnerability disclosure, or procurement security questionnaires, contact our team.
Email: security@uselamba.com