When an AI can operate the same computer interfaces your employees use, treat it as a new operational actor. Give it a distinct identity, narrow permissions, consequence-based approvals, a reconstructable action trail, and a tested way to stop. Those controls have to sit in the execution path. A policy document cannot interrupt a bad click.
I am excited about what this unlocks. Imagine giving people back the hours lost to copying records, wrestling with forms, or moving the same information between systems. That is useful work for an agent. I also care about the employee who gets paged when the agent changes the wrong record at 2:00 a.m. The opportunity and the operational responsibility arrive together.
On September 6, NVIDIA CEO Jensen Huang posted that “AGI has arrived” with OpenAI’s GPT-6 Astra. We can debate that label for years. A better Monday-morning question for CIOs and CISOs is much more concrete:
What changes when AI can use the computer?
Computer use changes the control boundary
Traditional automation usually enters through an interface built for software. An API advertises a defined set of operations, accepts structured input, and can enforce scopes, schemas, and rate limits. Those boundaries may be imperfect, but everyone can see where the application connects.
A computer-use agent can work through interfaces built for people. OpenAI says GPT-6 Astra combines computer use with multistep professional workflows across browsers, code, documents, spreadsheets, presentations, and other software. That flexibility reaches valuable processes that never received a clean API.
It also lengthens the chain of possible action. The agent can interpret a goal, inspect a screen, choose a control, move data to another application, and adapt when the interface changes. The permission to open an application says little about what it can do once it gets there.
This is the shift: governance has to follow the action all the way to the destination.
The old user-or-application model is too small
Enterprise controls have long recognized human identities and machine identities. A computer-use agent mixes characteristics of both. It may authenticate as a workload, act through a human-facing screen, carry authority delegated by a person, and decide which tool to use next.
That makes one question surprisingly hard: who performed this action?
“The AI did it” is not an answer an operator, auditor, customer, or regulator can use. The record should identify the agent, the run, the accountable owner, the authority it carried, the control decision, and the system that accepted the change.
This builds directly on the identity problem created by AI agents. Computer use makes that problem visible because familiar clicks can hide an unfamiliar chain of authority.
Inventory effective authority before features
Start with what the complete workflow can actually do, including browser sessions, extensions, connectors, local applications, downloaded files, and inherited credentials. A tool name such as “reader” or “assistant” does not prove the resulting workflow is read-only.
For one agent, write down four things:
- the systems it can reach
- the data it can observe
- the actions it can attempt
- the consequences if one action is wrong
Use observed behavior from a controlled environment, not the happy path from a demo. If an expense agent can open a finance system, find out whether it can only draft an entry, submit one, approve one, or change the payee. Those are four very different grants of authority.
I would start with the agent that can touch money, production, identities, customer data, or regulated records. Counting every experiment can wait. Find the largest blast radius first.
Identity has to survive the whole journey
Every production agent needs a distinct workload identity and an accountable business owner. Preserve the initiating user or service context when it matters, but do not hide the agent behind a person’s standing credentials.
In February 2026, the NIST National Cybersecurity Center of Excellence called for identification, authorization, auditing, non-repudiation, and prompt-injection controls for software agents. That is the right direction. An identity should connect the agent’s purpose, owner, allowed systems, credential lifecycle, and action history.
The practical test is simple: can the destination distinguish this agent and this run from every other user and automation path? If the answer is no, containment and investigation will both be slower.
The control path above is the architecture in miniature: identify the actor, constrain the action, pause for approval when needed, record the result, and keep a physical way to cut authority.
Put governance in the action path
The infrastructure control plane should make five controls real at execution time:
- Identity: authenticate the agent and preserve accountable delegation.
- Authorization: evaluate the exact operation, target, context, and credential scope.
- Approval: pause consequential actions for a named human decision.
- Evidence: correlate the request, policy decision, tool action, and resulting state change.
- Containment: stop new work, revoke access, disable tools, and preserve the record.
This is where an AI control plane becomes a tier-zero asset. A gateway or policy layer can centralize model access, tool registration, approval rules, data controls, and telemetry. The destination system still has to enforce its own permissions. Central visibility and local enforcement work together.
Prompt instructions are useful guidance for the model. They are not a substitute for an independent authorization check. “Do not delete production” belongs in the instructions and in a control the agent cannot rewrite.
Tie human approval to consequence
Requiring approval for every click will turn a useful agent into a very expensive cursor. Let routine, reversible, low-impact work flow. Increase friction as the consequence rises.
An agent might read a customer record, draft an update, and prepare an email without interruption. Changing payment details, sending a legally consequential message, granting access, deleting production data, or deploying sensitive code should cross a clear approval boundary.
Bind the approval to the exact action and target, and let it expire. Approval to update one test record this morning should not become permission to update every production record next month. The person approving should see enough context to understand the decision without replaying the whole session.
These thresholds turn the seven executive AI risk questions into enforceable operating rules.
Keep evidence an operator can use
Useful evidence answers what happened without asking the agent to narrate its own behavior. Record the agent and run identities, initiating instruction or workflow reference, model and configuration, tools and destinations, permission decisions, human approvals, timestamps, attempted actions, accepted changes, and observed results.
Do not confuse more logging with better evidence. Copying every prompt, document, and credential into a permanent store can create a second security problem. Protect sensitive content, set appropriate access and retention, and correlate records across the model gateway, identity provider, tool, and target system.
OpenAI’s Astra safety overview reports stronger prompt-injection resistance and safer behavior in realistic browsing and professional computer environments than its predecessor. That is encouraging. OpenAI also describes monitoring and system safeguards as additional layers. Enterprise architecture should follow the same defense-in-depth logic rather than asking one model behavior to carry the whole control burden.
Test the stop button before production
Every computer-use agent needs a containment drill. Pause the agent. Block new runs. Disable the affected tool. Revoke or invalidate its credentials. Inspect queued and delegated work. Preserve the activity record. Then verify the destination no longer accepts actions.
A red button in a console is only a promise until the team tests it. Some tokens remain valid until expiry. Some downstream jobs continue after the parent stops. Some completed actions cannot be reversed. The exercise shows where “stop” actually ends.
This belongs in the day-two operating model for enterprise AI, alongside ownership, observability, incident response, cost, and lifecycle management.
Run a ten-question readiness review
Before an agent operates enterprise applications, get clear answers to these questions:
- What business outcome owns the risk?
- Who is accountable for the agent?
- What distinct identity does it use?
- Which systems and data can it reach?
- Which exact actions can it perform?
- Which actions require human approval?
- Can another operator reconstruct a material change?
- How do we stop it and revoke authority immediately?
- What happens when external content tries to redirect it?
- Who leads the incident when behavior surprises us?
If the team cannot answer one, that is useful. You have found a design decision while the blast radius is still small.
The AGI label can wait
Maybe “AGI has arrived” becomes the phrase history remembers. Maybe the definition keeps moving. Either way, enterprise leaders already have enough evidence to act on the operational change in front of them.
AI can now move through computer interfaces, professional tools, and multistep workflows with growing capability. That is thrilling. It also means AI governance cannot remain a meeting that happens before launch. It must become identity, authorization, observability, approval, and containment built into the environment where actions occur.
When AI can use the computer, governance becomes infrastructure. Build that infrastructure well, and we can give people powerful help without leaving them alone with the consequences.
