Before access
A member selects the customer, reason, scope, and duration. An owner or admin reviews the request, or a designated team approver on the Team plan. Admins may self-approve, and Devora records that separately.
Security and shared responsibility
Security starts with
clear responsibilities.
Devora coordinates controlled staff access to customer accounts. Your application keeps control of authentication, tenant authorization, credentials, and protected routes. This page explains where that boundary sits and how to test it.
Shared responsibility
What Devora does.
What your application must do.
Devora adds governance and session controls around customer access. It does not replace your authentication or application authorization.
| Area | Devora | Your application |
|---|---|---|
| Customer identity and session | Coordinates the approved target, session context, duration, and handoff. | Finds the correct customer, creates and revokes the credential, and validates sign-in. |
| Authorization and scope | Provides trusted session context, read/write scope, endpoint rules, expiry, and liveness checks through the backend SDK. | Keeps tenant and permission checks in place, installs the guard on protected routes, and identifies sensitive endpoints. |
| Access decisions | Records requests, administrator decisions, reasons, scope, timing, self-approval, revocation, and termination events. | Defines the operating policy, including whether independent approval or customer notice is required. |
| Evidence and recording | Keeps access history and can provide optional masked recording and activity capture when enabled. | Keeps any domain-level audit events needed for business actions and decides whether capture is appropriate. |
Frontend restrictions help staff understand the session, but the backend is the security boundary. Protect every relevant API route and keep your existing tenant checks in place.
Access lifecycle
Control access before, during, and after the session.
During access
A visible banner identifies the session. The integrated backend guard evaluates scope, endpoint rules, expiry, and session checks while your application continues enforcing its own permissions.
After access
The agent or an admin can end the session, an admin can revoke the approval, and the session expires automatically. Your application must revoke the credential it created.
Credential handoff
A one-time path back to your application.
Your backend creates the impersonation credential. Devora holds its temporary copy encrypted while the short-lived, one-time handoff is available. Successful redemption clears that temporary copy before returning the credential to the frontend SDK. Unused handoffs expire and are rejected, with expired payloads removed by scheduled cleanup.
Your application then validates the credential and establishes the customer session. Redemption is not proof that application sign-in succeeded, and stored encryption is not end-to-end encryption that prevents Devora from delivering the credential.
Data and evidence
Collect what the workflow needs. Treat capture separately.
Customer identification
Devora retains an encrypted customer ID and, when supplied, encrypted name and email fields so staff can identify the account in the access workflow.
Workflow history
Requests and sessions retain the staff member, target, reason, scope, decisions, timing, and related security events. This is access history, not a claim that every application action is logged.
Optional capture
Recording and activity capture are disabled by default. If enabled, administrators configure masking and supported retention, and authorized replay access is audited.
Retention and responsibility
Baseline retention is 30 days for capture, 180 days for request and session records, and 365 days for the pseudonymous security audit. Customer notice and lawful use remain your organization's responsibility.
Evaluation guide
Test the boundary, not only the happy path.
Use a staging environment and test data before staff access real customer accounts.
- Connect a test application and use test customer accounts and explicitly allowed origins.
- Request read-only access, confirm an organization admin can review it, and check how self-approval is identified.
- Verify representative reads work while create, update, delete, billing, key, role, and account-management operations follow your configured rules.
- Attempt a cross-tenant request and confirm the application rejects it through its normal authorization.
- End an already-open session from Devora, then make another protected request and confirm the application credential is no longer accepted.
- Review the resulting request, session, and security records. If capture is enabled for the test, verify masking, retention, and replay access separately.
Scope of this page
This is a product architecture and responsibility overview. It is not a legal policy, technical specification, security certification, or statement of regulatory compliance.