OpenAI Presence Arrived. Decide Who Can Change the Agent.

OpenAI introduced Presence on 22 July 2026 as a managed enterprise product for voice and chat agents. It is available only to eligible enterprise customers through limited general availability, with deployments led by OpenAI Forward Deployed Engineers, selected systems integrators or both. It is not self-service (OpenAI).

The important change is not another way to build an agent. It is a continuing service model. OpenAI says production sessions, escalations and quality signals can reveal gaps, Codex using the Presence plugin can investigate those signals and suggest updates, and teams can test proposed changes before approving a controlled rollout (OpenAI).

That creates a clean governance question for Australian banks, insurers and superannuation funds: who is authorised to change the system that defines what the agent can do? Runtime approvals control what an agent may do now. Change authority controls who can redefine that boundary tomorrow.

What did OpenAI actually launch?

OpenAI describes Presence as a managed platform for building, deploying, operating and continuously improving agents for high-volume, high-stakes workflows. During limited general availability, it supports conversational voice and chat. Exact channels, integrations, models, capacity, pricing, service commitments and data arrangements are settled for each deployment (OpenAI Help Centre).

A Presence agent can be configured to follow approved instructions and procedures, use approved knowledge, connect to business systems with scoped permissions, complete approved actions and escalate when human judgement is required. OpenAI says a typical managed process includes scoping, system connections, policy and permission design, security and privacy review, simulations, acceptance testing, controlled rollout and continuing improvement. It also says ingesting documents alone does not make an agent production-ready (OpenAI Help Centre).

Those are product descriptions, not independent assurance. The public documentation says controls can include simulations, evaluations, guardrails, approval steps, session records, action histories, controlled rollout, monitoring and rollback, depending on the deployment (OpenAI Help Centre). Your signed architecture, contract and operating procedures determine what your deployment actually includes.

The same caution applies to customer examples. OpenAI says IAG is exploring support during high-demand events such as severe weather. That is an Australian signal, not evidence of a production deployment. BBVA is described as exploring voice support in Mexico, while SoftBank is testing Japanese-language conversations (OpenAI).

Presence is also separate from ChatGPT Workspace Agents. OpenAI says Presence agents are scoped and deployed with its engineers, a selected partner or both, and are not created through the Workspace Agent interface (OpenAI Help Centre). Do not import Workspace Agent controls, standard ChatGPT terms or API assumptions into a Presence assessment. Assess it the way you would assess any software bought for agents to operate: on the signed documents, not the demonstration.

Who can change the agent after launch?

OpenAI's announcement says the customer sets policies about what an agent may do, when approval is required and when a person takes over. It also says OpenAI works alongside the customer to connect systems, establish permissions and policies, test the agent and move it into production. Selected integrators can continue supporting the deployment as it expands (OpenAI).

The public material does not allocate every production authority. It does not tell your organisation which named role may accept a changed escalation threshold, alter an evaluation pass mark, deploy a new tool permission or invoke an emergency rollback (OpenAI, OpenAI Help Centre). That is not evidence that the supplier has unilateral authority. It is evidence that the allocation belongs in the deployment documents.

The two controls are easy to conflate and worth separating explicitly:

Use a Change Authority Ledger. It is more precise than a generic responsibility matrix because it connects each authority verb to a specific control object.

For every change family, name who may propose, prepare, test, accept, approve, deploy, pause and roll back:

1. Instructions and standard operating procedures.
2. Knowledge sources and retrieval settings.
3. Policies, guardrails and action constraints.
4. Evaluations, graders, cases and pass thresholds.
5. Tools, connectors and approved actions.
6. Permission scopes and authentication.
7. Escalation and human hand-off rules.
8. Model and reasoning configuration.
9. Channel, routing and customer verification.
10. Logging, masking, retention and storage settings.

Then record the evidence required at each stage, the segregation rule, the notification threshold and any emergency authority. A supplier engineer may be allowed to investigate a quality signal and prepare a change in a controlled environment. That does not have to include authority to accept the business behaviour or release it.

Use this prompt to draft the ledger from approved documents. A human product owner, security lead, legal or procurement reviewer must verify every assignment against the signed contract and access model.

Act as a change-control analyst. Use only the deployment scope, contract extracts and internal change policy supplied below.

Create one row for each change family:
instructions and procedures; knowledge sources; policies and guardrails; evaluations and thresholds; tools and actions; permissions; escalation and human hand-off; model configuration; channels and authentication; logging, masking, retention and storage.

Columns:
proposer; preparer; tester; business acceptor; control reviewer; approver; deployer; pause authority; rollback owner; required evidence; notification threshold; unresolved wording.

Do not infer authority. Mark missing assignments NOT SPECIFIED. Do not make an approval decision.

MATERIAL:
[PASTE APPROVED, DE-IDENTIFIED EXTRACTS]

For an APRA-regulated entity, this allocation can support existing operational-risk and service-provider controls under CPS 230. The current CPS 230 determination, in force from 1 July 2026, requires entities to manage service-provider risks, set clear roles and responsibilities, and address technology, data and change-management risk. Whether a specific Presence arrangement is a material service-provider arrangement remains an organisation-specific assessment (APRA CPS 230).

The practical point is narrower than a full CPS 230 assessment. If a managed agent supports customer enquiries, claims processing or another important operation, the entity still needs to know who can alter the operating boundary and who remains accountable for accepting that change.

What evidence belongs with each change?

Pair the authority ledger with an Agent Change Passport. The ledger defines who may act. The passport proves what one release changed and why it was allowed.

A useful passport records:

• agent ID, current version and proposed version;
• signal, incident, policy or business need that initiated the proposal;
• supplier, partner and internal people involved;
• configuration difference across instructions, tools, permissions, models, data and escalation;
• evaluation cases, thresholds, results and unresolved failures;
• security, privacy, legal and business reviews required by the ledger;
• named human acceptance and release decisions;
• rollout scope, monitoring window and stop conditions;
• last approved version, rollback test and rollback owner;
• links to the source evidence, with sensitive material kept in the approved system.

The passport should also identify apparently unchanged dependencies. A prompt change can interact with an existing tool permission. A new knowledge source can change the information passed to a human reviewer. A model configuration change can alter latency and escalation behaviour. "No code changed" is not a useful risk classification. Model lifecycle changes also arrive on the vendor's clock, which is why every model in the deployment needs a retirement date in your register.

Fictional worked example: [ORGANISATIONNAME] uses [AGENTID] to answer claim-status questions and collect information during a severe-weather event. The agent cannot decide coverage, entitlement, liability or settlement. Those decisions stay with [HUMANCLAIMSROLE].

Production evidence shows that one customer phrase is routed to the wrong support queue. The managed improvement process produces a proposed instruction and escalation-rule change. The supplier prepares the proposal and test results. [PRODUCTOWNER] confirms the intended customer behaviour, [CONTROLOWNER] reviews the escalation boundary, [RELEASEROLE] authorises deployment and [ROLLBACKOWNER] can restore [APPROVEDVERSION].

The supplier's expertise is useful. It is not self-approval. The passport shows who accepted the changed behaviour before it reached customers.

Use this prompt to test a proposed release. A human engineer and control owner must verify the source configurations, evaluation results and final disposition.

Compare [APPROVED_VERSION] with [PROPOSED_VERSION] using the de-identified configuration manifests, authority ledger and change ticket.

Return:
1. each changed instruction, policy, guardrail, tool, permission, escalation rule, model setting and data-handling setting
2. the authority required for each change
3. supplied and missing test evidence
4. conflicts or missing segregation
5. rollout, stop-condition and rollback readiness
6. questions that block release

Do not approve deployment. Cite the supplied field or clause supporting every finding.

[PASTE DE-IDENTIFIED MATERIAL]

OpenAI says data access, logging, masking, retention, storage location and access rights are defined and reviewed per deployment. It directs customers to their approved architecture, security documentation and contract as the definitive record (OpenAI Help Centre). Put those settings in the ledger. Do not assume a standard Australian location, retention period or access model.

Do this Monday

1. List the change objects. Map every instruction, source, tool, permission, evaluation, model setting, escalation rule, channel and data-handling control that can change after launch.
2. Extract the authority verbs. Read the contract, statement of work, privileged-access design and internal change policy. Record who may propose, prepare, test, accept, approve, deploy, pause and roll back.
3. Close every unnamed role. Assign a human business acceptor and release owner. Escalate any supplier or partner right that lacks a clear scope, evidence requirement or notification trigger.
4. Issue one change passport. Use a recent or fictional configuration change to test whether the team can show the difference, test evidence, approval, rollout limits and rollback target.
5. Run the reversal. In a controlled environment, prove that an authorised person can pause the agent and restore the last approved version. Record the result and repair any dependency on an unnamed individual.

Do not turn this into a blanket ban on supplier access. Managed expertise can shorten investigation and improve testing. The control is an explicit division of labour with retained human authority over acceptance, production release and rollback.

Bottom line

Presence makes continuing improvement part of the enterprise agent product. That is useful, but it turns change rights into production permissions. Attach those permissions to specific control objects, record each release in a change passport and keep human acceptance and deployment authority explicit. The agent can assist the work; accountable people decide its operating boundary.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. OpenAI, "Introducing OpenAI Presence": https://openai.com/index/introducing-openai-presence/
2. OpenAI Help Centre, "OpenAI Presence": https://help.openai.com/en/articles/20001405
3. APRA, "Prudential Standard CPS 230 Operational Risk Management": https://www.apra.gov.au/standards/cps-230