The AI Security Agent Found the Problem. Now It Has Authority to Fix It.

IBM and OpenAI announced an expanded strategic partnership on August 13, 2026. The cybersecurity portion combines what IBM calls OpenAI frontier AI capabilities with IBM Autonomous Security, which IBM describes as a multi-agent powered service designed to deliver coordinated decision making, response and intelligence at machine speed.

Machine speed response addresses a real problem. Security teams already operate against adversaries who do not pause for approval cycles. What I want to examine is what follows once a security agent has the authority to act at that speed.

Detection and remediation are different actions

A security agent that identifies a vulnerability produces information. An analyst reads the finding, assesses it, and decides what to do. The agent's consequential reach ends at the edge of the report.

A security agent that remediates a vulnerability changes something in a live environment. It may modify an application configuration. It may revoke or rotate a credential. It may alter a firewall policy, patch a system, or isolate a host. Each of those actions touches resources that matter. Each can produce outcomes the remediation was not designed to produce.

Detection and remediation are not the same authority surface. The transition from one to the other is also a transition in what the agent is permitted to do. That distinction is worth examining precisely, because the language used to describe these systems often treats them as a single capability.

IBM describes agents that act

IBM Autonomous Security comprises three integrated agent systems. IBM describes ARGO as handling continuous cyber risk, compliance and posture assessment. IBM describes ADA, the Autonomous Defense Agents, as providing always-on monitoring, automated policy enforcement and rapid remediation across existing IT and security tools. IBM describes ATOM, the Autonomous Threat Operations Machine, as handling autonomous security operations: orchestrating multiple collaborating AI agents across threat hunting and investigation planning, and carrying out remediation at machine speed.

IBM's descriptions are worth reading precisely. ADA enforces policy and carries out rapid remediation. ATOM coordinates multiple agents and executes remediation at machine speed. IBM does not claim that every remediation action is fully autonomous, nor does IBM state that human approval is always absent. What the documentation establishes is that these systems are built to act, not only to advise. What it does not fully specify is the operational line between automated execution and cases where human review applies. That line is the authorization question.

Defensive intent does not settle authorization

An agent built to protect a system can still take a consequential action against that system. The objective is defensive. The action is real. Those are different things.

Consider what rapid remediation involves in practice. The agent has identified a threat. It has decided that the correct response is to modify a configuration, revoke a credential, or isolate a resource. It has the technical capability to execute that change. The question at that moment is not whether the agent intends to help. The question is whether this specific action, against this specific resource, in this specific state of the environment, has been authorized to execute.

As examined in instructions are not authorization, the instruction set tells an agent what to attempt. It does not constitute an authorization decision for every action that follows from that instruction. A directive to remediate detected threats does not authorize every remediation path the agent might choose toward that goal.

Agent Authority is not only a problem for coding agents or personal assistants. It becomes equally important when the agent is a defender. A defensive agent inside a production environment has permissions, tools and consequential reach. What governs what it is actually permitted to execute at the moment it decides to act?

Machine speed creates a different approval problem

The case for autonomous remediation is coherent. If every action requires a person to review it first, the speed advantage disappears. Adversaries do not wait for approval queues. A ransomware propagation that runs in minutes cannot be contained by a process that takes hours.

The case for careful authorization is also coherent. An agent with broad remediation authority in a production environment can cause significant harm while doing exactly what it was designed to do. Automated policy enforcement across existing IT and security tools, as IBM describes ADA, means the agent can reach many systems simultaneously. At machine speed, errors can compound before anyone has noticed them.

The architectural question is not which case wins. Both are true. The question is how to design an authorization layer that can operate at the speed defenders need without granting the agent authority beyond what the specific situation requires. That is a different problem from writing good security instructions, and it needs a different kind of answer.

OpenAI is already emphasizing boundaries and oversight

OpenAI's Daybreak Cyber Partners program, announced August 10, 2026, approaches the same question from a different angle. OpenAI says Daybreak partners may work on vulnerability discovery and validation, red teaming, penetration testing, incident response and remediation. OpenAI also says safeguards may include identity verification, defined testing scopes, logging, monitoring and human oversight. OpenAI states that partners work with organizations to define engagement boundaries, review findings and apply expertise before action is taken.

That framing is significant. OpenAI is describing a program where frontier AI capability is extended to cybersecurity work, and the same document that establishes the capability also establishes the boundary structure. Engagement scope must be defined. Findings must be reviewed. Human expertise applies before action is taken. OpenAI is not describing a system that acts first and applies oversight afterward.

The fact that OpenAI is explicit about this does not weaken the authorization argument. It strengthens it. At the program design level, the distinction between capability and authorized action is treated as requiring deliberate attention. Capability and authority are being separated, by design, at the point where it matters.

The next security boundary is not only around the attacker

Security architecture has historically drawn its primary boundaries around threats. Where is the attacker? What can they reach? What limits lateral movement?

When a security agent can take consequential action inside the environment, the architecture needs to reason about a second actor. The defensive agent has an identity, permissions and tools that can alter applications, configurations, credentials and policies. It operates at speed. It makes decisions about consequential actions without a person approving each one.

This is not a hypothetical concern. An agent with authority to enforce policy and remediate threats across IT and security tools is an agent that, given an error or a malformed input, can enforce an incorrect policy or execute an incorrect remediation. The scope of that error is bounded by the agent's authority, not by its intentions.

As discussed in when several agents act at once, multi-agent architectures distribute decisions across agents that may each have partial authority. IBM describes ATOM as orchestrating multiple collaborating AI agents. What governs what one agent is permitted to authorize on behalf of another, and how that authorization is verified at the point of execution, is a question the product documentation does not fully answer.

When the agent protecting production decides production needs to change

IBM and OpenAI are building something that addresses a genuine problem. Security teams need to respond faster than human review cycles allow. Autonomous agents that can identify threats and carry out remediation at machine speed represent a real advancement in defensive capability.

The authorization architecture that governs what those agents actually execute is the less visible part of the same problem. As examined in agent authority at execution, the relevant control at the moment of a consequential action is not the instruction written before deployment. It is the authorization decision that applies at the moment the agent is about to act: against which resource, in which environment, at what scope.

A security agent deciding that production needs to change is an agent making a consequential decision inside a live environment. The agent's defensive intent is not an authorization decision. The question the architecture needs to answer is: who authorized that specific change?

Mate Security separates the mandate from the path

On 26 August 2026, Mate Security published Gamebooks, a governed procedure layer for the AI agents its platform runs against live security alerts. Mate describes a Gamebook as a versioned investigation procedure: it specifies what must be investigated, what evidence must be established, which conditions should redirect the investigation, which actions are permitted, and the points at which the agent must escalate, stop or request approval. What a Gamebook does not do, on Mate's own description, is fix the exact sequence of calls the agent makes to get there. Oren Saban, Mate's co-founder and chief product officer, frames the design choice directly: agentic investigation requires a different architecture, one that lets the agent reason and adapt while staying anchored to how a particular organization actually investigates, without trading control for speed.

That is a specific and checkable claim about where authority sits. The organization's mandate, what must be established and what boundaries apply, is fixed in the Gamebook. The route the agent takes to satisfy that mandate is not. An orchestrator reads the incoming alert and the organization's investigation context and selects or composes the Gamebooks that apply. From there the agent can invoke Capabilities, reusable, vendor-neutral investigative skills such as profiling a user's behavior or tracing a process chain, in whatever order the evidence in front of it actually calls for. Mate's own account of the problem this solves is worth stating plainly: static playbooks break the moment an environment changes, and an agent given open-ended reasoning with no boundary can just as easily disable a legitimate account as contain a compromised one. A Gamebook is the attempt to keep the first failure mode from forcing the second.

Where Mate says execution is actually constrained

The distinction that matters for Agent Authority here is not investigative reasoning versus rigidity. It is mandate versus execution, and Mate's architecture keeps them in different layers. A Capability is something the agent can reason with. It is not, on Mate's own description, a standing grant of access to a vendor's API. Reaching an actual connected system is the job of a Flow, a tool-specific execution path. In the vocabulary this record has used since the IBM and OpenAI reporting above, a Gamebook is closer to the instruction set and the boundary an organization sets in advance. A Flow is closer to the authorization check this record has argued has to exist at the moment an action actually executes, as examined in agent authority at execution. Not every Capability a Gamebook calls on is consequential in that sense. Reading a process tree or checking a file's reputation is investigation. Disabling an account or isolating an endpoint is not, and Mate's architecture routes the second kind through a Flow rather than letting the agent hold direct, standing reach to the system it is investigating.

What that leaves genuinely open, and what the material available to this record does not resolve at the precision the question requires, is the physical enforcement boundary. Mate's own site and independent reporting on the launch converge on the shape of the design: Flows are described as the layer through which agents reach real systems, built so that agents do not hold open access to those systems directly, and SiliconANGLE, which reported the launch, describes confidence thresholds, blast radius limits and approval paths as enforced outside the agent's own reasoning loop rather than inside a prompt it could talk its way around. That is a materially different design from a system that only instructs a model not to exceed its scope. What this record could not independently confirm from public material is the finer structure of that enforcement: whether a Flow's inputs and outputs are strictly typed and checked server side, whether permission and rate-limit scopes apply at the level of a capability, a connector, a specific operation or a specific resource, whether credentials are ever exposed to the model itself rather than held entirely inside the Flow, and whether any other path from the agent to a connected system's credentials exists alongside it. Those are exactly the questions this record has asked of every vendor claiming an execution-time boundary, and they are preserved here as undocumented rather than assumed answered in Mate's favor.

Autonomy that customers grant, not autonomy by default

Mate's supporting documentation on its AI SOC automation is specific about where the line between automatic execution and human sign-off currently sits, and specific about who moves it. Nothing runs autonomously by default. Customers grant autonomy per workflow as they build trust in what the agent's investigations actually produce, typically starting with lower-impact actions such as closing confirmed false positives, enriching a ticket or blocking a known-bad indicator. Mate's own account draws a line at a named set of higher-impact actions, account disablement, endpoint isolation in a production environment and remediation touching an executive account, which it says execute only after analyst sign-off.

Two things about that design are worth keeping separate. The first is that this is not a claim that every security response requires a human; Mate is explicit that autonomy is configurable and earned per category, which means the product is built to let low-impact, high-confidence actions run without a person in the loop. The second is that the higher-impact list is Mate's own named set, scoped, on the material available to this record, to that platform's per-workflow autonomy configuration rather than published as a universal taxonomy every Gamebook inherits automatically. Whether a specific customer's Gamebook can quietly reclassify one of those named high-impact actions into a lower tier is not addressed in what Mate has published. What is documented is the shape of the control, not its ceiling.

What the Gamebook proves about authority, and what it does not

Mate's own framing treats the Gamebook as unusually direct Agent Authority evidence, because it is meant to encode an organization's actual investigative procedure rather than leaving the agent to infer its mandate from the alert alone. Security teams can translate an existing playbook into a Gamebook, extend the ones Mate ships, or write a new one in plain language against their own tools and data. That is a real and checkable claim about immediate procedural mandate: a named organization can point at a specific, versioned document and say this is what we authorized this investigation to establish and to touch.

It is not the same claim as the harder provenance question this desk has asked of every vendor building an authority layer: whether whoever authored or modified that Gamebook actually held the standing, inside their own organization, to delegate the consequential actions written into it. A natural-language procedure document is not a signed mandate, and Mate's own material does not claim it is one. The organizational procedure a Gamebook encodes can be documented in detail while the ultimate legitimacy of whoever wrote it remains outside what any platform can verify from the outside. Mate's architecture is honest about the first half of that distinction in a way few competing products are. It does not, and could not on its own, resolve the second half.

The same caution applies to what a Gamebook's escalation language actually proves. Mate describes an agent that must stop, escalate to a human, or request approval under conditions the Gamebook sets, and its high-impact action list requires analyst sign-off before execution. What is not established in Mate's published material is what that sign-off screen shows an analyst before they approve it, whether an approval is scoped to the exact parameters of one proposed action or to the action class more broadly, and what happens to an already-running investigation when the Gamebook governing it is edited mid-run. Gamebooks are versioned, which at minimum means a change is a discrete, identifiable event rather than a silent edit. Whether a new version retroactively withdraws authority from an action already in flight, or only governs what the agent does next, is not addressed in what Mate has published, and this record does not assume either answer.

A second architecture reaching the same conclusion

Mate did not build Gamebooks to answer the question IBM and OpenAI's partnership raised above. It built them to solve a narrower, more concrete problem: an agent free to reason its own way through an incident can disable a legitimate account as easily as it can contain a compromised one. But the architecture it arrived at answers the same question in the same shape. The organization's mandate and the boundaries on what the investigation may touch sit in one layer. The path the agent chooses while satisfying that mandate is left genuinely open. The mechanism that actually reaches a real system sits in a third layer built to enforce what the first layer permits, whether or not the public record yet proves it cannot be reached around. That an unrelated security vendor, working from a different starting problem, converged on the same three-way separation is evidence that this is the shape the problem actually has, not a framing this record imposed on it.

Visa ships the same separation as running code, not stated policy

Visa's Vulnerability Agentic Harness (VVAH) is a released, open-source pipeline that Visa says it runs against its own codebase, and that the company says has been downloaded by tens of thousands of developers since its initial open-source release. On 27 August 2026, Visa published a corporate release positioning an expanded version of VVAH alongside a new Visa Consulting & Analytics cybersecurity advisory practice, framed around a stated Mean Time to Adapt metric Visa defines as the elapsed time from an AI-discovered exploit path to a validated fix. Moona Intelligence verified the underlying remediation and validation capability directly against the repository rather than the announcement: VVAH's own CHANGELOG dates the introduction of a remediate command (pipeline stage S10) and a validate command (stage S11), and their on-by-default configuration in the shipped profile, to version 1.1.0, released 30 June 2026, almost two months before the corporate announcement. A later release, version 1.2.0 on 4 August 2026, refactored both stages onto a shared backend with what Visa's own changelog calls read-only enforcement, and the repository's current main carries no dated entry after that release. The 27 August event is Visa formally positioning and expanding around capability that had already shipped and that Visa says it already runs internally, not the date autonomous remediation first appeared.

What Stage 10 can write, and what it cannot do

The shipped default profile sets both the remediation and validation stages on. A plain vvaharness scan therefore continues past the nine detection stages into Stage 10 remediation and Stage 11 validation without an operator asking for either; reaching detection only requires an explicit flag. Stage 10's default fix mode writes a candidate patch directly into the target repository's real, on-disk working tree (not a proposal held apart from target state), using a filesystem backend the tool itself confines to the repository root, with a tool set of Read, Glob, Grep, Edit and Write. Bash is denied on every shipped profile; the harness's own documentation states a prompt-injected agent with a host shell would be remote code execution against the scanner, and a remediation role routed to a non-Anthropic backend cannot write files at all and errors instead of silently proposing nothing. Moona Intelligence searched the codebase directly for any git commit, push, or merge operation and found none: the only git write-adjacent calls are an intent-to-add used solely to make new files visible to a diff, and a local revert of an edit a policy check rejects. The harness does not build, compile, or run the target's test suite at any stage. This is confirmed both in its own operational security documentation, which calls it "a static analyzer," and directly in the code, where no test-runner or build invocation exists in the remediation or validation path. This is Mutation Authority in this record's terms: Stage 10 is permitted to alter target working-tree state. It is not Adoption Authority, and the codebase gives that word no mechanism: nothing in VVAH accepts a candidate into a project's accepted state, and nothing in VVAH reaches a shared or production environment.

The policy gate is real code, and it ships unconfigured

VVAH also ships a policy layer that can narrow what Stage 10 is allowed to touch: a deny/allow list keyed to CWE identifiers, forbidden-path globs, and a diff-based post-gate that reverts an edit landing outside the allowed scope. That mechanism is genuine, enforced code, not aspirational documentation. The specific policy file the shipped default profile actually loads, however, ships with an empty deny list, an empty forbidden-path list, and a default action of allow: the scope-limiting behavior VVAH's own documentation describes is available machinery an operator must configure, not a restriction active out of the box. A separate, richer example file demonstrates what a configured policy looks like, but it is not the file the default profile resolves to. Moona Intelligence also found no check that the target's working tree is clean before Stage 10 runs; the harness instead refuses to remediate only when the repository's git HEAD has moved since the scan that produced the finding, a staleness check an operator can override, which is a different guarantee than transactionality or automatic rollback of a run that fails midway.

An operator-responsibility model, not a technical one

VVAH's own README states the tool "runs with elevated privilege and must only be used against trusted repositories by authorized operators," and instructs operators to scan only code they own or have explicit permission to test. Moona Intelligence found no identity, role, or authentication system inside VVAH itself that checks who is invoking it or who may accept its output: whoever has shell access and valid model-provider credentials can run any command with full effect. That gap is the same one this record has already logged for every other authority layer it has examined: technical operator initiation is documented; proof that the operator was organizationally entitled to delegate mutation authority over the target repository is external to the tool and undocumented by it. Each run does leave real, inspectable evidence: a per-finding DTO, a unified diff, a validation verdict, and a run manifest recording the tool version, a config hash and the target's git SHA. That manifest's own model-role capture, however, is scoped to the nine detection stages, not remediation or validation, and none of it should be read as a signed or non-repudiable authorization receipt; it is operational logging, not a mandate.

Visa's own human gates, and a boundary a headline can compress past recognition

VentureBeat's reporting on the 27 August release, corroborated independently here, quotes Visa placing human review at three separate points: before the tool is run, when the specific patch is reviewed, and again before anything is merged. Visa's own documentation describes its four-phase pipeline as proposing candidate fixes and adversarially validating them "before adoption." Both statements are accurate, and both describe adoption and merge authority, not the mutation that happens earlier in the same run: Stage 10 has already written to the working tree before any of Visa's three human gates apply to that specific edit. A headline compressing this into an agent that patches production code before any human reviews it overstates in one direction: nothing in VVAH reaches production, and Visa's own build, test and code-review workflow still governs what merges. Describing VVAH's default behavior as requiring human approval before every edit would overstate in the other direction, and is not what the shipped default does. What the evidence actually supports is the finding this record has been building toward across IBM and OpenAI's descriptions above and Mate's Gamebooks: human oversight is not one boundary. VVAH delegates real, working-tree-altering authority to an agent before a person reviews that specific change, and keeps commit, merge, build, test and deployment on the human side of a separate, later boundary: the same three-way separation this record found in Mate's architecture, arrived at again by a card network's own shipped tool rather than a security vendor's investigation layer.