ECHO / SECURITY STANDARDS

Trust begins
with boundaries.

Protect access. Limit authority. Be clear about what is verified.

ECHO’s approach to security connects technical controls with a simple operating rule: understanding a request does not, by itself, grant permission to act.

Explore the standards

Applies to ECHO at echoone.aiUpdated September 16, 2026

01 / IMPLEMENTED CONTROLS

Protection in the application.

These controls describe the current hosted implementation. Their scope matters: a control protecting one type of information is not a guarantee about every system or deployment.

Access checked on the server

The Voice Readiness Lab requires a signed-in account. Administrative operations check the account’s current role and active status on the server before allowing access.

Authentication and authorization are separate checks.

Protected passwords & sessions

Passwords are salted and hashed. Session tokens are cryptographically random and stored as hashes. Session cookies use HttpOnly and SameSite settings, with Secure enabled in production.

Passwords and session tokens are not stored in plaintext.

Encrypted integration credentials

Credentials saved through ECHO’s managed integration vault are encrypted with AES-GCM, using a random initialization vector and a separately configured vault key.

This control applies specifically to managed vault credentials.

Boundaries around requests

Administrative changes enforce same-origin checks. Database queries use bound parameters, and supported service connections validate their authorization callbacks or signed requests.

Each integration has its own permissions and verification requirements.

02 / AI & ACTION BOUNDARIES

Capability is not authorization.

ECHO’s governed design separates what a model suggests, what an integration can do, what is permitted, and what actually happened.

Permission before execution: A connected service or available tool does not independently authorize an action. The workflow must apply its permission and policy checks.
Context with ownership: Server-side conversation state is scoped to the authenticated user and session. Context and model output do not establish a caller’s identity or right to access external records.
Evidence before completion: An attempted action, a successful connection, and an accepted human handoff are different states. The governing standard is to report only the outcome supported by evidence.
Review before learning: Conversation observations and suggested improvements do not become approved instructions automatically. Learning proposals pass through ECHO’s review and release controls.

03 / DATA HANDLING

Know what your workflow uses.

Conversation & review data

Depending on the feature, ECHO can process transcripts, conversation context, test feedback, and review records. Lab history may also be held in the browser. Consider shared-device access and use fictional or redacted information for formative testing.

Connected providers

Enabled model, speech, hosting, and business-service providers may process information needed for the requested functionality. Their terms, settings, and retention practices form part of the deployment’s data handling.

Deployment-specific requirements

Before using sensitive or regulated data, confirm the permitted data types, integration scopes, retention and deletion arrangements, and applicable agreements for that deployment. This page does not set a universal retention period or promise zero retention by every provider.

04 / ASSURANCE & SCOPE

Specific controls.
Specific claims.

This page is an implementation overview and a statement of ECHO’s governing standards. It is not an independent audit, penetration-test report, or certification.

Certification & compliance

No SOC 2, ISO 27001, HIPAA, or other compliance or certification claim is made here. A provider’s assurance does not automatically extend to ECHO or a customer’s deployment.

Security hardening and validation remain ongoing. Production readiness also depends on the configured infrastructure, account protections, monitoring, recovery procedures, and the specific use case. Review these requirements with ECHO before a production rollout.

05 / SECURITY INQUIRIES

Start with the concern.

For a security question, deployment review, or suspected vulnerability, use ECHO’s contact page. Share a brief description and a way to reach you; ask to arrange an appropriate channel before sending sensitive details.

Contact ECHO about security

Keep passwords, access tokens, customer records, and sensitive exploit details out of the initial message.