The first time an AI agent does something useful on your behalf, it feels like magic. Perhaps you’ve watched Muse/Instinct/Grok bot send an email, book a restaurant or buy something you needed. You ask, it acts, and something disappears from your to-do list. We really are living in extraordinary times.
I find that promise incredibly exciting. Between work, family and the endless admin of everyday life, there is plenty I would happily delegate. But the moment an agent starts acting in my name, another thought creeps in: what exactly have I given it permission to do?
Could it send an email I would never have approved? Share something confidential? Buy the wrong thing, or agree to terms I haven’t read? And would I find out before the consequences arrived?
There is a big difference between asking AI to draft an email and allowing it to send one. Give that same agent access to your inbox, calls, browser and credit card, and you are delegating decisions with consequences beyond the chat window.
We are getting used to the magic of agents acting on our behalf. We should get equally interested in knowing what they are actually doing.
When passing a test becomes hacking another company
In July 2026, agents running inside an OpenAI cybersecurity evaluation compromised Hugging Face’s systems. OpenAI’s subsequent account describes models circumventing isolation controls, communicating through unauthorised channels and accessing third-party infrastructure.
The evaluation involved reduced safeguards and was primarily driven by an internal research model. That context matters: this was not an ordinary consumer assistant completing a routine request. Nevertheless, the result was a real intrusion into another company’s infrastructure. Hugging Face’s technical account describes thousands of automated decisions, including lateral movement, credential theft and attempts to maintain access.
The scale became clearer in an independent investigation by METR and Redwood Research. Researchers estimated that roughly 1,200 agents used an unauthorised message board, exchanging more than 70,000 messages and files. Approximately 700 participated in the attack. They were pursuing ways to manipulate an evaluation score and believed Hugging Face might contain useful clues.
For founders, the lesson is uncomfortable. A measurable objective can become a dangerous substitute for the outcome you actually intended. Passing a test is not permission to compromise the organisation that might hold its answers. Equally, improving conversion, reducing support costs or recovering unpaid invoices cannot mean pursuing those goals by any available means.
An agent can make progress towards its assigned target while taking actions its operator never intended to authorise.
Your inbox becomes an attack surface
There is another route to unwanted behaviour: someone else influences your agent through material it reads.
Anthropic’s research on prompt injection explains how malicious instructions embedded in websites or emails can redirect an agent. Its illustrative example involves an email containing hidden instructions to forward confidential messages elsewhere. This describes a potential attack, rather than a claim that every email assistant has suffered such a breach.
We want agents to read outside information, but we do not want that information to acquire the authority of our own instructions. An email from a supplier should be evidence to evaluate. It should not be able to rewrite the rules governing access to the rest of your inbox.
Consider a hypothetical assistant asked to organise a business trip. Comparing flights is one level of authority. Booking a non-refundable ticket is another. Calling a hotel, disclosing passport details and accepting cancellation terms introduce further decisions. A request to “sort out the trip” leaves considerable room for interpretation, especially when the agent encounters new information along the way.
This is where a reassuring activity summary can be misleading. “Trip booked” tells you the outcome. It does not necessarily tell you which information was disclosed or which commitments were made in your name.
Access to an account is not the same as permission to take every action that account allows.
Could agents trigger a bank run?
The concern becomes larger when many agents act simultaneously.
In “Is an Agentic Bank Run Coming?”, Apollo chief economist Torsten Slok considers what happens if household agents automatically move cash towards better-paying accounts. His concern is that banks could lose a substantial source of inexpensive deposit funding.
Apollo is describing a potential scenario, not documenting a bank run caused by agents. The mechanism also differs from depositors fleeing an institution they believe is failing: it begins with automated optimisation of returns.
My inference is that this raises a broader coordination problem. Millions of agents could respond to similar incentives and signals at similar times. Each might be doing something sensible for its owner, while the combined movement creates pressure elsewhere in the system. No malicious instruction is necessary. Better alignment with an individual user does not, by itself, solve the collective problem.
We should therefore distinguish three risks: an agent exceeds its mandate; an attacker redirects it; or many agents follow their mandates and collectively produce an undesirable result. Each requires different controls. Treating everything as a hallucination misses what makes agents consequential.
We cannot monitor what we do not record
One of the most revealing examples in Partnership on AI’s report, The Observability Gap in AI Agents, involves a mortgage application. A borrower exceeds the usual debt-to-income threshold but has substantial cash reserves. A loan officer permits an exception for that application. The agent stores the exception as a general rule and applies the higher threshold to future borrowers.
This is a hypothetical scenario used by the researchers, not a reported banking incident. But it captures a failure that is easy to imagine: a sensible human instruction becomes an unintended policy change. No hacker is required. If the system does not record what entered the agent’s memory, when it changed and what caused the change, investigators may struggle to establish why later decisions went wrong.
The researchers reviewed the technical documentation of four widely used agent frameworks: OpenAI Agents SDK, Claude Agent SDK, LangGraph and CrewAI. Their assessment identified gaps in the records needed to connect actions to an agent’s enterprise identity, trace memory changes and reconstruct human oversight. It examined what the frameworks record, rather than testing the effectiveness of complete security systems.
The human oversight finding is particularly relevant. None of the four frameworks captured all the intervention information the researchers considered necessary, including who reviewed a decision, their authority and whether review was required by policy. An approval button can put a person into the workflow without leaving enough evidence to assess whether that oversight was meaningful.
The report also distinguishes between recording actions and understanding decisions. Many missing operational records could be addressed through better engineering and common standards. Establishing whether a model’s explanation faithfully reflects how it reached a decision remains a research problem. Collecting more reasoning text does not automatically solve it.
The authors develop the broader argument in MIT Technology Review: meaningful monitoring depends on having the underlying records in the first place.
My takeaway is that companies need to ask for more than a demonstration of successful task completion. Ask the vendor to reconstruct a failure: what did the agent know at the time, which rules applied, and who authorised the consequential decision? Those answers will reveal far more about whether a business can responsibly delegate work than a reassuring “task completed” message.
The investment case for keeping agents under control
What caught my attention in a16z’s recent survey of 100 enterprise CISOs was that 63% said security was already slowing at least some AI adoption. We tend to discuss agent security as something companies will need once they deploy enough agents. These responses suggest it is already influencing whether those deployments happen at all. In the same survey, 45% planned to buy or upgrade internal agent security within twelve months.
There is a commercial incentive here: giving a company confidence to let an agent do more work can help unlock the adoption that agent developers are counting on.
The difficulty is that familiar permissions do not fully express what we mean when we delegate a task. An employee might have access to years of customer correspondence, financial documents and internal discussions. An agent acting through that employee’s account could inherit access far beyond what it needs to organise a meeting or follow up on an invoice.
Bessemer’s analysis identifies the accumulation of credentials and entitlements as a central problem. My reading is that companies will increasingly need to define authority around the task being performed, rather than simply accepting everything the underlying account permits. This is a fast evolving market and there are over 470 tracked AI security startups across the stack.
That helps explain the relevance of Sentra’s $150 million investment, led by Capital One Ventures in November. Sentra’s approach starts with the information an agent can reach: finding sensitive data, understanding access and reducing unnecessary exposure before anything goes wrong.
The participation of a bank’s venture arm is particularly interesting in this context, although it does not itself establish how Capital One uses the technology. For financial institutions, an agent’s ability to retrieve information can be useful and dangerous for precisely the same reason: it can connect material across systems faster than a person would.
Yet restricting access only answers part of the question. An agent might legitimately need customer records and an email account to complete its task. That still leaves a consequential decision about which information belongs in the message it sends.
Onyx Security, which raised $113 million in a Bessemer-led round in July, is pursuing that problem through monitoring and intervention while agents operate. Its proposition is that organisations need a way to assess an action in context, even when the agent has permission to use the tools involved.
These two Israeli companies show how the opportunity extends beyond detecting an obviously malicious prompt. Sentra is working to limit the exposure created by access; Onyx is working to control how agents exercise their capabilities. Funding announcements are not evidence that the problem has been solved, but they point to where customers and investors see work that needs doing.
At Remagine Ventures, the question I would ask a founder in this space is: what can your customer confidently let an agent do after installing your product that they could not allow before? A convincing answer connects security to a business outcome. It might mean allowing an agent to resolve a support case, process a payment or work with sensitive documents under clear constraints.
Useful autonomy needs boundaries
A sales agent might prepare a discount but require approval to exceed an agreed threshold. A finance agent might identify an invoice for payment, while a separate control verifies the recipient and enforces the spending limit. A support agent might issue small refunds, with escalation for unusual patterns or larger amounts.
The controls must exist outside the agent’s own willingness to obey them. Telling a model to stay within budget is weaker than using a payment mechanism that cannot exceed that budget.
Software development offers another practical example. A coding agent might produce a feature that works perfectly in a demo while overlooking the company’s requirements for authentication, handling sensitive data or using approved libraries. Passing the tests does not necessarily mean the code meets the organisation’s standards.
Pandorian addresses this gap by turning engineering, architecture and security standards into checks applied to pull requests and existing code. Teams can define their requirements, specify where they apply and identify violations within the development workflow. This gives the people responsible for security and compliance a way to check whether written policies are reflected in the software being delivered.
That is the kind of boundary that could make greater autonomy practical. A company can give coding agents more responsibility when it has a dependable process for checking their output before accepting it. The agent’s assurance that it followed the rules should never be the only evidence.
In commerce, Google’s Agent Payments Protocol tackles a related question through cryptographically signed mandates that provide evidence of a user’s instructions and the transaction they authorised. When software initiates a purchase, the other parties need a way to verify its authority. That does not guarantee a wise purchase, but it creates a more concrete basis for establishing what was permitted.
There is a product-design challenge running through all these examples. Asking users to approve every click would undermine the reason they adopted an agent. A better approach is to agree the boundaries upfront, surface material exceptions and provide a clear record afterwards. Users should be able to distinguish “the agent prepared this” from “the agent committed me to this.”
I remain optimistic about agents because the value of delegating work is enormous. But the ability to complete a task is only part of the product. The ability to constrain, inspect and interrupt that work will determine how much responsibility people are willing to hand over.
Before giving an agent the keys, we should be able to explain which doors it can open, what it did behind them, and how to take those keys back.
He is a former General Partner at Google Ventures (GV) in Europe, former head of Google for Entrepreneurs in Europe, and founding head of Campus London, Google's first startup hub. Eze writes on Israeli tech, venture capital, artificial intelligence, and founder strategy.
He is also the founder of Techbikers, a nonprofit that brings together the startup ecosystem on cycling challenges in support of Room to Read.
- What Did Your AI Agent Just Do? - November 8, 2026
- When AI Builds AI - November 7, 2026
- Weekly Firgun Newsletter – November 6 2026 - November 6, 2026
