AI agents expose a security gap between what they read and what they can modify

The article, bylined by Adithyan RK (co-founder and CEO of Hyring) as an outside contribution to VentureBeat, makes an argument that departs from the usual debate about AI safety. Over the past two years, the conversation has almost always centered on the model: whether it is well aligned, whether it can be manipulated through jailbreaks, whether it hallucinates under pressure. According to the author, those questions remain valid, but they no longer capture the real risk that appears when organizations move from AI agent pilots to production systems. That risk does not live in the model's weights, but in the infrastructure built around it: the way the agent reads data, calls tools, writes to databases and triggers automations.

The starting point is that the interaction pattern assumed during the chatbot era —a person types a prompt, the model responds with text, a human reads it— no longer describes how today's AI systems work. Agents in production read live data sources, invoke external APIs, write to real systems and, increasingly often, act without any human supervising in real time. Each of those new capabilities is also an attack surface that simply did not exist before.

The author details several categories of risk that, he argues, have nothing to do with model quality. The first is prompt injection through connected data: when an agent retrieves content from a CRM record, a support ticket, a web page or a shared document, that content becomes part of its context, and an attacker does not need access to the model to manipulate its behavior, only access to something the model will end up reading. Instructions hidden in a PDF, in an email signature or in a product review can hijack an agent's next action just as effectively as a prompt typed directly into a chat window.

The second category is tool calls with excessive permissions. Agent frameworks typically grant models the ability to send emails, query databases, modify records or execute code, and many of these integrations are built with permissions designed for development speed —broad API keys, service accounts with far more access than the specific task requires— simply because it is the fastest way to get a demo working. In production, that same permission model means a manipulated prompt or a simple reasoning error can turn into a real action with consequences: a record deleted by mistake, a message sent to the wrong recipient, a payment triggered improperly.

The third is the fragility of trust boundaries between tools in multi-agent workflows. When several components are chained together and pass results to one another without revalidating what crosses each boundary, a model that summarizes an untrusted document and hands that summary to a second agent with write permissions on a production system is, in practice, letting an unauthenticated third party influence that system, even though no human explicitly granted it that trust.

The fourth is the lack of observability. Traditional application security assumes you can log a request, trace a call stack and reconstruct what happened after an incident. Agentic workflows, the author notes, often do not offer that possibility: reasoning traces are non-deterministic, tool-call sequences vary from one run to the next, and many teams still do not log the agent's intermediate decisions with the level of detail needed to answer a basic incident-response question: what the system actually did and why.

The fifth category is automated decision flows with no braking mechanism at all. As autonomy increases, the agent no longer merely drafts a response, it sends it; it does not just flag an anomaly, it acts on it. The cost of a single bad decision is multiplied, especially when there is no rate limit, approval gate or kill switch between the moment 'the model decides' and the moment 'the action happens'. The author insists that none of these five problems is solved by switching to a more capable or better-aligned model, because they reside in the system's plumbing, not in the model's weights.

The article frames all of this as a problem of organizational governance, not merely a technical one. Questions about AI safety usually fall to machine learning or data science teams, which are equipped to evaluate model behavior but not necessarily to take on integration security, access control or production observability. Meanwhile, security and platform engineering teams —which have decades of institutional experience securing exactly this kind of system: services calling services, scoped credentials, audit logging, incident response— are often not brought in until the agentic workflow is already in production.

According to the author, the organizations that scale AI successfully are those that close that gap early, treating an AI agent the way they would treat any new production service with write access to real systems. In practice, that translates into an unglamorous but concrete checklist: least-privilege access by default, so that if an agent only needs to read a customer record, it should not hold a credential that also lets it write to that record; sandboxing before granting autonomy, with a deliberate, supervised path toward production access rather than rolling out full permissions just because the demo worked; human approval gates for high-consequence actions, understanding that autonomy is not binary and that a workflow can let the model draft an action —a refund, an email to a customer, a change to a live system— while requiring explicit approval before executing it, with the threshold set by the action's blast radius and not by how convincing the model sounds.

Two further recommendations round out that list: log at the decision level and not only at the outcome level, capturing what the agent read, which tools it invoked, what arguments it used and why, so that after an incident the question of what happened and why has an answer that does not rest on guesswork; and treat any third-party data as untrusted input, applying to a web page, an uploaded file or an email the same suspicion one would apply to user input in a traditional web application, because functionally that is exactly what it is. Finally, the author proposes explicit braking mechanisms —rate limits, anomaly detection and the ability to manually override automated actions— so that a single flawed chain of reasoning cannot multiply into thousands of erroneous actions before a human notices.

The article's conclusion is that none of this is exotic: it is the same engineering discipline that has governed production software for two decades —scoped permissions, input validation, observability, staged rollouts, human review of consequential actions. What is new is that there is now, inside that system, a probabilistic and occasionally unpredictable model taking part in the decisions about what happens next. That, the author argues, is why the workflow around the model deserves far more scrutiny than it gets today: a more capable model does not make an over-permissioned integration any safer, and a better-aligned model does not fix the absence of an approval gate. As AI agents take on more autonomous and consequential work inside real companies, the organizations that will suffer the biggest problems will not necessarily be those using the weakest model, but those that never asked whether the system built around their model was designed to be secured.