Skip to main content
VoicePing distinguishes authentication, which checks who is using the service, from authorization, which checks whether that person or service may access particular data or perform an operation. Permissions are checked on the server as well as reflected in the interface. Updated October 21, 2026. These are representative controls; internal API inventories, detection conditions and limits are not published. See the security overview for the policy and questionnaire. 日本語版.

​
Accounts, sign-in and recovery

Accounts are managed per user. Standard password registration includes email verification. Verification codes have expiry, attempt and resend limits to prevent reuse and repeated guessing. Users can change passwords in account settings, or use password recovery when they cannot sign in. Reset links have a limited lifetime and purpose and cannot be reused after completion. Completing a reset invalidates existing sessions. A reset does not bypass outstanding identity verification or additional authentication requirements.
Identity and membership checks before sign-in, and expiry and prior-use checks before resetting a password and revoking existing sessions

Representative authentication and account-recovery flows.

For SSO and Google or Apple sign-in, the server validates the received authentication information. Additional email verification or multifactor authentication depends on the sign-in method and organization settings. See SSO configuration. When a member leaves or changes roles, administrators update membership and roles and remove unnecessary access. They also review user-bound API keys, connected integrations and shared organization keys.

​
Authorization by endpoint type

An endpoint is an API or connection that receives requests from an application or external system. Authentication and permission checks depend on its purpose.
Requests pass authentication and authorization checks before the permitted operation; requests that fail either check are rejected

Identity and data permissions are checked according to the endpoint's purpose.

​
Organization and data separation

Data is logically separated by workspace. Checks consider membership, role, ownership and visibility. Meetings, transcripts, summaries, invoices and time-tracking records each have their own access conditions. Administrator status does not grant unrestricted access to all private data. Download URLs for recordings and attachments are issued after checking access to the underlying resource.
Membership, role and visibility checks allow access to authorized organization data and reject unauthorized access across organizations

Organizations and resources have separate permission checks within the same service.

​
Invitations, guests and meeting access

Invitations use hard-to-guess tokens. New invitation tokens are stored as hashes, have an expiry and are replaced when resent. Enterprise manual invitations also check the operator’s permissions, email/domain and plan conditions. Guests can join only the workspaces or meetings they are allowed to access. Media tokens are issued after checking participation rights, with publishing and receiving permissions set for the intended use.
Validate the invitation and entry conditions, issue a media token with required permissions, then join the meeting

Invitation and meeting permissions are checked before issuing the required media permissions.

Rotating an invitation link and removing a guest who has already connected are separate actions. Revocation must consider both links and existing connections.

​
APIs, AI tools and processing workers

The secret portion of an external API key is stored as a hash. Scopes define allowed operations, and configured source-IP conditions can restrict use. User-bound keys are distinguished from shared organization keys. MCP integrations for AI tools use OAuth authorization and PKCE to protect authorization-code exchange. Operations check current membership and data permissions as well as scopes.
API and MCP access checks scopes and data permissions; processing workers check caller identity and job assignment before updating results

Integrations and internal processing check the relationship between credentials and the requested operation.

Workers verify their assigned job before updating its result. Where a configuration uses shared credentials, worker identification alone cannot fully contain the impact of those credentials being compromised.

​
Defenses against web application attacks

Input, permissions, processing and output are checked separately. The following summarizes implementations and areas subject to continued review.
Validate input, check permissions, process safely and limit display, response and log output

Input validation and authorization are combined with controlled processing and output.

​
Command-injection defenses

Command injection occurs when input is interpreted as an operating-system instruction and triggers unintended execution. The key control is to separate the program and operation to execute from data supplied by the user.
Check input types, ranges and permissions, separate executable instructions from data, and pass validated input to restricted processing

Examples of checks between external input and execution. Implementation and isolation coverage vary by feature.

Separate arguments are not sufficient if a value becomes an unsafe option, arbitrary destination or external-file reference. File names, paths, URLs and settings must also be checked against the permitted scope of the operation. Tests check both rejection of invalid values before execution and acceptance of legitimate input such as Japanese file names. Request limits and suspicious-request detection provide additional controls; they do not replace safe input handling.

​
File validation and parser boundaries

A file cannot be trusted solely from its name or declared type. Additional checks for media used in subtitles and document processing examine the actual data, storage reference and reading method.
Validate file format, size and storage references, then restrict parser selection, external references and processing resources

Media/document validation and isolated SAML/collaborative-data parsing apply to different processing paths.

At the October 21, 2026 review, additional upload controls were at different rollout stages across services; some had reached testing environments only. Further path, URL and configuration validation remains in progress. A matching file format does not prove the absence of malware, and these examples do not mean identical checks or isolation are deployed on every upload path. See software supply-chain review for controls addressing malicious code within packages or models themselves.

​
Request limits and records

Excessive requests are subject to count or volume limits according to the IP address, signed-in user or feature. Sign-in, verification-code resends and guest access have controls tailored to abuse risk. Reaching a limit restricts requests but does not by itself identify the user as an attacker. The infrastructure guide explains detection and blocking. Deletion checks ownership and storage destinations so retries do not delete another user’s data. Logs are limited to information needed for investigation, minimizing content and credentials. Hashing an identifier alone is not treated as anonymization.
If you have any questions, please contact us via this form.

Official Links

Official Website

Visit our official website

X (Twitter)

Follow us on X

Facebook

Like us on Facebook

LinkedIn

Connect on LinkedIn