ChatGPT Voice can now use plugins and connected apps. Pilot it safely with clear permissions, confirmation points, test cases and a rollback plan.
8 min readVerified September 28, 2026
ChatGPT Voice can now work with the plugins and connected apps available to your account. The useful change is speed: you can ask for information or start work without stopping to type. The important control has not changed. A voice interface does not create a new permission boundary.
Before using Voice with email, calendars, documents or business tools, run one small pilot. Limit it to one app, one reversible outcome and one visible confirmation point. You should know what data may be read, what action may be taken and how you will check the result.
OpenAI announced plugin support for Live voice on web, iOS and Android on September 23, 2026. It also made Voice available in ChatGPT Work on web and mobile. Availability still depends on your plan, workspace settings, installed plugins and connected accounts. Verify the current controls in your own account before relying on any workflow.
What changed, and what did not
The September update lets a Voice conversation use plugins and connected apps that are already available to the account. Written responses remain visible in the chat, and unfinished Work tasks may continue in text after a voice call ends.
That does not mean every plugin can perform every action by voice. It does not expand the permissions granted by the connected service. It also does not replace workspace policy, account-level access controls or a human review step.
Treat Voice as another way to issue instructions. The connected app, its permissions and the surrounding workflow still determine what can happen.
Choose the right authority level
Use the lowest authority that can produce the result.
Read
The assistant retrieves approved information and reports it back. Examples include summarizing tomorrow's calendar or finding a document the user is already permitted to access.
Start here. Keep the source narrow and avoid sensitive material during the first test.
Draft
The assistant prepares an output but does not send, publish or change the source system. Examples include drafting a meeting agenda or composing a reply for review.
Drafting is a useful second step because the result can be inspected before anything leaves the conversation.
Act
The assistant creates, sends, books, modifies, deletes, pays or publishes through a connected service.
Use this level only when the exact action is supported, the correct account is visible, the result can be previewed, and a human confirmation is required at the right moment. If the current product does not show an adequate review step, stop at Draft.
A practical authority matrix
This NEXAIUM decision aid is not an OpenAI policy table. It helps you choose a safe starting level.
Read, Draft, Act: a NEXAIUM decision aid, not an OpenAI policy table
Level
Voice may do
Permission boundary
Human checkpoint
Evidence to keep
Rollback expectation
Read
Voice may doRetrieve approved, low-sensitivity context
Permission boundaryOne named app and account
Human checkpointConfirm source and scope before retrieval
Evidence to keepRequest, source used, summary
Rollback expectationDisconnect or narrow access
Draft
Voice may doPrepare an agenda, reply or task plan
Permission boundaryRead access plus a defined output format
Human checkpointReview the full draft before use
Evidence to keepInput, draft and reviewer decision
Rollback expectationDiscard or revise the draft
Act
Voice may doCreate or change an external record
Permission boundaryOnly the precise write action required
Human checkpointPreview and explicitly confirm the final action
Evidence to keepFinal parameters, confirmation and observed result
Rollback expectationDefined reversal or manual recovery
The practical takeaway is simple: move from Read to Draft before considering Act. Increase authority only after the lower level works reliably on normal and difficult cases.
Run the SAFE voice pilot
S: Scope one job and one app
Write one sentence that defines the task and its boundary.
Example: "Read tomorrow's approved work calendar and draft a 5-item agenda. Do not create, edit or send anything."
Avoid goals such as "manage my day" or "handle my inbox." They hide too many decisions inside one instruction.
A: Audit data and permissions
Check which account is connected, which records it can access and which actions the plugin supports. Use the least access that can complete the pilot.
Do not test with confidential client data, private HR records, financial details, health information, authentication secrets or material you are not authorized to expose.
F: Force a visible confirmation
Decide where the workflow must stop for review. For a Read task, confirm the source and time range. For a Draft task, inspect the complete draft. For an Act task, review the destination, payload and consequences on screen before approving.
OpenAI's current Voice documentation says that actions requiring approval must be reviewed with on-screen controls on web and mobile. Spoken approval is not supported. This does not mean every app action automatically requires approval. For this pilot, if you cannot enforce a visible checkpoint, keep the work at Read or Draft.
E: Evaluate expected and difficult cases
Run at least 4 tests:
A normal request with complete information.
An ambiguous request, such as "move the afternoon meeting," when several meetings match.
A restricted request involving private information or an unauthorized account.
A tool-failure case, such as a missing permission or unavailable app.
The pilot passes only if the assistant asks for clarification when needed, respects the boundary and leaves a result you can verify.
A 15-minute example pilot
The following example is illustrative. It is not a claim about a particular account, plugin or result.
Maya wants a hands-free summary before her commute. She connects one approved work calendar and defines a Read-and-Draft task: summarize tomorrow's meetings and draft an agenda. The assistant may not edit events, invite attendees or send messages.
She tests 4 cases:
A normal day with 3 meetings.
Two events with similar names.
A private event whose details should not be repeated aloud in a shared space.
A request made while the wrong calendar account is selected.
Maya compares the spoken summary with the calendar, reviews the written agenda and records each mismatch. When the account is unclear, the correct result is a question, not a guess. She keeps the workflow at Draft because no external action is necessary.
Voice-specific failure modes
Use the following as test cases, not claims that every Voice session will encounter these failures.
Names and dates can be misheard. State exact names, dates and time zones, then compare the written result with the source. Voice transcripts are not verbatim records.
Background speech can alter context. Pause in shared or noisy spaces.
The wrong account may be connected. Name and inspect the account before retrieval.
The screen may not be visible. Do not approve consequential work when you cannot review the exact action.
A follow-up may be ambiguous. Restate the target, time range and desired output.
Private information may be spoken aloud. Use headphones or switch to text in public spaces.
A tool may fail silently or partially. Compare the result with the source and record what was not completed.
A voice call may not leave enough evidence. Use the written chat and a short pilot record.
Stop conditions
Stop the workflow and switch to a safer process when:
You are in a shared or public space and cannot keep the pilot private.
You cannot confirm which account or app will be used.
The task involves sensitive personal, client or regulated data without an approved policy.
The action cannot be previewed before it affects another system or person.
The change is irreversible or has no tested recovery path.
The request involves a financial, legal, HR or medical decision.
The instruction remains ambiguous after one clarification.
The written record does not show what data was used or what action occurred.
Keep a short pilot record
Copy this template into a note or operating document:
Copy-ready block
Voice pilot date:
Owner:
Requested task:
Connected app and account:
Data allowed:
Data excluded:
Authority level: Read / Draft / Act
Tool used and data actually touched:
Human confirmation point:
Confirmation shown and reviewer decision:
Test cases:
Expected result:
Observed result:
Tool or permission failures:
Rollback method:
Decision: stop / revise / expand
Do not paste passwords, API keys, session tokens or private message content into the record.
Final checklist
One outcome and one connected app are named.
The correct account is visible.
Data boundaries are written down.
Permissions match the task.
The authority level is Read, Draft or Act.
A visible confirmation point exists for consequential actions.
Normal, ambiguous, restricted and failure cases were tested.
The written result was compared with the source.
A rollback or manual fallback is defined.
The pilot record contains no secrets.
What remains time-sensitive
Live currently does not support video or screen sharing. Voice in Work needs both Voice and Work access. Treat the 15-minute plan as an initial test, not a promise that setup or recovery will finish within that time.
Plugin availability, supported actions, approval behavior, plan access and interface labels can change. This article does not assume that every account has the same plugins or that every action can be completed through Voice. Check the current OpenAI documentation and the details shown in your own plugin settings before expanding a workflow.
The Read-level rollback means stopping future access. It cannot undo data already retrieved or spoken. Disconnecting an app is not a claim that prior chat content has been deleted.