Three Questions Every Security Lead Will Ask When Evaluating Your AI Agent

When enterprise security teams evaluate your AI product, they don't care how accurate your model is. What they really care about is the entire system built around the model—and the following three questions come up almost every time.

1. What can the Agent do that the user can't?

If your Agent has tool access—shell, filesystem, or API calls—the answer is often "far more than you think."

The core issue: the Agent runs with the permissions of its process, not with the permissions of the user who issued the prompt. Most AI products don't enforce Least Privilege at the tool layer.

Security leads will quickly follow up with a series of questions: What happens when a read-only user asks the Agent to delete something? Can the Agent access data that user shouldn't see? Can it move laterally into systems the product was never supposed to touch?

These follow-ups point to a frequently overlooked fact—the Agent's permission boundary is often silently expanded far beyond what the product team realizes.

Least Privilege is a foundational design principle in information security: any subject (user, process, service) should be granted only the minimum permissions necessary to complete its current task, and only for as long as necessary. The principle was systematically articulated by Saltzer and Schroeder in 1975 in The Protection of Information in Computer Systems, and remains a core requirement of compliance frameworks like SOC 2 and ISO 27001.

In traditional software, Least Privilege is enforced through OS accounts, database roles, API scopes, and similar mechanisms. But in AI Agent scenarios, this principle is often broken: the Agent typically runs as a service process or even with high-privilege credentials, and the tools it calls (shell, filesystem, external APIs) often share the same set of credentials. The result is that even when the user who issued the prompt only has read-only access, the Agent may still perform write operations with elevated privileges. This is exactly why security leads ask whether the Agent can delete data the user has no right to delete.

2. Where are the logs?

Security leads don't want model inference logs—they want operation logs: which tool was called, what parameters were passed, what results were produced, and which prompt triggered it.

If a customer's data was ever touched by the Agent, the security lead needs the full chain from input to action. The trouble is, most Agent architectures only log model calls, not tool executions, leaving the chain broken at the most critical junction.

This isn't just a technical problem. In compliance audits and incident forensics, missing operation logs mean you can't answer "what actually happened"—which is enough to become a fatal weakness during the due diligence phase of enterprise procurement.

3. Has anyone actually tried to break it?

Note that the question isn't "have you run a scanner." Security leads who've been through vendor risk assessments know the difference between automated scanning and adversarial testing.

What they want to know is: has anyone sat down and seriously tried to make the system behave unexpectedly—prompt injection, tool abuse, data exfiltration through context?

For multi-tenant products, this question gets even sharper: Does the Agent's memory persist across tenants? Is each session isolated? Can a prompt injection in one user's context affect another user's session? The answers directly determine whether the product can pass enterprise-grade security review.

Prompt Injection is an attack vector unique to AI applications, ranked by OWASP as the top risk for LLM applications. The principle: an attacker disguises malicious instructions as data (web content, documents, email bodies, tool return values), tricking the model into treating that data as instructions and thereby bypassing the behavioral boundaries set by the developer.

Injection comes in two forms: direct injection triggered by user input; and indirect injection triggered by external content the Agent reads—for example, the Agent fetches a malicious webpage whose hidden instructions tell it to send user data to an attacker's server. In multi-tenant or shared-memory architectures, the damage is amplified: a single successful injection can poison persistent memory and thereby affect other sessions or other tenants. That's why security teams pay particular attention to whether memory persists across tenants, whether sessions are isolated, and whether tool outputs are treated as untrusted input.

These aren't really AI problems

The three questions above are, in fact, standard questions security teams ask about any software that touches production data. The only difference is that many AI teams aren't prepared with answers—and often hear these questions for the first time mid-negotiation.

That's a terrible time to learn. If you can answer these three questions before the security review begins, deals move faster. If you can't, the review itself becomes the reason the deal stalls.

For AI product teams, this means bringing security thinking forward into the product design phase, rather than scrambling when the customer's security lead is sitting across the table. Tool-layer permission controls, a complete operation log chain, and proactive adversarial testing should be infrastructure for Agent products—not after-the-fact patches.

One-line Summary

Enterprise security review of AI Agents comes down to three things: permission boundaries, operation logs, adversarial testing.

Paragraph Summary

When enterprises evaluate AI Agents, what they really care about isn't model accuracy but the entire system built around the model. Security leads almost always ask three questions: First, what can the Agent do that the user can't? Agents run with process permissions rather than user permissions, and the tool layer often lacks Least Privilege controls, making permission overreach a widespread risk. Second, where are the logs? Security teams want the full operation chain including tool calls, parameters, results, and triggering prompts, yet most architectures only log model calls, breaking the chain at critical points. Third, has anyone actually tried to break it? They distinguish automated scanning from adversarial testing, focusing on prompt injection, tool abuse, and multi-tenant isolation. These three questions are fundamentally standard security questions for any software touching production data—it's just that many AI teams aren't ready with answers. Answering them early speeds up deals; failing to do so makes the review itself the reason deals stall.