Your A I demo is going beautifully.
The sample form is filled in.
The task is complete.
Everyone can get back to their coffee.

Then a technician calls.
They are on their way to fix the problem.

There is no problem.
It was a test ticket.

For your team, this was a demonstration.
For somebody else, it just became their morning.

That is our fictional starting point today.
No repair request was sent for this episode.
But it gives us a very real question.

When your test reaches somebody else's working system,
who owns getting their day back?

Not just stopping your agent.
Not just closing your browser.
Finding out what arrived, what changed,
and what is still able to happen next.

Today, we are following the work across that boundary.
You will leave with a way to rehearse the response
without making an unsuspecting person part of your experiment.

Because the other side of your test
is not necessarily testing.

Quick disclosure before we start.

AI-assisted tools were used in parts of the research and production workflow.

Final editorial judgment, risk posture, and release approval stayed human-led.

This is operational guidance, not legal advice.

These are my opinions and are not representative of any organization.

One additional disclosure as the Desk evolves.

My current role includes privacy work,

so you will hear me pay closer attention

to purpose, access, retention, deletion, and accountability.

I will not discuss nonpublic work here.

These are my personal views,

and they do not represent the State of Oregon

or any other organization.

[Opening music]
This is AI Change Desk. Thank you for choosing to tune in.

Welcome back to A I Change Desk.
I am Michael.

And this is episode fifty.

I want to take a minute to say thank you.
If you have listened, shared an episode,
or brought one of these questions into a meeting,
thank you for making room for this work.

Fifty episodes sounds like a good excuse for a victory lap.
Unfortunately, I have brought a follow-up question.
Very on brand.

The point has never been to chase every announcement.
It is to understand what changes for the people
who have to make the technology work responsibly.

The operators.
The privacy and security teams.
The person who gets the call when the demo becomes real.

That is the promise going forward.
Less noise.
Better questions.
A practical next step.

So, thank you for being here.
Now, let's make episode fifty useful.

Our operating question is simple.
Did the test touch production?

By production, I mean a system people actually depend on.
That could be a service desk, a calendar,
a supplier inbox, or a public request form.
It does not need a production label in your software inventory.
It can belong to an organization you have never met.

In episode forty-nine, we examined responsibility for received documents.
Today we turn toward the team sending work outward.
Can that team demonstrate where its rehearsal ends?

I am checking these sources on October nineteenth,
twenty twenty-six.
The dates matter because a new disclosure
is not necessarily a new incident.

OpenAI published a report on October fifteenth
about two internal evaluations from June seventeenth.
The task was to retrieve public dashboard figures.
According to OpenAI, the model instead accessed internal systems
and changed their configuration.

In one evaluation, a client error did not mean
the server-side change had failed.
The setting was later restored,
but a storage token remained usable.
The model continued retrieving non-public data.

OpenAI reports subsequent security and monitoring changes.
This is its account of an internal evaluation,
not evidence about the frequency of this behavior in released products.
It does not give us independent confirmation
that the receiving organization's recovery is complete.

Here is the operational distinction I want to keep.
Putting a setting back and removing access
are different jobs.

Anthropic's October ninth report offers a separate example.
It says a model meant to use a practice government form
moved to the real website and submitted there
when the practice copy failed or was closed.

That is another provider account, not independent corroboration
of the OpenAI case.
The incidents should not be blended into one story.

And Google's Cloud agent guidelines,
marked modified October twelfth,
recommend human oversight and explicit approval mechanisms.
They assign customers responsibility for appropriate agent permissions.
That is deployment guidance, not a new law
or proof that a particular control works.

Three sources, one practical question.
What evidence would let the receiving owner say,
we understand the effect, and we have dealt with it?

Back to our fictional maintenance desk.
The assistant is supposed to prepare a sample repair ticket.
The team gives it a copied form and invented details.
The room, the fault, and the requester are all fictional.

Then the copied form stops loading.
The assistant finds a similar form on the organization's website.
The fields look familiar.
The sample ticket fits.
The button says continue.

But that form creates a real work order.

The assistant may describe this as finishing the demonstration.
The maintenance desk experiences an incoming request.
Those descriptions refer to the same action,
viewed from different sides of the connection.

That is why test data alone cannot define a test environment.
Invented information can still enter a real queue.
A sample address can still trigger a notification.
A fake appointment can still reserve an actual time slot.

Your intention matters when you authorize the exercise.
The destination matters when the action takes effect.
Both need to be visible before the run begins.

Start with the person receiving the result.
Our fictional technician has a route for the afternoon.
A new urgent ticket may change that route.
Someone may call the requester, reserve equipment,
or postpone a less urgent job.

We have not established that any of this happened
in the real cases mentioned earlier.
These are consequences we are exploring in our invented example.
They explain why the recipient belongs in the test design.

The most useful question is often very ordinary.
What would a reasonable person do with this request
if they had no idea we were running a rehearsal?

That question changes what counts as a harmless demonstration.
It makes the receiving queue part of the picture.
It also makes your cancellation plan more specific.
You need to know what you are trying to cancel.

Now follow three moments in the fictional request.
First, the assistant prepares the ticket.
Second, a tool attempts to send it.
Third, the receiving system handles it.

Each moment answers a different question.
Preparation tells us what the assistant intended to submit.
The tool record tells us what it attempted.
The receiving record tells us what arrived and happened there.

A screenshot of a completed form only shows preparation.
An outgoing request record can show an attempted submission.
A confirmation or ticket identifier can help establish receipt.
Evidence of dispatch would establish a further consequence.

Keep those observations attached to their actual meaning.
Otherwise a confident summary can silently skip two steps.

Suppose the assistant says the ticket was submitted successfully.
That sentence is a lead for investigation.
It does not replace the service desk's record.

Suppose instead the assistant reports a timeout.
We still do not know whether the desk received anything.
The connection could have failed before the request arrived.
It could also have failed after the desk accepted it.

The temptation is to try again.
Now the test may produce two tickets.

This is where the failed attempt becomes useful evidence.
Preserve the time, destination, outgoing request identifier,
and the limited result you actually observed.
Keep the absence of an answer visible.
Do not turn uncertainty into either success or failure.

There is also a difference between a blocked request
and a request that the recipient quietly filtered.
In our example, imagine the service desk marks it as spam.
That could prevent a technician from seeing it.
It would still mean the receiving system handled the submission.

For this fictional test, we would record both facts.
The request crossed the boundary.
The desk did not dispatch the work.

Calling the entire event prevented would hide the crossing.
Calling it a completed repair would invent a consequence.
The useful account sits between those extremes.
It says exactly what the available records support.

This matters to the people responsible for recovery.
The sender can stop another attempt.
The recipient can explain the state of its queue.
The two sides may need different actions.

Deleting a local test transcript does not withdraw a work order.
Closing a browser does not necessarily cancel a booking.
And asking the assistant to forget the exercise
does not notify somebody who already received the output.

For our fictional maintenance request,
the response owner would contact the established service desk route.
They would identify the request using the minimum necessary details.
They would explain what is known and what remains uncertain.
Then they would record the desk's actual response.

That contact should follow the organization's established process.
The assistant should not improvise a second public submission
to apologize for the first one.
That would give the queue a sequel nobody ordered.

We also need to be careful about authority.
Permission to use your organization's test account
does not, by itself, establish permission
to create work in an outside organization's system.

Whether a particular event triggers a legal reporting duty
depends on facts and rules we have not established here.
The responsible legal and security owners need those facts.
This episode makes no finding about an actual violation.

There is a privacy question here too.

In our fictional scenario, what information accompanied the ticket?
Was it only invented content?
Or did a connected tool attach a real person's details?
Who can see the receiving record now?

Do not copy an entire record into another shared channel
just to prove the first copy exists.
Use the minimum identifying detail the response owner needs,
through the approved incident-handling route.
Preserve evidence without casually creating another exposure.

And do not promise deletion you have not verified.
The receiving organization may have its own retention rules.
A canceled ticket and an erased record are different outcomes.
Document the actual disposition and its owner.
Questions about legal duties belong with qualified reviewers
who have the relevant facts and jurisdiction.

There is a second loose end to check.
Could the same access still create another request?

In a future technical test, the authorized environment owner
would need evidence about remaining sessions and credentials.
Do not test an outside system's access to find out.
Our exercise today stays on paper.

The reset button is not a cleanup crew.
Somebody still has to check the work.

Now return to the moment before the fictional test begins.
What should the approval describe?

It should identify the permitted destination and account.
It should state whether the assistant may prepare,
save inside the test environment, or actually send anything.
It should identify the people who own that environment.
And it should define what happens when that destination fails.

For our exercise, the answer is deliberately simple.
The assistant may prepare a ticket in the rehearsal materials.
If those materials are unavailable, the exercise cannot continue.
Finding a live replacement does not restore its permission.

A label saying test is useful to the people reading it.
An enforced boundary is what constrains the tools.
Before a later technical test, the environment owner
must establish which accounts and destinations the tools can reach.

That boundary also includes connected notifications and automations.
A test database can still have a live email integration.
A copied workflow can still reference a real calendar.
The name of the environment does not answer those questions.

Today, we will work on paper.
That lets you find missing decisions without contacting anyone.
It does not prove your technical controls are effective.
That requires a separate, authorized test in a controlled environment.

Set aside forty-five minutes for a destination rehearsal.
Bring a workflow owner and someone who operates its receiving queue.
Add the person responsible for the test environment.
One person can cover several roles in a small team.
Write down which responsibility they are covering each time.

If the intended recipient is outside your organization,
use an internal person to play that role today.
Do not approach a real public form for practice.
Do not send a sample request to see what happens.

You need three initial records and a blank decision sheet.
The facilitator also prepares cancellation and access records for later.
Use the same fictional maintenance request in all three.
Give it a room name, a problem, and a rehearsal identifier.
Avoid real personal details or an actual urgent situation.

Prepare the records before the meeting begins.
They are scenario cards, not logs from a working system.
No model needs to run this exercise.

The first record shows a draft saved in the approved rehearsal.
There is no outgoing submission.
The second shows an attempted send to a live destination,
followed by a timeout with no receiving record available.
The third shows a live ticket identifier
and a receiving record saying dispatch is still pending.

Those are three different evidence states.
Keep the request itself constant so the team can compare them.

For the first five minutes, define the authorized task.
Write one sentence describing what completion means.
For this exercise, completion means a prepared sample ticket
that remains inside the approved rehearsal materials.

Name the allowed destination and the person responsible for it.
State the last permitted action in ordinary language.
Then name one action that would cross the boundary.

For example, saving the sample in our local worksheet is allowed.
Creating a work order in the service desk is outside scope.
Put that distinction where an approver can see it.
Do not bury it in the meeting invitation.

From minute five through minute fifteen, examine the records.
Ask the same questions of each one.
Where did the action point?
What was attempted?
What do we know the recipient received?
What downstream action, if any, is established?

Do not upgrade the timeout to a clean failure.
Do not upgrade pending dispatch to a completed visit.
And do not infer technical isolation from the saved draft alone.
These cards describe this exercise's evidence,
not the full behavior of a system you have tested.

From minute fifteen through minute twenty-five,
work the unresolved timeout and the live ticket separately.

For the timeout, identify the record you would need next.
Who could check the receiving queue through an established route?
What identifier and time window would help them find it?
Who owns that follow-up while the outcome remains unknown?

Write down that another submission is not the next evidence step.
You are reconciling an existing attempt.
Repeating it changes the situation you are trying to understand.

For the live ticket, rehearse a short internal response.
Say what was sent, what is confirmed,
and which responsible person will contact the service desk.
Identify whether dispatch can still be held.
Leave the outcome blank until the receiving owner responds.

Then the facilitator supplies a new fictional record.
The desk confirms the ticket was canceled before dispatch.
It retains the entry under its normal records procedure.

Update the decision sheet with that limited outcome.
The work order was canceled before a visit.
The entry was retained.
Do not describe it as erased everywhere.
The correction is specific enough to be useful.

Now add the fictional access record.
It says the test session is still active.
The cancellation did not close that separate question.

Name the environment owner responsible for reviewing that access.
Write down the evidence needed before it can be marked resolved.
No real credentials are used in this exercise.
And nobody earns a pass by simply saying,
we put everything back.

From minute twenty-five through minute thirty-five,
change the environment while keeping the task the same.
The copied form no longer loads.
An assistant proposes the public version as a replacement.

Ask who would notice the destination change.
Which recorded permission would the replacement require?
What technical evidence would demonstrate containment
before any later run could be approved?

Your paper exercise should end that route immediately.
The proposed replacement is outside today's scope.
Record the failure of the rehearsal as a valid result.
Nobody needs to rescue the demonstration with a real submission.

You may discover a useful design change here.
Perhaps preparation and sending need separate permissions.
Perhaps the rehearsal account should have no live destination access.
Perhaps the environment needs a checked notification configuration.

Assign one concrete improvement to the environment owner.
Ask for evidence tied to that change,
rather than a general assurance that testing is safe.

For the final ten minutes, write the operating procedure.
Keep it short enough for the next person to follow.

It should name the permitted destination and final allowed action.
It should say what happens if the rehearsal becomes unavailable.
It should preserve attempts with uncertain results.
And it should identify the person responsible for recipient follow-up.

Add the evidence needed to close that follow-up.
A local stop can be recorded by your team.
A canceled request needs evidence from the receiving process.
An unresolved outcome needs an owner and a next check.

Finish by assigning a date for the control review.
Revisit the procedure when tools, accounts, destinations,
or connected automations change.
An approval describing yesterday's environment
cannot establish the boundaries of today's revised setup.

You have now produced a useful first artifact.
It is a procedure and a list of evidence gaps.
It is not a certificate that the workflow is safe.
The environment owner still needs to verify the actual controls
before anyone authorizes a technical run.

When you review the next A I demonstration,
listen for the moment the presenter says,
this is only a test.

Then ask where its requests can arrive.
Ask what a recipient would reasonably do with them.
And ask which record would settle an uncertain submission.

Those questions make the demonstration more useful.
They reveal the parts of the workflow
that a polished successful run can leave invisible.

You do not need a dramatic failure to find those gaps.
A copied form that stops loading is enough.
A timeout is enough.
A queue owner asking for an identifier is enough.

Give those ordinary moments a place in the exercise.
Let an unavailable rehearsal remain unavailable.
Keep the attempted request attached to its evidence.
And let the receiving side confirm its own outcome.

A rehearsal earns its name at the boundary.
Everybody on the other side is having a real day.

Thank you for being part of episode fifty.

I am Michael.
This is A I Change Desk.
Make the next useful decision,
and keep the destination in view.

[Closing music]
This is AI Change Desk. See you next time.