Automating the Security Work APIs Cannot Reach

Where Security Work Happens

Most security and compliance work is carried out in administration consoles. Identity providers, device management platforms, firewalls, email and collaboration suites, and supplier portals each contain settings that can open or close an exposure. Some of these platforms provide an MCP server, a documented API or a PowerShell module, but many still require a person to log in and change the setting by hand.

Microsoft Purview Compliance Manager shows how much of this work still lives in the portal. Each improvement action carries an implementation status, notes and a store of uploaded evidence, and keeping them current is done on the action's own page. Microsoft's documentation describes no API for updating improvement actions, and the only bulk route it documents is a workbook that a person exports, edits and uploads again. An assessment can hold a long list of these actions, and each one needs someone to open it, record what was done and attach the proof before an auditor will accept it.

Detect-then-respond tools typically stop once a finding is raised. A ticket is created, and a member of the security team works through the console to apply the fix. This manual effort sits at the centre of the Infinite Security Problem, because the number of findings grows faster than the time available to resolve them.

Computer use agents operate a web browser in the same way a person does. This gives the Negative Zero agent access to every console a security engineer can reach, including platforms that offer no programmatic access.

The Access Ladder: MCP, API, Browser

For each task, the Negative Zero agent selects the most reliable route available, and it treats the routes as a ladder that it climbs down only when it has to.

The top rung is MCP. When a vendor publishes a Model Context Protocol server, the agent calls the vendor's own tools directly, with typed actions and permissions scoped to what the task needs. Coverage is the narrowest of the routes, but where a server exists it is the fastest and most dependable way for the agent to work.

Where there is no MCP server, the agent moves to the interfaces that administrators already script against: REST APIs such as Microsoft Graph, PowerShell modules such as Exchange Online PowerShell, and the command-line tools that vendors ship for their own platforms. They behave the same way on every call, return structured results that the agent can check, and leave a clear audit trail. Coverage is broad, and much of the routine configuration work in Microsoft 365, Entra ID and Intune can be done this way.

The browser is the last rung. When a setting is exposed through none of those interfaces, the agent signs in to the vendor's own portal and does the work as an administrator would, inside the same Conditional Access boundaries that apply to your staff. Its coverage is universal, since anything a person can do in a console the agent can attempt, but it is also the slowest and least reliable route, which is why the agent keeps it for the last mile of work that the other routes cannot reach.

A successful browser run is not thrown away. Each action the agent takes is recorded, the final outcome is checked against the portal, and the recorded flow is saved as a deterministic replay. Later runs of the same task use the replay, and the agent steps back in only when the portal has changed. Each successful run therefore lowers the cost of the next one, and the share of the work that needs a model to reason its way through a screen keeps shrinking.

Computer Use Models Are Getting Faster

Stagehand publishes browser agent evaluations that compare models and agent harnesses on accuracy, cost and speed. In its Claude Code harness, the average time to complete a task fell by more than half between two consecutive Claude Opus releases, from 678 seconds with Claude Opus 5 to 326 seconds with Claude Opus 5.5, and the average cost of a task fell by 79%, from $2.44 to $0.51.

Accuracy is improving more slowly than speed. Claude Opus 5.5 completes 89% of the benchmark's tasks, the highest score on the board, against 78% for Claude Opus 5, and the average across the 15 runs that Stagehand shows is 80%. That is a strong result for general web tasks, and it is still too low for unsupervised changes to production security controls, where one task in nine going wrong is not acceptable.

Anthropic's own figures point the same way. On OSWorld 2.1 it reports 81.8% for Claude Opus 5.5 against 74.0% for Claude Opus 5, and it says the new model matches or beats Claude Opus 5 on resistance to prompt injection in every setting it tested, computer use and web browsing included. That matters for an agent that spends its time reading pages it did not write.

Negative Zero closes the gap that remains by verifying every action, setting the agent's autonomy by the risk of each change, and keeping evidence of exactly what the agent changed.

Reliability Across Multi-Step Tasks

A typical portal workflow involves 20 or more separate actions, and a single failed action can stop the whole task. When each action succeeds 95% of the time, a 20-step task completes successfully 36% of the time. At 99% per action the completion rate rises to 82%, and at 99.9% it reaches 98%.

This is why Negative Zero measures agent performance in verified task completions rather than benchmark scores, and why the ladder matters as much as the model. Moving a task from the browser to an API improves reliability even when the model stays the same, because one API call can replace many separate browser actions and every action removed is one fewer chance to fail. Verification after each step catches the failures that remain early enough to retry them, before a half-finished change is left behind in a production console.

The Cost Crossover

When Gmail launched in 2004, it offered 1 GB of free storage at a time when leading webmail services offered a few megabytes. Google built the product on the expectation that the cost of storage would keep falling.

Negative Zero is built on the same expectation for computer use. Inference costs are falling and agents complete tasks faster with each model release; on the Stagehand benchmark the cost of an average task fell from $2.44 to $0.51 between Claude Opus 5 and Claude Opus 5.5. The Cost Crossover is the point at which an agent completes a verified task at a lower cost than a human operator.

Tasks do not reach that point together. High-volume work with clear rules gets there first, such as Cyber Essentials readiness checks, configuration evidence collection and routine portal setting changes, because the agent runs it often enough for replays to take over and each run needs little judgement. Work that needs more judgement, such as remediation with production impact, reaches the crossover later, because it takes more reasoning per step and more human review around it. We expect the line to keep moving in the agent's favour with each model release, and we are building the platform around that expectation rather than around today's prices.

Autonomy Is Earned One Task at a Time

Cost determines which tasks an agent can complete economically. The level of autonomy for each task is set separately, based on its potential impact and the agent's record of verified work.

In Discovery, the agent finds and explains. It identifies the exposure and collects the evidence, and a person decides on the fix and applies it. A Conditional Access exclusion group that has grown beyond the break-glass and service accounts it was created for is a typical case: the agent can show exactly who was added and when, but removing them is a decision for your team.

As a Co-pilot, the agent proposes. It prepares the change as a plan for review, and a person approves the plan before it runs. Raising Intune compliance requirements, such as a minimum OS version or BitLocker, belongs here, because the change blocks every non-compliant device at its next sign-in and someone needs to decide when that is acceptable.

With Trusted Autonomy, the agent acts. It applies the fix within agreed boundaries, verifies it and records it, and your team reviews the audit log afterwards. Assigning the existing baseline policy to a device group that was missed, or running an Intune remediation script on a non-compliant device through the Microsoft Graph API, are the kinds of change that reach this level first.

Low-risk changes run automatically once the agent has a record of verified completions, while changes with production impact go to your team as a plan for review and approval. Every completed task produces an evidence pack that can be shared with insurers, auditors and boards. We call the point at which a task moves from proposing to acting the Trust Crossover, and as the agent builds its record, more work moves past it.

Whatever level a task has reached, it runs with scoped, short-lived credentials, every action is logged, timestamped and attributed to the agent, and any change that cannot be rolled back needs human approval.