Credential encryption
Integration credentials are encrypted with AES-256-GCM using a derived application key, unique initialization vectors, and authentication tags.
Write-only secrets · Versioned ciphertext
Security & trust
Trust starts with
knowing what
protects your data.
Explore how Undown handles workspace access, protects saved integration credentials, and separates public updates from internal operational data.
Credential protectionIllustrative demo
Stage 2 of 3
Authenticated application encryption.
AES-256-GCM uses a derived application key, a fresh initialization vector and an authentication tag to protect the stored credential.
- algorithm
- AES-256-GCM
- key derivation
- HKDF / SHA-256
- initialization vector
- 12 random bytes
A new IV is generated for each encryption operation.
No live credentials or requests
Current application controls
Protection at the points
where it matters.
Tenant boundaries
Organization-scoped requests require an authenticated session, active membership, and permission for the requested action.
Membership + permission + scoped query
Role-based access
Owner, administrator, member, and viewer roles separate management privileges from read-only access across workspace resources.
Four workspace roles
Administrative audit trail
Platform changes can retain actor, action, target, request, network, and before/after context while redacting sensitive field names.
Sensitive values redacted
Session protection
Production authentication uses secure cookies, trusted origins, account-disable checks, and session revocation after password resets.
Secure production cookies
Public data minimization
Public status responses use customer-facing component data and derived identifiers without exposing monitor targets or organization records.
Targets remain private
An identity is only the first check
Signed in doesn't mean
allowed everywhere.
Explore an illustrative request from a workspace viewer. Membership and action permissions determine whether a workspace operation can proceed.
Example actor / Workspace viewer
- Authenticated sessionSatisfied
- Workspace membershipSatisfied
- Action permissionSatisfied
Request allowed
A viewer can read a monitor in a workspace they belong to.
Demo only. These controls do not access or change a real workspace.
Intentional public boundaries
Share the service update.
Keep the investigation private.
Public status pages expose customer-facing component information and updates, while private monitor targets and workspace membership stay out of public responses.
Inside the workspace · Fictional example
Checkout API incident
- Monitor target
- checkout.example.com/health
- Regional evidence
- Virginia + Frankfurt / HTTP 503
- Investigation notes
- Internal responder context
Public status page · Fictional example
Checkout service disruption
We are investigating checkout errors. Our team is working to restore service and will share an update here.
Customer-facing component name and published update
No monitor target, workspace membership or internal investigation notes.
Data and its purpose
Understand what is handled.
Account and membership
Authentication, organization access, invitations, and support
Accessed through authenticated, role-aware operations
Monitoring telemetry
Availability history, incident evidence, charts, and reports
Organization-scoped; historical observations survive region retirement
Integration credentials
Deliver notifications to configured destinations
Application-encrypted and never returned in full after storage
Public status content
Communicate component health, maintenance, and incidents
Explicitly selected content with internal targets removed
Current controls and ongoing work
A clear view of where we are.
Current controls are separate from work in progress and planned capabilities. Planned items are not available features or delivery commitments; this page is not a claim of independent certification.
Current
Organization-scoped authorization
Membership and role permissions are evaluated before workspace data access.
Encrypted integration vault
AES-256-GCM protects stored provider credentials at the application layer.
Platform audit records
Administrative changes retain traceable context with sensitive-key redaction.
In progress
Published retention schedule
Documented deletion windows and customer-facing retention commitments.
Formal incident-response policy
Published severity, escalation, notification, and post-incident commitments.
Self-service session management
User-visible active sessions with individual and global revocation controls.
Planned
Multi-factor authentication
Additional account verification beyond the primary password flow.
Enterprise identity
SAML-based SSO and automated identity lifecycle management.
Independent compliance program
Evidence collection and third-party assessment before any certification claim.
Security questions deserve a conversation
Reviewing a requirement?
Found a concern?
Share the affected feature, a description and safe reproduction steps. Please omit passwords, live tokens and customer data from your initial message.