What to Look for When Buying AI Security: Can Permissions Be Constrained and Fixes Verified?

Behind Spending Expectations, Connections Already Need Managing

The a16z survey asked 100 CISOs at companies with more than 1,000 employees for their assessments of the work ahead in 2027. Of those surveyed, 87% expect security spending to increase, and 45% plan to buy new security products for internal AI agents or upgrade existing ones within the next twelve months. Current usage deserves closer attention: 83% report already using coding assistants or agents in production, and 55% have connected agents to business applications through MCP servers or other means. My judgment is that security for internal agents already has concrete use cases behind it: procurement discussions concern connections and permissions that are already in use. But these percentages describe only the surveyed sample, and spending expectations and purchase intentions cannot be treated as approved budgets or records of completed deals.

Evidence: [1]

Permission Controls Must Apply to Every Request

How can we judge whether these products solve the problem? OWASP identifies excessive functionality, permissions, and autonomy as causes of excessive agency. It recommends limiting tool functionality and downstream permissions, operating within the specific user’s authorization, and requiring human approval before high-impact actions are executed. Crucially, downstream systems should check authorization for every request; the language model must not decide for itself whether a request is allowed. This suggests a procurement evaluation criterion: a product should explain whose identity an action uses, what permissions it has, and where authorization is enforced. This criterion depends on the controls covering the downstream systems actually being called.

Evidence: [2]

Seeing Actions Also Requires Being Able to Restrict Them

Logs and monitoring help detect anomalies, trace actions, and support response. OWASP also makes clear that logging alone cannot prevent excessive agency. A complete activity history therefore demonstrates only some observability; it does not establish that permissions are constrained. An evaluation can test a specific boundary: when an agent authorized to read and investigate attempts to modify, send, or delete, must it still obtain the corresponding authorization? These are control mechanisms that should be tested. The available evidence does not establish that any particular vendor has implemented them fully, or that these measures can eliminate all risk.

Evidence: [2]

Remediation Must Extend Beyond Deployment

Vulnerability remediation has similar limits on what the evidence establishes. NIST’s enterprise patch management guide includes identification, prioritization, acquisition, installation, and verification in a single process: check authenticity, integrity, and operational impact before deployment; confirm after deployment that the patch was successfully installed and has taken effect; then continue monitoring whether the patch remains in place and whether system behavior changes. Installation may also cause side effects or require a rollback. From this, I infer that evaluations of AI remediation tools should ask how they connect testing, deployment, verification that a fix has taken effect, and subsequent monitoring. Finding a vulnerability, generating a ticket, or generating a patch is insufficient on its own to prove that the risk has been eliminated. The guide itself does not measure the effectiveness of AI agents’ remediation.

Evidence: [3]

Buyers Favor a Starting Point, but Vendor Outcomes Remain Unsettled

In the survey, 44% of respondents consider existing security platforms first when looking for AI security capabilities, while 21% consider AI-native vendors first. This supports the conclusion that existing platforms more often serve as the starting point for evaluation, but their share of completed deals cannot be inferred from it. a16z also discloses investments in Armadin and Neo. Related case studies should be read with that context and cannot serve as independent verification of effectiveness. The permission constraints and verification of fixes proposed here are product evaluation criteria derived from security control requirements. Records showing whether they actually influence purchases, renewals, or vendor replacements are still lacking. Only by linking these capabilities to actual deployment performance, contracts, and renewal outcomes can we assess further which vendors secured the budget.

Evidence: [1] [2] [3]

What to watch next

• Whether purchase and renewal records show that surveyed companies’ spending expectations and purchase intentions translated into actual spending.
• Whether product testing shows that downstream systems reject requests beyond the granted authorization and that high-impact actions receive approval before execution.
• Whether remediation cases provide records of pre-deployment testing, verification that patches were installed and took effect, ongoing monitoring, and rollbacks where necessary.
• Whether completed-deal and vendor-replacement records support the view that existing platforms’ advantage in initial evaluations carries through to the contract stage.