I have sat in a lot of product discovery sessions. The ones that stay with me are not the ones where a security engineer showed up with a list of concerns. They are the ones where a PM sketched out what an agent should be able to do, and no one in the room realized they were making security decisions. Not threat modeling. Not risk assessment. Just: what should this agent have access to? What should it be allowed to do? How much should it act on its own?
Those questions shape how attackable the resulting system is. They almost never get named as security decisions. That gap is what this piece is about.
Traditional software executes instructions. An AI agent makes decisions. If you are a product manager shipping agentic features in 2026, that distinction should be reshaping how you think about risk, scope, and trust, starting in discovery, not after launch.
When your team gives an agent the ability to query a database, draft and send emails, or call external APIs, you are shipping something categorically different from a recommendation engine or a smart search bar. Those older features did what their code told them to do. An agent reads context, interprets it, decides what to do next, and acts. Autonomously. On behalf of your users. The threat model that worked for your last five releases does not cover what you are building now.
According to Gartner's 2025 forecast, by 2028 over 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024. That pace of adoption means PMs are making scoping decisions about agent capabilities right now, often without the security vocabulary to evaluate what those decisions actually expose. This piece is a field guide for that gap.
The attack surface you did not draw on your architecture diagram
Most PMs carry a working mental model of where their system is vulnerable: the API endpoint, the authentication layer, the third party integration. AI agents break that model in three specific ways.
Autonomy compresses the window for intervention. Traditional software executes a defined instruction and stops. An agent executes, evaluates, decides, and continues, often across dozens of steps before a human sees any output. A single corrupted instruction early in a task does not produce one bad result. It steers the entire chain. By the time something looks wrong, the agent may have already acted on it five steps back.
Tool access raises the blast radius. Agents are not retrieval systems that hand you a summary and wait. They write calendars, commit code, send messages, trigger payments, and modify records. When something goes wrong, the consequence is not a bad response in a chat window. It is a real action taken in a live system, on behalf of a real user.
Trust boundaries shift from code to content. In conventional software, trust is enforced by logic: code checks a credential, validates a type, rejects a malformed request. In an agentic system, trust is partly enforced by a model interpreting natural language. That means an attacker's surface is not just your endpoints. It is any text your agent reads: a document it summarizes, a webpage it visits, an email it processes. Security practitioners call this prompt injection. The input field is no longer a text box on your interface. It is everywhere.
The security conversation that rarely happens in sprint planning
I have sat in enough of these sessions to recognize the pattern. Someone is mapping out what the agent needs to do, the conversation is moving fast, and four decisions get made that will define the security posture of the system. No one names them as security decisions. They are just the product spec taking shape.
Here are the four.
- Tool scope defines the blast radius of a successful attack. When you define what an agent can do, whether it can read files, send messages, call APIs, or trigger workflows, you are not just writing a feature spec. You are defining what an adversary can hijack. A useful forcing question: if this agent were acting on behalf of someone who wanted to cause damage instead of help, what could it do? That answer is the scope you are actually shipping.
- Trust levels determine how the agent handles adversarial input. Most product specs define what the agent should do when a user gives it an instruction. Very few define what the agent should do when it encounters an instruction embedded in something it reads: a document, an email, a webpage, a support ticket. These are the vectors for prompt injection. The product question is not just "what does the agent do for users?" It is "what sources of instruction does the agent treat as authoritative, and what does it treat as data?"
- Human in the loop design is a scoping decision, not a UX preference. Autonomy exists on a spectrum, and where you place the agent on that spectrum should depend on the reversibility and consequence of the action. Drafting a response and sending a response are not the same decision. Summarizing a contract and signing one are not remotely equivalent. The right question is not "should there be a human checkpoint?" It is "at which actions does the cost of a mistake justify a pause?"
- Data access scope sets the exposure surface. An agent that can read an entire customer database to answer a billing question has a much larger exposure surface than one scoped to the specific record it needs. Least privilege is typically taught as an engineering principle, but the real decision happens earlier, when a PM defines what the agent should have access to in order to do its job. Narrowing that scope is not a constraint on the product. It is part of the product.
Each of these is a question you can bring into your next discovery session without framing it as a formal security review. They are product decisions with security consequences, and naming them as such is the first step toward building agent features that enterprises will actually trust enough to buy.
The incidents are not hypothetical
If these patterns feel theoretical, they should not. The attack vectors described above are already documented in the wild, and in each case the exploit followed a capability the product team deliberately built.
- AI assistants with email access have been demonstrated to exfiltrate data and take unauthorized actions based on malicious instructions embedded in emails the agent was asked to process. The agent was doing its job: reading, summarizing, acting. The attacker simply embedded instructions inside the email body and let the agent execute. The product decision that created the exposure was not a bug. It was the feature: email read access combined with the ability to act.
- AI coding assistants have been shown to be manipulable through content in the repositories they read. A malicious comment or README entry can influence the code an agent writes or the commands it suggests. The developer sees a helpful suggestion; the suggestion was shaped by adversarial content the agent ingested upstream.
- Browser based agents have been redirected by instructions embedded in the web pages they visit. An agent sent to book a flight, summarize an article, or fill out a form can be silently rerouted by a page containing the right text in the right place.
In each of these cases, the root failure was not in the underlying model or the engineering implementation. It was the absence of constraints around what the agent was allowed to treat as instructions versus what it was supposed to treat as data. That is a product design decision. It belongs in discovery, not in an incident postmortem.
Security aware AI features are a competitive advantage
It is worth flipping the frame. PMs who understand agent security are building features that enterprises can actually purchase.
Security review is a gate in every enterprise sales cycle. AI features that cannot clear those reviews do not ship to enterprise customers, regardless of how polished the UX is. The PM who can speak fluently to trust boundaries, tool scope, and human in the loop design during a security review is the PM whose feature closes deals.
Beyond the sales cycle, users are still forming their mental models of what AI agents can do and what they can be made to do. That window will not stay open forever. Products that earn deep trust now will be the ones that visibly demonstrated they thought carefully about what their agents can be exploited into doing. Sophisticated buyers and users are already starting to notice the difference.
Building user trust is the same work as reducing risk
There is a version of user trust that marketing tries to manufacture and a version the product earns. The second one lasts. Users extend trust to an agent the way they extend it to a new colleague: slowly, based on what it does when no one is watching, and based on whether they can see what it did.
The design choices that make an agent harder to attack are the same ones that make it easier to trust. A confirmation step before a consequential action is a security control and a trust signal at once. So is showing the user what the agent read, what it decided, and what it changed. So is scoping the agent to the data it needs and saying so out loud. So is making its actions reversible. None of these are security features bolted onto a product. They are the product telling the user it can be relied on.
The teams that earn this kind of trust tend to build for legibility, not just capability. An agent that quietly does the right thing earns less trust than one that does the right thing visibly, because the user has no way to know the difference until something breaks.
One question to add to your next AI feature review
The mental model shift this requires is small to describe and hard to practice. Traditional software security asks: what can this feature do? AI agent security adds a second question: what can this feature be made to do?
The difficulty is not the question. It is when the question has to be asked. These decisions get made in discovery, and discovery is built for optimism. The room is imagining what the feature could become, and adversarial thinking runs the other way: it asks you to picture the same feature working against the user you are trying to help. Holding both modes at once does not come naturally. That is why the security decisions at the start of this piece so often go unnamed. They are not hard to understand. They are hard to remember to ask at the moment they matter.
A few practices keep the question from being forgotten. Run the abuse case during discovery, not after launch: assume the agent has been turned against its user, then trace what it could reach and what it could do. Put the second question in the spec template, next to the line for what the agent does, so it gets asked every time rather than when someone happens to remember it. And before launch, have someone hide an instruction inside the content the agent reads and see whether the agent obeys. If no one has tried prompt injection against the feature, the feature has not really been reviewed.
None of this requires a PM to become a security engineer. It requires one new line of inquiry in discovery, sprint planning, and launch review. When you are scoping an agent's permissions, ask who benefits if those permissions are abused. When you are defining its memory, ask what happens if that memory is written to by someone other than your user. When you are approving its integrations, ask whether a carefully crafted string of text could redirect its actions toward an outcome you never designed for.
