The Agent Clicks the Button, and the Log Says a Person Did It

On 3 September 2026 OpenAI released GPT-6 Astra, and the capability it led with was not reasoning or context length. It was computer use: the model operates software the way a person does, through pixels, keyboard and mouse, rather than through an interface built for machines. The numbers behind the claim are real enough to take seriously. On OSWorld 2.0 it scores 72.6 percent against 65.7 for the previous flagship, and the same task set that took roughly 75 minutes now takes about 40. Rollout is staged, starting with a gated enterprise programme and reaching Plus, Pro, Business and Enterprise tiers along with the API and AWS. The marketing framing is unusually candid about the point of all this: you no longer need to build an integration to automate a system. That framing is exactly what should give a security or compliance function pause, because the integration layer everyone found tedious was quietly carrying most of the controls.

It is worth being precise about what an API actually gave you, because it was never only a data format. A token has a scope, so an agent could read invoices without being able to approve them. An endpoint has an authorisation check that runs server side, independent of what any client believes it is allowed to do. Rate limits bound the blast radius of a loop that goes wrong. Requests arrive with a service account identity attached, and they land in a structured log with a timestamp, a caller and a payload. None of that exists when a model drives the user interface. The agent authenticates into a session, sees every screen that session can reach, and clicks whatever a human in that seat could click. The permission boundary stops being a policy you wrote and becomes whatever the application decided to render.

The attribution gap is the part that breaks first, and it breaks quietly. When an agent updates four hundred rows in an ERP through the interface, the system of record writes exactly what it would write for a person: four hundred updates by a named user or a shared service account. There is no field for which model made the change, which version of it was running, which instruction produced the action, or whether a human reviewed the plan beforehand. Six months later, when someone asks why a supplier bank detail changed on a Tuesday, the log answers with a name belonging to somebody who was not at their desk. That is not a theoretical concern. Under ISO 27001 the logging control exists so that actions can be attributed to identities, and under SOC 2 the evidence chain for a change depends on being able to say who did it and under what authorisation. A UI driving agent does not defeat those controls by attacking them. It simply supplies a truthful looking answer that is wrong.

The vendor side of the monitoring picture is thinner than the launch coverage suggests, and the distinction is one worth writing into your risk register in plain words. OpenAI states that chain of thought monitorability decreased relative to the previous generation, meaning the model is less likely to expose its own reasoning in a form that a watcher can read. It also describes expanded internal monitoring, isolated training environments after the Hugging Face incident in July, submission of the model for government review under a voluntary framework, and restrictions that make the model refuse advanced cybersecurity tasks outside the gated programme. All of that is genuinely better than nothing. None of it is yours. Vendor monitoring covers vendor deployment, and nothing published extends that telemetry into a customer audit trail. If you cannot query it, subpoena it or hand it to an assessor, it is not evidence for your programme, and treating a vendor safety page as a compensating control is the error to avoid here.

That leaves identity, which is where most teams will make an expensive decision without noticing they made one. There are three realistic options and each has a cost. Give the agent a shared service account and attribution collapses immediately, because every action across every workflow lands under one name. Let the agent operate inside a real user session and the log becomes actively misleading, attributing machine actions to a person who can be disciplined, audited or subpoenaed for them. Issue a distinct, scoped, short lived credential per agent and per workflow and you keep attribution, which is the right answer, and also the point at which you are doing the identity and access work you thought you were skipping. That trade is fine, so long as somebody states it out loud. What is not fine is arriving at option two by default because it was the fastest way to get a demo working.

Segregation of duties deserves its own paragraph because it fails in a way that is easy to miss. Financial and payment controls are built on the assumption that the person who raises a transaction is not the person who approves it, and that separation is usually enforced by giving two humans two different sets of permissions. An agent that operates screens inherits whatever the session can reach, so if a single account can navigate to both the raise screen and the approve screen, the four eyes design is decorative. Under PCI DSS, and under any financial reporting control regime, that is a finding regardless of whether anything bad has happened yet. Before an agent touches an approval workflow, someone has to confirm that the identity it uses cannot complete both halves of a control that was designed to require two people, and that confirmation belongs in writing.

Mapping this into the frameworks you already run is not difficult, and it is far cheaper to do before deployment than after. Under ISO 42001, every UI operating agent earns an inventory entry naming the applications and screens it may touch, the identity it uses, the workflows it is approved for, who approved them, and what evidence of its actions is captured and for how long. Under ISO 27001 it sits across access control, logging and supplier management at once. Under SOC 2 it is a change management problem in two directions: the agent changes production data, and the applications it drives change their own interfaces on their own release schedule, which means a vendor shipping a redesigned form can silently turn a working automation into one that fills the wrong field or retries and double posts. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will each carry an agent inventory and an access review as monitored controls once someone configures them. What none of them will do is discover that a team in operations pointed an agent at the billing system last month, and shadow automation is going to be the dominant failure in this category for the next year.

The adoption pattern makes that risk worse rather than better, because UI automation gets deployed precisely where APIs are absent. The long tail of internal systems with no clean interface is the same long tail with no role based access model, no structured audit log, no test environment and often no owner. That is where a tool like this is most attractive and least safe, and it is a different population of systems from the ones your security programme has been reviewing. The same logic reaches the software your teams are building rather than buying. An internal tool assembled in Bolt, v0 or Lovable, a support flow wired to ChatGPT or Claude, a booking front end running on ElevenLabs, or a service scaffolded by Cursor or Devin will each be a candidate for exactly this kind of automation, and none of them arrived with an access model an auditor would recognise. We have argued before that platform compliance is not your compliance. This is the same argument with a faster clock on it.

The work available this week is small and specific. List the internal systems that have no usable API, because that list is the shortlist of where a UI operating agent will be pointed, with or without your involvement. Decide the eligibility rule now: which systems are open to UI automation, which are API only on audit or compliance grounds, and which are off limits entirely. Require a distinct identity per agent per workflow, and confirm no such identity can complete both sides of a segregated control. Decide what gets captured, whether that is step logs, screen recordings or application audit records, how long it is retained and who can search it, before the first agent runs rather than after the first incident. And write down the failure path for the day an interface changes underneath a running automation, because that day is scheduled by someone else. None of this stops you using the capability, and the productivity case is strong enough that refusing it is its own kind of risk. It stops you finding out in an audit that for six months your system of record has been confidently naming the wrong actor.