Vishal Sharma’s Zero-Trust Warning: AI Agents Need Proof of Control

Vishal Sharma is challenging a familiar security promise: telling AI agents to follow rules does not establish that those rules actually held. Vishal Sharma’s zero-trust warning concerns AI agents, systems that use models and software tools to act toward a goal. The Queen’s University Belfast researcher asks what evidence remains when an agent claims it deleted information, respected a restriction, or completed an authorized task.

The argument puts enterprise buyers and developers under pressure to distinguish cooperation from enforceable control. An agent that reports success has supplied an answer. A system that independently records the relevant operation has supplied something buyers can investigate. Those outputs deserve different levels of confidence.

The historical reference is NIST’s zero-trust architecture, a security approach that rejects automatic trust based on network location or ownership. Sharma’s challenge concerns how that principle survives when agents interpret information, delegate work, and carry context between tasks. The central tradeoff is concrete: useful autonomy needs access, while accountable autonomy needs boundaries that remain effective when the model makes a mistake.

Vishal Sharma’s Zero-Trust Warning Starts With Missing Evidence

Sharma’s university-sponsored agent security analysis, published by IEEE Spectrum, questions how organizations verify agent behavior. Its sponsorship matters: readers should treat it as an institutional contribution to the debate, rather than independent validation of a commercial security system.

The article describes agents operating under an orchestrator, software that coordinates their tasks. It raises the possibility that later prompts retrieve information an agent was previously instructed to forget. It also reports an internal Queen’s University Belfast experiment in which agent-orchestrated de-authentication attacks took two to three seconds. De-authentication attacks interrupt a device’s authenticated wireless connection.

The article’s strongest contribution is its demand for evidence, while its experimental claims need more detail before supporting broad conclusions.

The published account does not provide enough methodology to establish a general attack-speed benchmark. Its context-recovery discussion also does not establish that physically erased information was reconstructed. Information remaining accessible somewhere in a workflow presents a different problem from recovering data that no longer exists.

That distinction should shape the response. A statement about forgetting needs a defined object: a message, a stored record, an accessible document, or a model’s learned behavior. Without that definition, organizations cannot agree on what a successful deletion would look like.

Consider a hypothetical client-profiling assistant. A user withdraws permission to use an earlier interview. The assistant confirms that it will disregard the interview, then produces a recommendation resembling its earlier assessment. That resemblance alone cannot establish whether the assistant retrieved the interview, retained a summary, or independently reached the same conclusion.

An investigation would need to examine what the system actually retained and accessed. The generated explanation might offer a clue, but the explanation itself would not settle the question. The disputed behavior concerns the machinery surrounding the answer, including which records remained available.

For buyers, this changes the evidence worth requesting. A polished demonstration can show that an assistant responds correctly during a prepared session. A controlled failure test can reveal whether a restriction survives an unexpected request. Those demonstrations answer different procurement questions.

The news value lies in that change of emphasis. Sharma directs attention toward the point where a verbal promise becomes an operational claim. Once an agent handles sensitive information or consequential actions, that point deserves explicit examination.

It also creates a fairer standard for vendors. A supplier should not need to promise that its model never produces an undesirable response. It should be able to explain the limits of its deployment and provide evidence appropriate to those limits.

Zero Trust Still Applies, but Identity Cannot Settle Intent

NIST’s zero-trust architecture, published in August 2020, focuses protection on resources rather than assuming a trusted internal network. Its account separates authentication, establishing identity, from authorization, determining permitted access.

That framework does not become obsolete because software can interpret natural language. It supplies a useful starting point: an agent’s location inside an organization does not automatically justify access to its resources.

The analytical problem is how much authority an authenticated agent should receive for the task currently underway.

Imagine an assistant authorized to prepare a supplier comparison. Reading approved proposals fits that assignment. Sending a confidential negotiation brief to a supplier raises a separate question, even if the same assistant possesses the technical ability to send email.

Successful authentication would establish which account attempted the send. It would not, by itself, establish that the user intended that particular disclosure. The security discussion therefore needs to examine the requested action and the authority supporting it.

This is where agent deployments complicate familiar enterprise decisions. A human instruction can describe an outcome without enumerating every intermediate operation. “Prepare the comparison” leaves room for interpretation. The organization still needs to decide which operations that interpretation can authorize.

A reasonable procurement question follows: what happens when the assistant chooses an unnecessary step? The answer should identify the component responsible for allowing or rejecting the operation. A promise that the assistant usually chooses sensible steps addresses behavior, while the buyer is asking about authority.

The same reasoning applies to delegation. Suppose a coordinating assistant asks another agent to research supplier history. Does that request carry permission to inspect confidential contracts? Does it permit onward delegation? Which original restriction remains visible to the receiving service?

These are hypothetical design questions, not findings that every agent platform handles delegation incorrectly. Their purpose is to expose assumptions before buyers grant broad access. A deployment can appear orderly while leaving its authority model poorly specified.

Security teams consequently face a scope problem. Assessing an agent as a single application might overlook meaningful differences between reading, editing, sending, and deleting. Assessing every harmless operation manually would create a different burden. The useful evaluation lies between those extremes.

Product teams should therefore expect questions about the relationship between task intent and executable permission. A customer asking for that relationship is requesting a system property, not merely another model instruction.

Vishal Sharma’s zero-trust warning is most useful when read through this lens. It challenges organizations to make their assumptions inspectable without claiming that all existing access-control principles have failed.

Memory Makes the Tradeoff Harder to Ignore

OWASP’s AI agent security guidance addresses memory isolation, expiration, sensitive-data handling, and authorization outside an agent’s context. Context means the information supplied to the model while it generates a response.

The guidance also identifies memory poisoning, the persistence of malicious information that influences later behavior. That concern connects retained information with future actions, rather than treating each response as an isolated event.

For enterprise buyers, the unresolved tradeoff is how much useful history an assistant should retain and under whose continuing authority.

Consider a hypothetical research workflow that turns interviews into a project brief. Historical notes help the assistant avoid repeating questions and preserve decisions. Those benefits create a legitimate reason to retain information. They also make withdrawal requests more complicated to evaluate.

Suppose an interview participant requests removal of a sensitive statement. The buyer needs to know which promise the product offers. Removing the original transcript, excluding it from future search, and revising a derived brief are distinguishable outcomes.

A meaningful contract would specify the applicable outcome. A demonstration would then test that outcome directly. Asking the assistant whether it remembers the statement would provide weaker evidence because the question relies on the same interface whose behavior is disputed.

This distinction matters for ordinary knowledge work as well. Someone choosing a personal knowledge base needs to understand how collection, retrieval, and removal relate. Convenience does not answer those questions, and a product category does not establish a security guarantee.

There is also a tension between investigation and minimization. An organization may want enough history to explain a consequential recommendation. It may simultaneously want to avoid keeping unnecessary personal information. Neither objective disappears because an assistant performs the work.

A hypothetical investigation illustrates the difficulty. A customer disputes a recommendation after the underlying interview has been removed. Investigators need an account of which authorized evidence informed the decision. Keeping every raw record forever would undermine the removal promise; keeping nothing would frustrate the investigation.

The editorial implication is that “memory” deserves more precise product language. Buyers should expect descriptions of the records involved and the guarantees attached to each. A single switch labeled “forget” leaves too much room for incompatible expectations.

The commercial pressure falls on vendors selling continuity across projects. The more useful that continuity becomes, the more important its boundaries become to a customer evaluating sensitive work. A memory feature’s value and its governance requirements grow together.

Sharma’s question therefore reaches beyond an unusual attack scenario. It exposes a basic purchasing issue: whether an organization can verify the handling of information after the conversation has moved on.

Browser Research Shows Why Architecture Changes the Stakes

University of Washington researchers Franziska Roesner and David Kohlbrenner examined browser origin boundaries across seven agentic browsers. Their work concerns the same-origin policy, a browser rule separating mutually untrusted websites.

Their April 2026 account describes experiments conducted in late January and early February. It reports a cross-origin attack demonstration involving ChatGPT Atlas in Agent Mode. For several other products, it identifies attack preconditions rather than equivalent completed attacks.

The scenario depends on specific conditions, including successful prompt injection, an attempt to make an agent treat untrusted content as instructions. The tested versions and configurations matter. These findings should not become an unsupported statement about every current browser release.

The broader architectural question is whether an assistant’s access creates a path that ordinary website code would not possess.

For buyers, that question offers a more useful comparison than a generic ranking of model intelligence. A capable assistant might operate within narrow access boundaries. Another deployment might expose broader information while relying more heavily on the assistant’s judgment.

Those configurations present different purchasing decisions even when their demonstrations look similar. Both might summarize a page successfully. Only a closer examination would reveal what additional information each assistant can reach during that task.

Consider a hypothetical employee asking for a summary of a public supplier page. The intended output concerns that page. If the workflow also permits access to private business material, evaluators need to understand why that access exists and what constrains its use.

The employee’s request supplies a useful reference point. It defines the business purpose against which extra access can be assessed. A successful summary does not answer whether the system exposed more information than the assignment required.

This is also why comparisons need careful language. Researchers identifying a possible route to harm have established something worth investigating. They have not necessarily established a successful attack against every product sharing one design feature.

A buyer should apply the same discipline to vendor responses. A patched example can close a demonstrated route without establishing that every related route has disappeared. Conversely, an older research finding should not automatically be presented as an unresolved vulnerability today.

The lesson for the current debate is methodological. Security claims become more informative when they identify the boundary tested, the conditions involved, and the observed outcome. Product names alone cannot carry that explanation.

That supports Sharma’s demand for proof while adding an important limit. Evidence should remain attached to the system and circumstances that produced it. Extending it further requires additional testing, not stronger rhetoric.

Better Model Behavior Does Not Settle the Containment Question

Anthropic’s November 2025 account of prompt injection defenses describes training, detection systems, and adversarial testing for browser use. The company explicitly acknowledges that browser agents remain vulnerable.

Its May 2026 discussion of agent containment distinguishes model defenses from restrictions on the environment where an agent operates. Containment means limiting what a system can reach or do. Anthropic describes using environmental boundaries alongside measures intended to improve model behavior.

These are vendor accounts of its approach. They establish the company’s stated security rationale, rather than independent proof that every deployment achieves the intended protection.

The important comparison is between reducing the chance of an error and limiting the consequences when an error occurs.

A hypothetical document assistant makes that distinction concrete. Better judgment might help it reject a deceptive instruction inside a proposal. An access restriction might prevent it from obtaining an unrelated confidential document regardless of how it interprets that instruction.

Those outcomes answer separate questions. The customer wants sensible behavior during legitimate work. The customer also wants a defensible answer about what happens during failure. A thorough evaluation should examine both.

This creates a practical challenge for procurement presentations. Model demonstrations are easy to understand because they show visible behavior. Environmental restrictions can look less impressive until an evaluator asks the system to cross a prohibited boundary.

A convincing demonstration would make the attempted crossing visible. Evaluators could then examine what blocked it, what evidence remained, and whether the legitimate assignment could continue. The rejection itself would be only part of the result.

The assessment should also consider the cost of restrictions. A tightly limited assistant might require additional user input or fail to complete an otherwise reasonable task. That does not make the restriction wrong. It makes its operational effect part of the buying decision.

Likewise, frequent interruptions are not automatically evidence of superior security. An interruption deserves attention when it helps a person understand and authorize a meaningful consequence. A vague approval request may leave the underlying decision just as unclear.

The useful buyer question is therefore specific: which proposed action is awaiting whose authority, and what exactly changes after approval? The answer should remain understandable to someone responsible for the business outcome.

This framing avoids an artificial contest between smarter models and stronger boundaries. Customers benefit from both, but should ask suppliers to explain what each contributes. Improvement in one area does not establish improvement in every other area.

It also sharpens the competitive pressure. Vendors selling broader autonomy need evidence proportionate to the authority their products request. The burden grows with the consequences of a mistaken action.

Vishal Sharma’s zero-trust warning fits that debate without settling it. The issue is whether the deployment supplies a credible account of control when cooperative behavior stops being enough.

The Next Evidence Should Come From Failure Tests

Over the next three months, the most useful signals will concern reproducibility, enforcement, and behavior under realistic failure conditions. These are editorial watch points, not announced release commitments.

The strongest evidence will explain what failed, what remained protected, and whether legitimate work still finished.

First, watch for a reproducible account of the Queen’s University Belfast experiment. A fuller publication would ideally identify the equipment, configuration, timing method, and baseline used to assess the reported attack speed.

That evidence would strengthen the experimental claim if independent teams obtained comparable results under stated conditions. A narrower result would still be informative. It would help readers separate a particular laboratory observation from a general claim about agent-assisted attacks.

The same standard applies to context recovery. A useful test would define what information was removed, where it had existed, and which retrieval paths remained. Without those details, apparent recollection leaves too many explanations open.

Second, watch for product releases that make authority boundaries easier to inspect. The relevant signal is a documented change tied to a testable restriction. A new security label, by itself, does not supply that evidence.

For example, a hypothetical release might demonstrate that an assistant can prepare an external message while a separate component controls its transmission. Evaluators would still need to examine the recipient, content, and authorization conditions covered by that restriction.

Such evidence would strengthen the case that vendors are translating general security principles into deployable controls. A release that merely adds another instruction would provide less support for claims about independently enforced limits.

Third, watch for independent evaluations that test recovery alongside attack resistance. Blocking an unwanted operation is valuable. Buyers also need to know whether the system can recover without repeating the attempt, losing authorized work, or requiring excessive intervention.

A hypothetical evaluation could compare the same assignment before and after an access restriction. The result should describe both prohibited actions and legitimate completion. Otherwise, a system that accomplishes little might appear secure for an unhelpful reason.

Results showing bounded harm and successful authorized work would strengthen the case for practical autonomy. Results showing that useful completion requires broad, poorly explained access would expose a continuing tradeoff.

These signals matter because the current argument can otherwise become circular. Researchers ask for verification. Vendors describe safeguards. Buyers receive assurances without a common account of what those assurances cover.

More precise evidence would allow a narrower, more productive disagreement. One deployment might suit drafting and research while another supports consequential operations. The justification should identify what each system can establish about its behavior.

For developers, the immediate implication is to make security claims testable before expanding an agent’s responsibilities. For enterprise buyers, it is to connect the requested evidence with a specific business consequence. For knowledge workers, it is to understand the authority attached to an assistant before assigning sensitive work.

Before your next agent pilot, choose a disputed action and define the evidence that would resolve it. Consider an unauthorized recipient, a withdrawn document, or a request that exceeds the original assignment. Ask the supplier to show what happens, where the restriction operates, and what record remains afterward. Then assess whether the authorized task still completes. Treat the demonstration as evidence about that deployment and configuration, with limits stated clearly. Vishal Sharma’s zero-trust warning provides a useful starting question for that conversation: when an assistant says it followed the rules, what can someone else actually verify?