Security research · · 6 min read
Cybersecurity Startups: The Application Security Opportunity
What the NFX thesis means for teams buying security: test the workflow, inspect the evidence and verify the fix.
By Pentesty
What is NFX’s cybersecurity startup thesis?
In Cybersecurity’s Future Belongs to Startups, published in September 2026, NFX partner Gigi Levy-Weiss argues that software evolution creates openings for new security companies. He highlights application ecosystems and AI agents as areas where established approaches may struggle to adapt. NFX also argues that an initial insight must develop into a durable business advantage.
That is a useful starting point for a market discussion. It is not a comparative security benchmark. NFX is an investor and references a portfolio company in its argument. Our analysis takes a buyer’s perspective: what evidence should an organization require before relying on a security provider?
Where application security needs business context
Imagine a SaaS application with separate customer workspaces, a reporting API and an assistant that exports records. A valid login proves that a user authenticated. It does not answer whether the user may export a particular customer’s records, whether a shared link remains valid after access is revoked, or which destinations the assistant can use.
OWASP’s guidance on broken object-level authorization identifies the risk of APIs accepting an object identifier without checking the caller’s permission to act on that object. This illustrates why an assessment needs user roles and ownership rules, not just a list of reachable endpoints.
In our example, useful test preparation includes two synthetic customer workspaces, accounts with different roles and an agreed list of permitted actions. The assessor can then check whether those boundaries hold. A test result should identify which role, object and operation were involved so the engineering team can reproduce and fix the problem.
AI integrations add another set of decisions
For the assistant, also ask who authorizes tool calls and where exported data can go. A sensible answer from the model does not establish that its underlying permissions are correct. Our AI agent security checklist covers permissions, outbound transfers, memory and independent execution records.
This does not make endpoint or network protection obsolete. We recommend mapping each control to the boundary it protects. A security plan should make gaps visible instead of assuming that a purchase in one category covers every workflow.
What should a security startup prove?
Our recommendation for a focused provider is to define one important customer problem precisely enough to demonstrate progress. For example: “Can users from one customer workspace access another workspace’s exports?” is an assessable question. “We make your AI secure” leaves the scope and success criteria undefined.
For a buyer, the proof should survive a handoff to engineering. Can an owner understand the finding without a sales call? Are prerequisites documented? Can the team distinguish an observed exposure from a hypothesis? Does a retest show what changed? These questions are useful for established vendors too.
A sample report is a good place to start. Our article on getting more value from a pentest report discusses the gap between a long list of findings and a report that supports decisions.
Security vendor evidence checklist
This original Pentesty matrix is a discussion aid for procurement and security teams. It is not an industry certification, a vendor ranking or a claim that a particular tool supports every test.
| Criterion | Question to ask | Evidence to request |
|---|---|---|
| Coverage | Which user roles, APIs and integrations were actually exercised? | A coverage record separating tested, blocked and excluded paths. |
| Finding quality | Can the team reproduce the issue within the authorized scope? | Sanitized requests, responses and the conditions required to reproduce it. |
| Business impact | What data or action could an unauthorized party reach? | An impact explanation tied to the affected workflow and permissions. |
| Human review | What did a reviewer validate, and what remains uncertain? | Recorded review decisions and explicit limitations. |
| Remediation | Can the engineering owner understand and verify the fix? | A concrete recommendation, an owner and a relevant regression check. |
| Retesting | Was the original issue checked after the change? | Dated retest evidence and a clear residual-risk statement. |
To reference this matrix: Pentesty, “Cybersecurity Startups: The Application Security Opportunity,” September 17, 2026. Permanent link to the evidence checklist.
How to turn the discussion into an assessment
1. Choose a representative workflow
Select a business action with a clear owner, such as an account invitation, document export or integration setup. Document the expected access rules, connected systems and sensitive data. Agree on written authorization, test accounts, permitted techniques and stop conditions.
2. Define the deliverable before testing
Specify the evidence needed to make a remediation decision. Include tested and untested areas, failed prerequisites and the scope of human review. Use the Pentesty report-reading guide to frame questions about findings and remediation guidance.
3. Close the loop after a change
Assign an owner, review the correction and retest the affected behavior. Keep the result tied to the version or configuration evaluated. Schedule relevant reassessment when permissions, integrations or critical workflows change; choose the cadence according to risk and scope.
The NIST Secure Software Development Framework, version 1.1, describes practices that organizations can integrate into their development lifecycle to reduce vulnerabilities and address root causes. Our recommendation is to make assessment findings useful inputs to that lifecycle, including regression checks where appropriate, rather than treating report delivery as the end of the work.
Frequently asked questions
Why does NFX see an opportunity for cybersecurity startups?
NFX argues that changes in software create security problems that new companies can address before established vendors adapt. Its September 2026 essay emphasizes the application layer and agentic software. That is an investment thesis, not proof that any particular startup provides better protection.
What is application security?
Application security is the work of protecting software and the data and actions it exposes. Assessment can include authentication, authorization, API behavior, integrations and business workflows. The relevant tests depend on the application, its users and the agreed scope.
Does application security replace endpoint or network security?
No. These controls address different parts of a system. An application may have an authorization flaw even when its host is protected, while a compromised endpoint can still endanger a well-designed application. Plan coverage across the relevant layers.
How should a buyer evaluate an AI-powered pentest provider?
Ask for a clear scope, evidence supporting findings, an explanation of human review, documented coverage limitations and a retest process. Evaluate a sample deliverable against a representative workflow. An AI label or a high finding count does not establish test quality.
Sources and editorial scope
- NFX: Cybersecurity’s Future Belongs to Startups, Gigi Levy-Weiss, September 2026. Source of the investment thesis discussed here.
- OWASP API1:2023: Broken Object Level Authorization. Technical background on object-level permissions.
- NIST SP 800-218: Secure Software Development Framework, version 1.1, February 2022. Secure development practices.
Sources checked September 17, 2026. This is independent Pentesty analysis with an original evaluation matrix. References to NFX, OWASP and NIST do not imply their endorsement of Pentesty.