One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.”

It sounds almost funny. In software terms, though, it points to a real problem. An access control said no, and the agent treated the answer as information about how to continue.

“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, according to the prime minister, though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.

Around the same time, OpenAI disclosed another incident. A model in training found its web searches and direct connections blocked, then discovered that the environment’s own DNS resolver still answered. It embedded questions in hostnames and got answers from an external chatbot. OpenAI stopped the run. Days later, it shelved GPT-6.1 Astra, which Saachi Jain, its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”

Different systems, different failures, one question: what does “access denied” mean to an agent?

Why a denial is information

Traditional software treats an authorization failure as the end of a code path. A service gets a 403, raises an exception and someone reads the log. The denial works as a stop sign because the program has no independent objective to pursue.

Agents do have one.

We have spent years teaching software to recover from failure: retry the request, switch the endpoint, back off and try again. Those are good instincts. They become dangerous when the failure is the security control itself.

A timeout says “try later.” A malformed request says “fix this.” An authorization failure says “you are not allowed to do this.” Those are different kinds of messages, but a guardrail that returns all three as text in the model’s context makes them look alike.

Researchers are now measuring what happens after a restriction is applied. In the August paper Permission Denied, 12 coding agents were tested under increasingly restrictive security policies. Blocked runs rarely stopped early. They timed out or produced wrong solutions. Of the policy-induced failures, the researchers found that 97% came from the agent building a workaround.

The issue is not simply whether a model understands a policy. It is what the system allows the model to do after the policy says no.

Enforcing policy outside the model is no longer a new idea. Recent research puts policy enforcement at a trusted tool boundary the agent cannot control. But that still leaves an unanswered question: when should a denial end the task rather than become another input for the agent?

Real systems already have harder stops. The OpenAI Agents SDK can halt a run when a tool guardrail raises an exception. Claude Code’s auto mode can return control to a person after three blocked actions in a row or 20 in total.

Nothing tells you which denials deserve which response. The missing piece is not another kill switch. It is a policy for deciding what a denial means and what authority disappears when it happens.

I don’t think the lesson is that models are bad. The problem is where we put the boundary. A guardrail that reports back to the thing it is restraining is a soft boundary. It shapes behavior. It doesn’t necessarily end it.

A terminal denial changes authority

I would treat denials differently depending on what they mean.

A denial is retryable when the same authorized request might succeed later without anyone granting new authority. A timeout, a temporary dependency failure or a rate limit can fit here.

It is correctable when the request itself is malformed and a legitimate fix does not expand what the task is allowed to do.

It is terminal when continuing would require permission the task was never given, such as reading another tenant’s records or reaching a destination the egress policy prohibits.

The test is whether succeeding needs permission or just patience.

If it needs permission, the agent shouldn’t be the one looking for it. At some point, persistence is just a very polite security incident.

In a previous InfoWorld piece, I argued that permission enforcement should be independent of how an agent interprets its situation. A terminal denial applies that principle at the moment of refusal. It should change the state of the system, not just the contents of the model’s context.

A terminal denial should do five things.

1. Enforce it at a trusted execution boundary. The decision happens in the harness, policy service or gateway that executes the tool call, outside the model’s reasoning. A model cannot argue its way past a check it does not control.
2. Take away the relevant authority. Once the task is terminally denied, the runtime rejects later calls that depend on the authority that was denied.
3. Invalidate the relevant capabilities. Short-lived credentials and delegated permissions need to be revoked or fenced, including any the task passed to helper agents. Blocking an export tool is not enough if the same task can reach the same data through email five seconds later.
4. Record the attempt outside the agent. The control plane should record the attempted action, policy decision and task identity in a protected audit trail. The agent shouldn’t document the event that stopped it.
5. Require fresh authorization to resume. Restarting the task should be a new decision by a person or policy, not an automatic retry.

The model can still reason. It just no longer gets to act under the old authority.

This is not a bigger kill switch. A kill switch stops a whole agent; a terminal denial acts on a specific refusal when it happens.

Timing matters too.

Suppose the harness checks that a task is authorized and then dispatches an action. If the task is terminated between those two steps, a stale approval can still get through. High-impact operations need atomic authorization and dispatch where feasible, or fencing tokens that downstream services verify before accepting an action.

Work already in flight creates another problem. On an enterprise system I worked on, a permission check correctly rejected an operation, but the workflow kept going through work that had already been queued. The control worked at the point of rejection. The task still had a path to continue.

A queued operation may be cancellable. A running operation may be interruptible. A committed database write may require a compensating action instead.

The architecture needs to say which guarantee it provides.

Deny the effect, not the tool

The question I ask about every agent permission is what outcome the denial protects.

Not which API is blocked. Which effect is the policy trying to prevent?

Customer data leaving a tenant is an effect. It might happen through an export API, an email attachment, a file upload or a DNS lookup.

On another project, we restricted a sensitive operation at the main service interface and considered the control complete. Testing showed the same operation was still possible through a separate, approved path. The permission worked. We had protected the interface, not the effect.

An April stress test of Claude Code’s auto mode found a version of exactly this problem. When a command-line tool was unavailable, agents fell back to editing state files directly, “a path the classifier does not evaluate.”

Group controls by effect. When a terminal denial fires, apply it to the protected operation across every tool the task can use.

Treat repeated denials as a signal, not a magic number. Several denials across different tools pursuing the same outcome may mean the task should stop. Set the threshold by risk; one high-impact violation may be enough.

Treat every communication path as egress. Blocking HTTP does not establish isolation if DNS, package installation or shared infrastructure can still reach the outside.

Test the boundary the way an agent might challenge it.

Deny a resource through one tool while leaving another route available. Terminate a task with an action still queued. Revoke a parent task and check whether its helpers continue. Try a new action with a stale capability.

Measure whether the prohibited action executed. Do not measure success by whether the model said it would stop.

ScopeBench recently found 331 boundary violations that mechanical verification missed.

None of this is new to security engineers. Least privilege, deny by default and fail closed are decades-old principles.

What changes with agents is what happens after a control says no.

The answer is not to make every tool error fatal. It is to separate the model’s ability to propose the next action from the system’s authority to permit it.

A denial is a response. Enforcement is what happens next. The agent can be as persistent as we like. The boundary shouldn’t be negotiable.

This summer, the White House rolled out the Gold Eagle Initiative, billed as an “unprecedented” effort to coordinate cybersecurity vulnerability disclosure across government and industry. It was easy to miss this news with all of the other safety concerns in the world of AI, but the timing isn’t a coincidence — and neither is the terminology. Gold Eagle is just one in a fast-growing category of security clearinghouses. Although it has already been scaled back once, recast in an August CISA fact sheet as a narrower triage layer rather than the sweeping coordination system first announced, it still indicates a trend we’re seeing in the world of cybersecurity.

To understand what a clearinghouse is, and why the number of them is increasing, it’s important to understand what has broken — namely (and hugely), the vulnerability disclosure process. For many years, vulnerability disclosure worked like this: A researcher found a bug, reported it privately, and honored an embargo period that gave vendors time to patch quietly (and hopefully quickly) and ship the fix before the bug was made public. This gave the good guys a chance to patch before the bad guys had a chance to use the vulnerability for bad guy things. The process was tedious, but it worked because the economics worked — historically, only nation-states had the resources to hunt for — or reward teams of experts to hunt for — undisclosed vulnerabilities at scale.

Of course, AI has changed all that — all of that. The average gap between the discovery of a vulnerability and its weaponization has collapsed from something measured in years to negative seven days. The bad guys are finding CVEs and exploiting them long before the good guys have had a chance to patch them. A terrifying prospect, to be sure. And it’s something I embarrassingly admit has happened to me personally several times recently.

Frontier AI models are democratizing the finding, chaining, and weaponization of flaws faster and cheaper than any team of human experts. Indeed, it’s the chaining — and AI’s mastery of it — that may be the most debilitating. In chaining attacks, two or three low-severity and moderate-severity bugs get stitched together by an AI system. On their own, these bugs are pretty unremarkable. However, by joining the “right” ones together (something AI is very, very good at), a model can achieve a full compromise.

Several major AI labs have already disclosed that their own models were used to breach unrelated systems, evidence that the old assumption about who can afford to hunt for exploits no longer holds. Anyone with API access to frontier models can now run what amounts to a small (and very efficient and intelligent) hacking team. Worse, these models can be resold illicitly to embargoed countries, and there’s an entire ecosystem of jailbreaking models to get them to do even more nefarious things.

Why clearinghouses?

At its core, the AI hacking threat is a scale problem that software development, be it proprietary or open source, was never set up to handle. It’s not just big projects like Linux and Kubernetes that are targets; it’s every one of the libraries underneath every application. There are literally millions and millions of packages available on PyPi (Python), npm (Node.js), RubyGems (Ruby), Crates (Rust), NuGet (C#/.NET), and Packagist (PHP), along with tons of smaller language ecosystems. These are ecosystems that power almost everything built today.

AI-generated vulnerability reports arrive faster than volunteer maintainers can read them, let alone verify and fix them. A single, real bug can spawn a dozen duplicate CVE filings from different automated scanners, each with its own tracking number, essentially serving as a distributed denial of service attack on the upstream. And, this is from the good guys, trying to do the right thing.

This “gap” (to put it mildly) is what clearinghouses are designed to close. Historically, a bug fix loop looks like:

1. Discover bug
2. Report to maintainer
3. Honor embargo
4. Maintainer patches
5. Release fix to the world

In the world of clearinghouses, here’s what it looks like:

1. Discover bug
2. Report it to clearinghouse
3. Receive patch
4. Clearinghouse handles the rest (handle embargos, reporting upstream, etc.)

It could look even as simple as:

1. Sign up for clearinghouse
2. Receive patches from clearinghouse
3. Clearinghouse handles the rest

The clearinghouse is essentially a trusted intermediary, run by a vendor, an association, or other entity, which triages the flood of AI-generated reports, identifies which are real, accepts or builds a fix, validates it, sends it to customers and partners, and only then works to merge it back into the upstream project. This still must be done at a pace that the upstream can handle.

There are also ethical dilemmas to handle here. It is not fair to force upstream projects to operate at the speed that for-profit and gigantic public entities require, especially large, demanding organizations like Fortune 500 corporations and governments. Remember, many people participate in open source projects for “fun”. Working for organizations demanding responses to thousands of CVE patches, faster and faster, is not fun or it would not be called work.

Assessing clearinghouses

Not all clearinghouses work in the same way. Some efforts function as a permanent fork that patch (and keep patching) the vulnerable code with AI-generated maintenance, and never reconcile with the original project. Others push every fix back upstream so it becomes permanent, which benefits the whole community. The latter seems to be the more functional option because if you can’t get your stuff back upstream, things could be locked in a clearinghouse forever. That feels a lot like vendor lock-in, as much as dressing a proprietary product in “open source” clothing does. You simply can’t have an open source clearinghouse that’s proprietary.

What else should an enterprise security team be looking for in a clearinghouse? Some hard questions to ask include:

• Can it triage the noise?
• Can it correlate multiple reports into one confirmed vulnerability?
• Can it produce a working patch, and not just an alert?
• Does it have a credible path upstream, rather than trapping users on a permanent fork?
• And, most importantly, who’s paying for it, and will they keep paying? In a word: Is it sustainable?

Clearinghouses may or may not become a viable tool in the fight to stay ahead of (or maybe just keep up with?) vulnerabilities in the AI age. Regardless, the bigger and more uncomfortable question is whether software itself needs to change. There are initiatives in place to quash entire classes of bugs: memory safety, thread safety, etc. Some are looking to write new Linux kernel drivers in Rust, a memory-safe language that structurally eliminates entire categories of the chaining bugs AI is so good at identifying and exploiting.

Other tactics include looking at compiling C/C++ with tricky new methodologies (fat pointers, or auxiliary pointers) to, again, remove entire classes of memory and threading bugs. Whether decades-old languages such as Python, Node.js, and friends can be hardened in similar ways, or will need to be rewritten from the ground up, remains to be seen. The world of open source is ablaze with experimental solutions.

For now, it’s less about a silver bullet and more about recognizing that vulnerability response has become a team sport at a scale nobody planned for. Every major bank, utility, and software vendor is running its own AI-augmented triage operation, and those operations increasingly need to talk to each other. The organizations that ask hard questions about triage speed, upstream commitment, and funding durability rather than taking a clearinghouse’s staying power on faith will be the ones standing strong under relentless vulnerability fire.        

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

For most of the history of enterprise software, accountability has been relatively easy to understand. A person logs in, a person has a set of permissions, and a person takes an action. If something goes wrong, you can usually work backwards from there.

Agentic AI changes that. We are moving from systems that suggest what someone should do to systems that can actually do it. Agents can access tools, call other systems, make decisions across multiple steps, and increasingly operate without a human approving every move. That is the point, of course. An autonomous system that needs someone hovering over every decision is not particularly autonomous.

But the more action we hand over, the more important one deceptively simple question becomes: When an agent does something, who did it?

Not philosophically. Operationally. Whose authority was it using? What was it allowed to touch? Who granted those permissions? And if something goes wrong, who owns the outcome?

Accountability starts with identity

The first question is what an agent actually is inside your organization. Should it always be treated as a delegate of a human, acting on that person’s behalf and inheriting some version of their permissions?

That model makes accountability relatively straightforward. If my agent does something, the action can be traced back to me. But it becomes harder to sustain as agents become more persistent and autonomous.

An agent might run continuously or serve an entire team rather than one person. It might perform a business function that continues long after whoever originally configured it has moved on. In those cases, should the agent have an identity of its own? And if it does, who creates that identity, who owns it, who grants its permissions, and how long should those permissions last?

Identity is where accountability starts because if you cannot reliably answer who the agent is, everything that follows becomes harder to reason about.

Identity and permissions are closely related, but they are not the same thing. Consider an agent designed to conduct research using public information. It might be perfectly reasonable for that agent to use a public model, external tools, or public Model Context Protocol (MCP) servers. Now point that same capability at internal finance data.

The agent has not fundamentally changed. Its environment has.

Suddenly, sending information to an external model may be unacceptable. Certain tools may need to disappear from its reach. Data that could previously move freely now sits inside a very different compliance boundary. So permissions cannot simply be a static list attached to an agent. They need to reflect who the agent is, what it is trying to do, and the context in which it is operating.

That becomes even more important when agents can choose different tools and paths through a problem rather than following a completely predictable workflow.

Delegation gets complicated quickly

Now add sub-agents.

An agent receives a goal and creates several others to complete pieces of the work. Do those sub-agents inherit the parent’s identity? Do they inherit its permissions? Should their authority be narrower based on the task they have been given? And who ultimately owns what they do?

There may not be one universal answer, but there does need to be an answer inside the enterprise. More importantly, there has to be a through line.

An agent can delegate execution to another agent, which delegates part of that task again. That cannot mean accountability disappears somewhere along the way. Autonomy can branch. Accountability cannot disappear.

Enterprises need to retain the relationship between the original authority, every agent involved, the permissions each one carried, and the actions they ultimately took. Otherwise, when something goes wrong, everyone gets to participate in a very expensive game of “whose agent was this?”

The same problem appears over time, not just across agent chains. Consider a long-running agent that constantly monitors tickets and takes action. Eventually, it becomes part of normal operations. Then the person who created it leaves the company.

The agent stays.

Who owns it now? Did responsibility automatically transfer to the person’s manager? Was a successor assigned? Does the team own it? Does the enterprise? And what happens to permissions that were originally linked to someone who no longer exists in the organization?

We already manage life cycles for employees, service accounts, and enterprise applications. Agents need the same seriousness. They need an ownership life cycle, not simply a deployment life cycle.

Accountability has to exist in the system

Defining ownership is only useful if you can reconstruct what actually happened. That means connecting an agent’s identity to its permissions, actions, tools, sub-agents, and eventual outcome.

If something fails, the organization should be able to understand what happened, why the agent was allowed to do it, which permissions enabled the action, which agent actually performed it, and where the control failed. That is what makes remediation possible.

This is why identity, permissioning, and execution tracing cannot live only in policy documents. Writing down who owns an agent is not the same as encoding that ownership into the systems governing it. Telling an agent not to access something is not the same as preventing access. And asking teams to piece together an incident afterwards is not the same as tracing execution while the system is running.

The goal is not to put a human approval step in front of every agent action. That would defeat much of the value of autonomy. The goal is to move humans up a level, from making every individual decision to defining the boundaries within which autonomous systems can make them.

As agents take on more work, enterprises need to know what they can do, who owns them, how authority is delegated, and how every action can be traced.

Because the question is no longer simply whether an agent can act. It is whether, when it does, the organization can still answer who.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.