Businesses are moving AI agents out of pilot projects and into everyday work. Unlike a chatbot that answers questions, an agent is given a goal and the access to pursue it. It reads files, queries systems, sends messages, and takes actions on a company’s behalf, often faster than any person can follow. Every one of those steps begins with data, and every one raises the same question: what information has an organisation placed within an agent’s reach?
That question lands at a fitting moment. Cybersecurity Awareness Month has long steered attention to familiar habits such as strong passwords, phishing vigilance, and careful handling of company information. This October, data security is no longer only about what people do with company information, but about what software acting for them is allowed to touch, record, and change.
For this first instalment of UpTech Media’s Inside the Firewall, three leaders from different corners of the security and data landscape weigh in on the problem: Jason Duerden, Vice President for ANZ of SentinelOne; Matthew Oostveen, Chief Technology Officer for Asia Pacific & Japan of Everpure; and Sunil Chavan, Vice President for Asia Pacific & Japan of VAST Data. Each comes at it through a different lens: identity and authority, the data layer and recovery, and the architecture agents run on. Yet they keep returning to the same questions: what can an agent reach, what did it do, and how quickly can it be stopped?
The agent that won’t take no for an answer
SentinelOne’s Duerden starts with three questions he believes every business should be able to answer before an AI agent goes live.
Duerden said, “Every business should be able to answer three questions before an agent goes live: what can it do, whose identity and authority is it using, and how quickly can that authority be withdrawn? That means giving the agent its own managed identity and access only to the data and systems it needs.”
Access should also be removed when it is no longer needed, he added, and high-impact or irreversible actions should require human approval. Testing matters just as much: in a controlled environment with dummy data, businesses should check whether an agent can be tricked into exposing sensitive information or following malicious instructions hidden in emails and documents, and repeat those tests as models, connected tools and permissions change.
The step companies most often skip, according to Duerden, is the discipline behind all of this. In his words, “A major mistake is giving an agent broad access for convenience, then assuming instructions alone will keep it within its brief. The Medicare portal incident shows why that assumption is risky.”
To show why that assumption is risky, he pointed to what he described as the Medicare portal incident. An OpenAI agent was tasked with researching public medicines spending, but after being denied access to information, it found another way into the portal and reached non-public files.
“A task that appears harmless can still lead to unauthorised activity if the agent has the tools and opportunity to keep trying. Companies need to treat agents as identities that can hold real authority, not software features. That means every deployed agent has a named owner, defined authority and an incident response process that covers the providers and systems it relies on,” he said.
Without an accountable person behind it, he warned, an agent can become one more account with access to company systems and no one responsible for keeping it in check.
That is also why he ties an agent’s freedom to the organisation’s ability to control it. “An agent’s freedom should be tied to the organisation’s ability to observe and control it. Start with clearly defined, lower-risk tasks, such as drafting an email for a person to review, and consider what data the agent needs to access even for those tasks,” Duerden said.
If instructions can’t hold an agent back, the limit has to sit somewhere harder to talk around, and that raises the question of where it should sit. Everpure’s Oostveen has a clear answer: the data itself.
Security moves to the data itself
Everpure’s Oostveen starts where every agent’s work starts: with the information it can reach.
Oostveen said, “Every action an AI agent takes begins with data. Organisations need to know what information it can access, what it is authorised to do and how they will recover if something goes wrong.”
That means classifying sensitive information, enforcing access controls at the data layer, and maintaining an audit trail. It also means being clear about where an agent’s authority ends, particularly when the action can’t be undone.
On approvals, he was specific. In his words, “High-impact actions need clear approval boundaries, alongside the ability to stop the agent when necessary. Destructive actions, such as deleting data or protected recovery points, should require verified human authorisation, so that neither an attacker nor a misbehaving agent can act alone,” he said.
Safeguards are only worth having if they work under pressure, he added, and that is why he puts recovery on the checklist before launch.
Oostveen said, “Recovery must also be tested before deployment. Protected, immutable recovery points and an isolated recovery environment are essential safeguards, but teams need to demonstrate that they can restore critical services under pressure.”
The step companies most often get wrong, according to Oostveen, is one of timing: the most common mistake, he said, is treating security as something to add once the agent is already working, when an agent operating on poorly governed data can expose, corrupt or act on sensitive information at machine speed, turning an existing weakness into a business problem.
For Oostveen, that points to where security has to sit. Agents don’t operate as single applications enforcing fixed rules, he said, so security has to move from the application to the data itself.
“They call multiple tools and pull data from different sources in unpredictable combinations, so access policies have to travel with the data. Governance, security, and immutability need to be built into the data layer, which is ultimately the last line of defence when everything else is bypassed,” he concluded.
He advised starting with a clearly defined use case, limiting the agent’s permissions to what that task requires and keeping human oversight over consequential decisions, with autonomy expanding as the controls prove themselves.
Controls at the data layer matter more as agents move faster than the people overseeing them, and that is where VAST Data’s Chavan picks up the argument.
Agents remove the limits security quietly assumed
VAST Data’s Chavan starts with an assumption that sits underneath much of today’s security: that whatever is acting on company data behaves like a person.
Chavan said, “A common mistake is expecting agents to be limited the way people are. Much of today’s security quietly assumes human fatigue and pace, but agents retry endlessly, act at machine speed, and multiply on demand.”
Safeguards, in his view, put back the limits that agents don’t have on their own. He pointed to isolated sandboxes that limit the blast radius when something goes wrong, identity-based policies that restrict the data and tools an agent can reach, and the ability to roll back and restore a system after a lapse without losing customer data.
The problem does not end with what an agent can reach, he said. It extends to what the agent creates. “Companies must stop treating agent security and data security as separate problems. Agents generate new data, including responses, agent-to-agent messages, and logs, which creates new places for sensitive information to leak,” Chavan continued.
That makes the record of what an agent does as important as the controls around it, according to Chavan, because a record is what allows blame to be settled with proof rather than guesswork.
He put it this way, “When something goes wrong, responsibility should fall on whichever side failed on its part. Sorting that out takes evidence, so every agent action should leave a tamper-proof record of what it did, whose identity it used, and which policy allowed it.” he emphasised
The timing of those controls matters just as much, he argued. Policy has to apply before an agent acts, not only be reviewed afterwards, and that determines whether an organisation can rely on what its agents produce.
Chavan said, “Companies must stop treating agent security and data security as separate problems. Agents generate new data, including responses, agent-to-agent messages, and logs, which creates new places for sensitive information to leak.”
Caution has a cost of its own, organisations that keep agents on a tight leash are right to be careful, he said, but caution that never reaches production delivers no value, and governance should be the infrastructure that makes ambition safe.
The one thing that has to change
Looking ahead, the leaders name the one thing that needs to change in how companies approach AI and data security before agents become commonplace. Their answers pointed to accountability, to where security sits, and to how far it reaches.
For SentinelOne’s Duerden, the change is accountability. “Businesses need these controls before deployments multiply across departments and vendors, because adding accountability after hundreds of deployments are live is far harder than building it in from the start,” he stated.
For Everpure’s Oostveen, it is where security sits. In his words, “Security has to move from the application to the data itself. AI agents don’t operate as single applications enforcing fixed rules.”
For VAST Data’s Chavan, it is how far security reaches and when it acts. “Security has to extend into the data layer, with policy enforced before an action executes and every action recorded. Without that, no organisation can fully trust what its agents produce,” he said.
**
Taken together, the three leaders agree that an AI agent is only as safe as the data it can reach. Their safeguards line up: limit what an agent can access, keep a record of what it does, require human approval for high-impact actions, and be able to stop it and recover. However, the difference is where each starts: Duerden with accountability, Oostveen with the data layer, and Chavan with the machine speed and new data that agents bring.
The takeaway for businesses is to settle three questions before an agent goes live: what can it reach, what did it do, and how quickly can it be stopped. As agents move into everyday work, those answers need to be in place before deployments multiply, with an agent’s freedom growing only as fast as the organisation’s ability to control it.
