On September 18, 2026, OpenAI announced multi-account support across most ChatGPT plugins. A user can bring work and personal connections into the same conversation. That creates a specific security review: which account supplies the data, which account performs the next action, and is that transfer allowed?
OpenAI's authentication documentation says the model selects among connected accounts and each call uses the selected connection's credentials. A correctly authenticated write can still put work data in a personal account.
Consider a hypothetical document plugin with a work connection and a personal connection. Reading a work file and creating a personal file could each pass their own authorization checks. Copying confidential work content between them could still violate company policy. This guide gives plugin engineers and administrators a way to review that gap. It is a proposed acceptance procedure, not a report of a vulnerability or a tenant integration test by General Analysis.
Define the permitted workflow before connecting accounts#
Start with a specific task: an employee searches two approved client workspaces, then drafts a response in one named workspace. Record the permitted sources and destination. If policy forbids combining those clients' information, do not approve a workflow that gives the agent both sources and relies on a prompt to keep them separate.
In OpenAI's workspace controls, plugin availability, MCP access, action settings, and source-service permissions are separate decisions. An administrator can make a plugin available without granting access to its underlying records. Where supported, Action control limits available actions, while App permissions governs when ChatGPT asks before using the connection.
For the pilot, record each connected account's owner, allowed resources, read/write scope, and permitted destination. Begin with read access. Enable a write only after the team can identify its target and recover from an incorrect result. Check the actual plugin and workspace: the announcement covers most plugins, and it does not establish identical availability or controls everywhere.
Shared connections need their own review. ChatGPT Work cloud security documents that shared or agent-owned connections use their connected account's permissions, which can exceed the requester's personal access. An employee's role is therefore insufficient evidence of the authority behind a tool call.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Make identity reliable, then check the other tools#
For a plugin you maintain, follow OpenAI's profile-tool contract: expose an authenticated read-only tool, accept an empty argument object, derive identity from validated credentials, and mark it with _meta["openai/profile"]: true. Return the required profile shape in structuredContent and its matching serialized text representation.
Use a persisted opaque ID. It must survive reconnection, token refresh, and display-name changes while remaining distinct from other independently connected profiles. An email address is display metadata. The official reference includes the declaration, response schema, handler example, and identity checks; use those directly rather than inventing an account selector.
A correct profile handler does not prove that search, fetch, and write handlers use the same identity. Inspect their authorization paths. Each must resolve its own request's authority. Look for a process-wide "current account," a shared cache keyed only by document ID, or a retry that silently tries another credential. These are review targets for your implementation, not claims about OpenAI's implementation. Our MCP server security guide covers the surrounding authorization threat model.
Follow one result through to its destination#
Use two authorized test accounts with harmless fixtures that are easy to distinguish. For example, put a document titled Release checklist in each, with different dummy contents. This makes an incorrect selection visible without exposing real client information.
The following cases extend the official profile checks into workflow behavior. They are proposed acceptance criteria; adapt them to your service's resource and permission model.
| Review case | Evidence to retain | Acceptance decision |
|---|---|---|
| Search the same title through each account | Authenticated identity, returned resource IDs, and source account | Each result belongs to resources that the selected identity may read. |
| Fetch a result after the requested account changes | Original result provenance and the fetch request's identity | The service reauthorizes the resource; it does not trust a previous lookup. |
| Repeat a query with cached results | Cache namespace, current identity, and authorization outcome | A cache hit cannot substitute another account's data or stale access decision. |
| Approve a draft, then change its destination | Approved destination, executing identity, and downstream receipt | The changed target requires a new decision under the workflow's approval policy. |
| Remove one account's access | Revocation time, subsequent request result, and remaining connection identity | Failed access does not silently fall back to the other account. |
| Intentionally combine information from both accounts | Approved source/destination policy and the final artifact's location | Both reads and the information transfer are permitted. |
For HTTP MCP token handling, the July 28, 2026 authorization reference requires validation of tokens intended for the server and authorization on every request. Keep those checks in front of cached responses. Identity stability does not mean authorization is permanent: a profile can keep its ID while losing access to a resource.
A server can enforce both accounts' permissions and still participate in a prohibited transfer. Review the destination before enabling that workflow. The Supabase MCP research illustrates the related distinction between permission to read data and permission to disclose it; it is a separate historical setup, not a test of this feature.
Keep an evidence record that names both sides#
For a service you control, record the authenticated profile, operation, resource, and outcome at the enforcement point. Add the approved destination for writes. Link the decision to the downstream service's receipt so an investigator can distinguish a proposed action from a completed one. Avoid access tokens and document contents in routine logs.
This illustrative record describes a deliberately blocked transfer of dummy data. The identifiers and fields are invented for the example; this is not an OpenAI event schema or a captured result.
Code source: illustrative.
{
"review_case": "work-source-to-personal-destination",
"source": {
"profile_id": "prf_work_fixture",
"resource_id": "doc_fixture_17"
},
"destination": {
"profile_id": "prf_personal_fixture",
"resource_id": "folder_fixture_9"
},
"operation": "create_document",
"transfer_policy": "work-content-stays-in-work",
"decision": "deny",
"executed": false,
"downstream_receipt": null
}
Treat this record as a review specification. An implementation needs trusted provenance and a policy check before execution to produce it honestly. The model repeating a source label cannot establish where the data came from. If your integration cannot enforce the transfer rule, restrict its connected resources or write capabilities until a suitable control exists.
When you use a vendor-managed plugin, ask for the equivalent account and action evidence available from that service. Do not assume that ChatGPT's transcript exposes its internal connection IDs, caches, or every enforcement decision.
Contain an incorrect action at the source and destination#
If an action uses the wrong account, stop the affected workflow and preserve its account, resource, time, and downstream outcome. Restrict the connection or source-service grant that supplied the authority. Review whether the destination artifact needs removal or access changes under the organization's incident procedure.
Disconnecting an account does not establish that already-copied information has disappeared. OpenAI's cloud data-handling guidance distinguishes retrieved content from copies saved in conversations, projects, Library, or synced indexes. A file written into another service also needs review in that service.
Re-enable the workflow once the team can explain the source, destination, and authorization decision for the disputed action. If the evidence stops at "the plugin was enabled," keep the affected write capability restricted.
Frequently asked questions
- Does connecting two plugin accounts isolate their information?
It gives tool calls distinct authenticated connections. OpenAI documents that connected accounts are available to the model. Separate credentials do not establish a rule preventing information read through one account from being used in an action through another. Define that policy and verify the controls for the intended workflow.
- Does an openai/profile tool enable multi-account support?
No. The profile tool helps identify and label connected accounts. Users can connect accounts without it. A declared tool must return a valid, stable identity derived from the request's credentials; the marker does not grant access or establish feature eligibility.
