Always-On Agent Control Check

The new coworker does not need a chair. That is not the strange part. The strange part is that it might have a calendar. A memory. A desktop app. A browser. A way to reach SharePoint. A way to reach Teams.

A way to publish an internal site. And, if nobody is paying attention, a way to keep doing small helpful things after the meeting is over. Which sounds great. Until the small helpful thing is wrong. Or premature.

Or outside the process. Or technically allowed, but operationally insane. This is where the agent conversation changes. We are not only asking: can this thing answer a question? We are asking: can this thing keep acting when I am not looking?

And if it can, whose permission is it carrying? Welcome back to AI Change Desk. I am Michael. Today is Wednesday, June third, twenty twenty-six. This is episode thirty: Always-On Agent Control Check. 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 they are not representative of any organization.

I am source-checking this on Tuesday, June second, twenty twenty-six, and the timing matters. Microsoft just used Build week to push agents closer to the center of work. OpenAI just updated the Enterprise and Edu release notes with more internal app, plugin, session, and workspace-agent controls.

So tomorrow's brief is not about whether agents are coming. That argument is over. The useful question is smaller, and much more annoying. Who owns the standing permission? Because one-time approval is easy. Someone asks, can I use this tool?

You say yes, or pilot, or not yet, or please stop installing things from a comment thread. That is familiar governance. Not always fun. But familiar. Always-on agents are different. Microsoft described a new category called Autopilots: agents that stay active in the background, operate with their own identity, and act on your behalf under the permissions and policies you set.

Microsoft Scout is the first one they announced. The pitch is practical. It can coordinate meetings, spot schedule conflicts, prepare materials, block time for deliverables, and surface stalled decisions before they become blockers. That is not science fiction.

That is the part of office work that eats Tuesdays. And yes, I would like help with that. I am not anti-help. I am anti-mystery-help. There is a difference. Microsoft also says Scout is in private preview through Frontier, not broadly available to everybody.

Access requires Frontier enrollment, Intune policy configuration, and an opt-in attestation. That matters because the announcement is not simply: here is a fun assistant. It is: here is an agent with identity, credentials, access controls, policy enforcement, and human sign-off options.

That is not a chatbot. That is a work actor. And once something becomes a work actor, the operating model has to change. The question is no longer only: what model is underneath it? The question is: what account does it use?

What can it reach? What can it change? What requires human sign-off? What gets logged? What gets blocked? And who explains the action when the audit trail says, technically, the agent did it? That last phrase should make every manager sit up a little.

Not panic. Just sit up. Maybe put the coffee down. Not dramatically. Just enough to stop typing during the demo. The second signal is OpenAI's Enterprise and Edu release notes. On June second, OpenAI listed ChatGPT Sites in preview for eligible Enterprise and Edu workspaces.

The practical meaning is that users can ask Codex to create, iterate on, and deploy lightweight internal web apps. OpenAI says Sites is default off for Enterprise and Edu, and admins and owners manage enablement, access, and published sites through workspace settings.

That default-off detail is important. It is the sentence operators should underline. Because an internal app is not just content. It is a work surface. It may have a URL. It may have data. It may have sign-in.

It may have storage. It may become the place where a team starts doing the job. So if the governance question is only, can people use Codex, you are late. The better question is: can people publish an internal app, who can see it, what data can it store, who can disable it, and what happens when the prototype becomes the process?

Because that is the quiet failure mode. Nobody announces, we have replaced the workflow. They just say, use this little app for now. Then for now becomes Friday. Friday becomes next quarter. And suddenly the little app is holding together a business process with the emotional stability of a group chat named final final two.

I am not judging. I have seen the group chat. It has load-bearing emojis. This is where episode twenty-six and episode twenty-nine connect. Episode twenty-six asked: who owns the agent toolchain? Episode twenty-nine asked: what evidence proves agent work is reliable?

This episode adds the standing-permission layer. If the agent can stay active, publish surfaces, connect apps, or act under a governed identity, then the control is not just at launch. The control has to live with the thing.

Persistent agents need persistent ownership. Not vibes. Not enthusiasm. Not a pilot channel where everyone agrees it is probably fine. Ownership. Here is the practical check for tomorrow morning. Pick one agent, one internal app, or one automation that is close to acting on behalf of a person or team.

Do not inventory the whole company. That is how good governance becomes a calendar hostage situation. Pick one. Then answer seven questions. First: What identity does it use? A named user? A service account? A governed agent identity?

Something nobody wants to admit exists? Second: What can it reach? Email. Calendar. Files. Tickets. Code. Customer records. Financial records. Internal websites. Do not say connected systems. Name them. Third: What can it change? Reading is one risk.

Writing is another. Scheduling, publishing, deleting, approving, or messaging on behalf of someone are not the same action. Treat them differently. Fourth: What requires human sign-off? If the answer is, we trust the model, that is not a control.

That is a mood. Fifth: Where is the log? Can a manager, security owner, or process owner reconstruct what happened without interviewing six people and a Slack thread? Sixth: Who can turn it off? Not spiritually. Actually. Which person, which admin console, which switch.

Seventh: What is the user message? If people are allowed to use it, tell them what it is for, what it is not for, what requires review, and where to report a bad action. That is the standing-permission check.

Identity. Reach. Change authority. Human sign-off. Logs. Shutdown. User guidance. You do not need a giant committee to start. You need one owner, one candidate agent or internal app, and one honest map of what it can do.

Then label it. Proposed. Pilot. Approved. Blocked. Sunset. The label matters because always-on systems create always-on ambiguity. And ambiguity is where risk gets comfortable. It takes off its shoes. It opens your calendar. It says, I just moved a few things around.

No. Bad ambiguity. Back in the box. The big idea is simple. Agents are moving from answer boxes to work actors. Internal AI apps are moving from prototypes to places where work happens. And the control question is moving from approval to stewardship.

If it can keep acting, you need to keep owning it. That is the brief. Run the standing-permission check before the agent becomes the process. I am Michael. This is AI Change Desk. I will see you next time.