For most of the software era, cybersecurity teams had a fairly clear idea of what they were trying to protect. Employees logged into applications, applications connected to databases, servers ran software, and security tools watched those users, devices, networks, and systems for signs of suspicious behavior.
AI agents change that model because they are not simply another type of software waiting for someone to click a button. An agent can read information, decide what to do next, call tools, use credentials, open files, change records, write code, communicate with other systems, and continue working without asking a person for approval after every step.
That shift creates a much harder security question for businesses. Companies now need to figure out how to protect software that can make decisions and take action on its own.
Boston is becoming one of the more interesting places to watch this problem develop. The city already has a deep cybersecurity industry, strong enterprise software companies, major universities, AI research, and large regulated sectors such as healthcare, finance, biotechnology, and defense. Those conditions make Boston a natural test market for the next generation of agent security.
BostonBizScene reviewed public product announcements, company materials, regulatory filings, security frameworks, funding announcements, acquisition records, and research published through September 25, 2026. From that research, we identified five Boston or Cambridge organizations with clear activity at the intersection of autonomous AI and cybersecurity: 7AI, Neo, Agentic Highway, Rapid7, and Akamai.
These companies are not all building the same thing, and that is what makes the market interesting. Some are using AI agents to perform security work, while others are building systems designed to control, monitor, identify, or govern AI agents operating inside enterprises.
Taken together, they point toward a larger trend. AI agent security is beginning to separate into a business category of its own, and Boston already has companies operating across several important parts of that emerging market.
The Short Version: Software That Can Act Needs a New Security Layer
The easiest way to understand the agent-security market is to look at what changes when AI moves from answering questions to taking actions.
A normal chatbot may tell an employee how to reset an account. An agent may actually reset it.
A traditional AI assistant may summarize a suspicious email. A security agent could investigate the sender, inspect related alerts, query endpoint data, check an identity provider, search threat intelligence, decide whether the activity appears malicious, and prepare a response.
A coding assistant may suggest a command for a developer to run. An autonomous coding agent can execute the command itself.
That change from recommendation to execution dramatically increases the security stakes. The danger is no longer limited to whether the AI generates a bad answer. The more important question becomes what the AI is allowed to do after it produces that answer.
NIST has highlighted agent hijacking and indirect prompt injection as important risks for AI agents. In this type of attack, malicious instructions can be hidden inside information that an agent reads, potentially causing the agent to take actions that were never intended by the real user.
OWASP has also started treating agentic risks as a distinct security problem. Its work highlights issues such as agent goal hijacking, tool misuse, privilege abuse, weak identity controls, unsafe supply chains, and unexpected code execution.
For business leaders, the difference is straightforward. Traditional cybersecurity was largely designed around questions such as who a user is, whether a device can be trusted, whether software is vulnerable, and whether a network request appears malicious.
Agent security introduces a second set of questions. Organizations now need to know what an agent is, who authorized it, which tools it can use, what data it can reach, which actions it can take, why it took those actions, and whether risky behavior can be stopped before damage occurs.
Those questions are broad enough to support an entirely new software market, and Boston companies are already working on several parts of it.
BostonBizScene Original Research: Mapping Boston’s Emerging Agent Security Market
To move beyond individual company announcements, BostonBizScene created a small original dataset focused specifically on the Greater Boston agentic-security market.
The goal was not to build a complete directory of every cybersecurity company in Massachusetts. Instead, we wanted a conservative sample of organizations where we could verify a direct public connection between autonomous AI and cybersecurity products, platforms, or operations.
Our Methodology
We included an organization only when it met three requirements.
First, the company needed a verified Boston or Cambridge operating connection.
Second, its public product strategy had to explicitly involve AI agents, autonomous workflows, agentic software, or systems designed to control those technologies.
Third, the agentic work had to relate directly to cybersecurity rather than simply using artificial intelligence as a general product feature.
Our research cutoff was September 25, 2026.
We then grouped each company according to its primary role in the emerging market. One group includes companies using autonomous AI to perform cybersecurity work. A second group includes companies building security systems that protect or control AI agents. A third category includes infrastructure focused on identity, inventory, evidence, trust, and accountability across agent systems.
We also recorded disclosed funding and acquisition values where reliable public figures were available. These numbers represent announced financing or purchase values rather than revenue, valuation, or total market size.
The Five-Company Boston Sample
| Company | Boston-area connection | Main agent-security role | Public capital signal included in our analysis |
| 7AI | Boston | AI agents performing security operations | $166M total funding |
| Neo | Boston | Runtime control and security for agentic software | $100M launch funding |
| Agentic Highway | Boston | Agent inventory, evidence, and supply-chain trust | Not publicly disclosed in our sample |
| Rapid7 / Kenzo | Boston | Multi-agent autonomous security investigations | $25.5M acquisition value |
| Akamai | Cambridge | Identity, behavior, and edge controls for agent traffic | Not treated as startup funding |
7AI has reported $166 million in total funding following its $130 million Series A. Neo emerged from stealth in July 2026 with $100 million in funding. Rapid7 later disclosed an aggregate fair value of $25.5 million for its March 2026 acquisition of Kenzo Security.
Finding #1: At Least $291.5 Million Is Already Tied to a Very Small Boston Agent-Security Sample
When we add the publicly disclosed amounts tied to 7AI, Neo, and Rapid7’s acquisition of Kenzo, the measurable total reaches $291.5 million.
| Capital event | Amount |
| 7AI total announced funding | $166.0M |
| Neo launch funding | $100.0M |
| Rapid7 purchase price for Kenzo | $25.5M |
| Total measurable capital signal | $291.5M |
This number needs to be interpreted carefully. It is not an estimate of Boston’s total agent-security market, and it does not include Akamai’s internal spending, Rapid7’s broader AI investments, or any undisclosed financing connected to Agentic Highway.
The figure simply shows how much measurable capital is already associated with a very small group of Boston-area companies operating directly in agentic security.
That is notable because the market itself is still very early.
Capital Signal in Our Boston Sample
7AI $166.0M █████████████████████████████████
Neo $100.0M ████████████████████
Rapid7 / Kenzo $25.5M █████
——————————————
Measured total $291.5M
The distribution is also revealing. Around 57% of the measurable amount in our sample is tied to 7AI, roughly 34% is connected to Neo, and about 9% comes from the disclosed Kenzo acquisition value.
This is clearly not a mature or evenly distributed market. Capital is concentrated in a small number of companies attempting to establish strong positions before enterprise buying patterns fully settle.
That is often how important infrastructure categories begin.
Finding #2: Boston Is Developing Both Sides of the Agent Security Market
One of the clearest findings from our dataset is that Boston is not producing only one type of agent-security company.
There are really two major business questions developing at the same time.
The first asks how AI agents can make cybersecurity teams more effective.
The second asks how cybersecurity teams can make AI agents safer.
Our five-company sample can be grouped this way:
| Strategic direction | Companies in our sample | Share of five-company sample |
| Agents performing security work | 7AI, Rapid7/Kenzo | 40% |
| Security or trust controls for agents | Neo, Agentic Highway, Akamai | 60% |
This distinction matters because the phrase “agentic security” is often used as if it describes one product category. In practice, it already covers at least two very different markets.
Security operations are becoming more autonomous as AI agents take over repetitive investigations, triage, and response workflows.
At the same time, every department that deploys autonomous agents creates additional work for cybersecurity teams because those agents need identity controls, permissions, monitoring, logging, runtime policies, and governance.
Boston has meaningful activity on both sides.
Why AI Agent Security Is Different From Normal Application Security
It is tempting to treat an AI agent as simply another enterprise application. That approach misses the most important difference.
Traditional software usually follows paths that developers defined in advance. An agent is designed to choose among different paths based on changing information.
The model can interpret data, select a tool, decide which parameters to use, examine the result, revise its plan, and choose another tool. Developers may understand the possible range of behavior without knowing the exact sequence of actions that will happen in every situation.
That flexibility is one of the main reasons agents are useful. It is also one of the main reasons they create a new security problem.
A Safe Individual Action Can Become Dangerous When Actions Are Chained Together
Consider a finance agent with permission to read invoices, search email, query vendor records, and upload files to an approved cloud service.
Each capability may be perfectly reasonable on its own.
The risk appears when those capabilities are combined.
For example, an attacker could hide malicious instructions inside an invoice attachment. If the agent interprets those instructions as part of its task, it might search email for sensitive information, place the information in a document, and upload that file through a tool that is normally allowed.
None of the tools involved needs to be malicious. The danger comes from the sequence.
This is why agent security increasingly needs to understand complete chains of behavior rather than inspecting every action in isolation.
Prompt Injection Becomes Much More Serious When AI Can Use Tools
Prompt injection has been a concern since large language models began appearing in business applications.
Agents increase the potential damage because a manipulated system can do more than generate an incorrect answer.
A manipulated agent may be able to use credentials, modify records, execute code, send information outside the organization, or trigger other software.
That is why agent security is moving beyond the prompt and the model. Security systems increasingly need to understand what the agent is trying to do and whether that action should be allowed.
The Market Is Moving From Model Security to Action Security
The first generation of generative AI security focused heavily on protecting prompts, models, and data.
Companies asked whether confidential information could leak into a chatbot, whether users could jailbreak a model, whether unsafe content could be generated, and whether employees were sending sensitive company data to unapproved AI services.
Those questions remain important, but autonomous agents introduce another layer.
The key security object is increasingly the action.
The New Agent Security Chain
A useful way to understand the new environment is to think about the agent as part of a complete execution chain.
USER
↓
AGENT
↓
MODEL / REASONING
↓
TOOLS
↓
IDENTITIES + CREDENTIALS
↓
APPLICATIONS / APIs / DATA
↓
REAL-WORLD BUSINESS ACTION
Traditional AI security often focused near the top of this chain.
Agent security has to reach much further down.
Once an agent can touch GitHub, Salesforce, Microsoft 365, financial systems, cloud infrastructure, browsers, customer databases, or internal APIs, the security boundary extends into the rest of the business.
This helps explain why companies such as Neo are focusing on runtime control rather than stopping at prompt inspection.
Neo Is Making a Direct Bet on the Agent Control Layer
Neo is one of the clearest examples of agent security becoming a business category of its own.
The Boston company emerged from stealth in July 2026 with $100 million from Andreessen Horowitz and Bessemer Venture Partners, with additional participation from Craft Ventures and Merlin Ventures.
Its stated goal is to build a control layer for agentic software operating across the enterprise.
That positioning is important because it shows where the security market may be heading.
Neo says its platform can discover agents, models, skills, MCP servers, extensions, and related software. It also looks for configuration issues and permission problems while giving enterprises a way to intercept agent actions before those actions reach sensitive systems.
Policies can then allow an action, block it, or require human approval.
That combines several security functions that were historically sold as separate categories. There are elements of asset inventory, posture management, identity security, endpoint control, data protection, and application enforcement.
The difference is that the thing being controlled is autonomous software.
Why Preventing an Action Could Become More Valuable Than Logging It
Logs are useful after something happens, but autonomy makes prevention much more important.
If an agent attempts to export a customer database, the security team does not simply want a record proving that the export took place. The better outcome is to pause or block the action before the data leaves.
That creates a possible future architecture in which security policy sits directly between the agent’s decision and the business system.
Agent proposes action
↓
Security policy evaluates action
↓
┌────────────┬──────────────┬───────────────┐
│ ALLOW │ REQUIRE HUMAN│ BLOCK │
│ │ APPROVAL │ │
└────────────┴──────────────┴───────────────┘
↓
Business system
That control point could become one of the most valuable positions in enterprise AI infrastructure.
Instead of protecting only the model, security moves directly into the execution path.
Agentic Highway Is Targeting the Inventory and Trust Problem
Runtime enforcement is useful only when a company knows what it is trying to control.
That is already becoming difficult.
A large enterprise may have official agents built by an internal AI team, coding agents installed by developers, SaaS applications quietly adding autonomous features, MCP servers connected to internal tools, department-built automations, third-party agents, browser extensions, and experimental workflows created by individual employees.
The result begins to resemble shadow IT, except the software may be able to take actions rather than simply store or process data.
Boston-based Agentic Highway is focusing on this inventory and accountability layer.
The company says it is building Vettd, a vendor-neutral trust layer for the agentic supply chain. Its approach includes an inventory of agentic assets, security and performance grading, evidence records, and mappings to frameworks such as the NIST AI Risk Management Framework, ISO 42001, the EU AI Act, and OWASP guidance.
The company is early, but the problem it is addressing is likely to become increasingly important.
AI May Need Its Own Bill of Materials
Modern cybersecurity teams increasingly want to know what software contains.
Agentic software may require an even broader record.
Security teams may need to know which model an agent uses, which tools it can call, which MCP servers it trusts, which skills are installed, what data it can access, what credentials it inherits, who owns it, and what evidence exists that it was tested.
This is especially important because agent systems are often assembled from many external and internal components rather than delivered as one simple application.
The more components an agent depends on, the more difficult it becomes to understand its true attack surface.
Finding #3: The Emerging Product Stack Already Extends Far Beyond Generic “AI Security”
We coded the five companies in our sample according to six broad functions visible in their public product strategies.
A checkmark in the table below means that the function appears prominently in the company’s public description. It does not mean BostonBizScene independently tested or certified the product.
| Company | Agent inventory / visibility | Identity or attribution | Runtime / action control | Security investigations by agents | Audit / evidence layer | Agent traffic or behavior control |
| 7AI | — | — | — | ✓ | ✓ | — |
| Neo | ✓ | ✓ | ✓ | — | ✓ | ✓ |
| Agentic Highway | ✓ | — | — | — | ✓ | — |
| Rapid7 / Kenzo | — | — | — | ✓ | ✓ | — |
| Akamai | ✓ | ✓ | ✓ | — | ✓ | ✓ |
The important point is not which company has the most functions.
What matters is how many distinct jobs are already appearing inside this market.
Agent security is beginning to separate into discovery, identity, policy, runtime enforcement, autonomous investigations, evidence management, behavior monitoring, and governance.
That is a strong sign that the category is moving beyond a single feature.
Akamai Shows Why Agent Identity Could Become a Major Security Problem
AI agents will not operate only inside internal enterprise applications.
They will increasingly interact with websites, APIs, commerce systems, login flows, payment services, and internet infrastructure.
That creates another question that traditional identity systems were not designed to answer well.
When an automated request arrives, who or what is actually making it?
Cambridge-based Akamai is working on this issue at internet scale.
In June 2026, the company announced an agentic-security framework for its Bot & Agent Control products. One part of the framework is a “Know Your Agent” approach designed to connect the identity of an AI agent with the authorized human behind it.
Akamai also described a decision layer that combines identity and behavior signals so organizations can make more informed decisions about agent-driven traffic.
This points toward a much larger enterprise requirement.
Companies may need to know not only which employee is authenticated, but which autonomous entity is operating under that employee’s authority.
Human Identity Alone Is No Longer Enough
Imagine an employee creates three agents.
One agent summarizes email.
A second agent makes purchases below a set limit.
A third updates customer records.
All three may ultimately trace back to the same employee account, but that does not mean they should have the same permissions.
A useful security model may need to look more like this:
HUMAN: Employee A
│
├── Agent 1: Email assistant
│ └── Permission: Read mail
│
├── Agent 2: Purchasing agent
│ ├── Permission: Vendor catalog
│ └── Spending limit: $500
│
└── Agent 3: CRM agent
├── Permission: Read customers
└── Permission: Update selected fields
The organization needs to know which agent performed each action and whether the action matched the agent’s approved role.
That is where identity security begins to merge with behavioral governance.
Akamai’s Research Shows Why Browsers and Endpoints Are Part of the Agent Security Problem
The agent-security problem is not limited to large formal AI programs.
In September 2026, Akamai published research arguing that enterprises need to move toward behavioral governance for nonhuman identities and autonomous software.
The company reported that more than 40% of enterprise users had installed AI-powered browser extensions. It also said that 25% of those extensions changed permissions within a 12-month period and that more than 6% of chatbot conversations contained sensitive information.
These figures are important because employees may adopt agent-like tools long before the CIO approves a company-wide agent strategy.
Autonomous capabilities can enter the business through browser extensions, coding environments, desktop tools, SaaS applications, and AI assistants that quietly gain more execution power over time.
Security teams therefore face a visibility problem before they can even begin enforcing policy.
7AI Shows the Other Side of Boston’s Opportunity: Agents That Perform Security Work
Not every company in this category is trying to protect agents.
Some are turning agents into defenders.
Boston-based 7AI is one of the most visible examples.
The company was founded by Cybereason co-founders Lior Div and Yonatan Striem-Amit and has positioned its platform around autonomous security investigations. According to the company, its agents can detect, investigate, respond to, and hunt threats while people remain responsible for oversight and higher-level decisions.
7AI reports $166 million in total funding.
In May 2026, the company said its platform had processed more than seven million investigations and that its customer base had grown threefold quarter over quarter. It also announced plans for 100 additional AI jobs at its Boston headquarters.
These are company-reported figures rather than independently audited measurements, but they still provide a useful signal about how rapidly agentic security operations are moving from experiments toward production.
Why Security Operations Is a Natural Agent Market
A modern security operations center has many characteristics that make it suitable for autonomous AI.
Teams receive huge numbers of alerts, investigations require repetitive data gathering, analysts frequently move between several tools, and many cases follow recognizable workflows.
The work is also expensive because experienced security analysts are difficult to hire and retain.
Most importantly, the results can be measured.
A security leader can ask how many investigations were completed, how long each one took, how many alerts were resolved, how many required human escalation, how often the agent made mistakes, and whether important incidents were missed.
That makes cybersecurity operations one of the clearest places to test whether AI agents can create measurable business value.
Rapid7’s Kenzo Acquisition Shows Agentic Security Moving Into Established Platforms
Startups are not the only meaningful signal.
Acquisitions often reveal when an emerging technology is becoming important enough for established companies to make it part of a broader platform strategy.
Boston-based Rapid7 acquired Kenzo Security in March 2026.
Kenzo was described as an agentic AI security platform designed for autonomous investigations. Rapid7 said the technology uses multiple specialized agents and reported that an average customer reduced investigation time by 94% while increasing alert coverage from 12% to 100%.
Those figures come from the company and should be interpreted as reported customer outcomes rather than independently verified industry benchmarks.
Rapid7 later disclosed an aggregate fair acquisition value of $25.5 million.
The transaction matters because it shows agentic security being folded into an established cybersecurity platform rather than remaining isolated inside early-stage startups.
The Real Shift Is From AI-Assisted Work to AI-Driven Operations
Rapid7 had already introduced agentic workflows into its security products before acquiring Kenzo.
The acquisition pushed that strategy further toward multi-agent investigation and machine-speed security operations.
The difference becomes clearer when we compare the old model with the new one.
An AI assistant may tell an analyst, “Here is a summary of the alert.”
An autonomous security system may instead investigate the alert, correlate related activity, gather supporting evidence, reach a preliminary conclusion, document the investigation, and escalate only the decisions that require human authority.
The first model is primarily about productivity.
The second begins changing how the security team itself operates.
Finding #4: Authority May Become the Most Important New Security Boundary
Traditional cybersecurity has spent decades thinking about access.
Can this identity reach this system?
Agentic AI introduces another important question.
What is the agent actually authorized to decide?
An agent may have technical access to an email system without having permission to send external messages.
It may have access to customer records without having authority to delete them.
It may be able to prepare a payment instruction without being allowed to submit the payment.
The difference between capability and authority could become one of the defining ideas in agent security.
A Simple Authority Model
BostonBizScene recommends that businesses separate agent actions into four practical authority levels.
| Authority level | Meaning | Example |
| Level 1: Read | Agent can retrieve information | Search a knowledge base |
| Level 2: Prepare | Agent can create a proposed action | Draft an email or remediation plan |
| Level 3: Execute reversible | Agent can perform low-risk actions that are easy to undo | Update a support ticket |
| Level 4: Execute high-impact | Agent can make consequential changes | Transfer money or disable production infrastructure |
This is not an official industry standard. It is a simple operating model that companies can adapt.
The security requirement should become stricter as the level of authority increases.
A Level 1 agent may need identity, access controls, and logging.
A Level 2 agent may also need clear ownership and review procedures.
A Level 3 agent may require runtime enforcement and rollback.
A Level 4 agent may need explicit human approval, tightly limited credentials, strong transaction limits, and continuous monitoring.
The Agent Permission Problem Could Become More Important Than the Prompt Problem
Many companies begin the AI-security discussion by asking whether the prompt is safe.
That is important, but it is not enough.
A carefully written prompt connected to an identity with excessive permissions can still create serious damage.
By contrast, an imperfect model operating inside narrow, well-designed permission boundaries may create far less risk.
This leads to a practical principle.
Companies should not focus only on securing the language of the instruction. They also need to secure the authority behind that instruction.
Least Privilege Has to Become Agent-Aware
The cybersecurity principle of least privilege becomes even more important when software acts autonomously.
An agent should receive only the tools, data, credentials, and execution rights required for its specific role.
In practice, many early agents are built using the permissions of the employee or developer who created them.
That can make the agent far more powerful than its actual job requires.
A customer-support agent, for example, may only need permission to read one customer’s account and issue refunds below a small threshold. It should not automatically inherit an administrator’s ability to access every customer record or modify every support setting.
MCP Is Turning the Agent Supply Chain Into a Security Surface
The Model Context Protocol, or MCP, makes it easier for AI systems to connect with external tools, services, and data.
That convenience can greatly accelerate agent development, but it also creates another dependency layer.
An agent may use several MCP servers, each exposing different tools. Those tools may then connect to databases, SaaS platforms, internal APIs, file systems, or cloud services.
Every additional connection expands the effective attack surface.
OWASP’s agentic-security work specifically identifies supply-chain weaknesses as a major risk category because autonomous systems increasingly depend on many separate components.
Businesses Need an Agent Dependency Map
For every important production agent, security teams should be able to build a simple dependency map.
Agent
├─ Model
├─ System instructions
├─ Identity
├─ Credentials
├─ MCP server A
│ ├─ Tool 1
│ └─ Tool 2
├─ MCP server B
│ └─ Tool 3
├─ Database access
└─ External API access
Without this map, incident response becomes extremely difficult.
If a vulnerable MCP server is discovered, the company needs to know which agents depend on it.
If a credential is compromised, the company needs to know which agents can use it.
If a third-party integration quietly changes permissions, the security team needs to know which workflows became more powerful.
This is why agent inventory and dependency management could become foundational security categories.
Agent Memory Is Becoming Another Security Surface
Agents are increasingly being designed to remember information across multiple interactions.
Memory can make an agent more useful because it does not need to relearn the same context every time.
It can also create persistent security risk.
If malicious information enters the memory system, that information may continue influencing the agent long after the original interaction has ended.
Sensitive information may also be stored longer than intended.
Businesses therefore need clear answers to several operational questions.
They should know what the agent can remember, where that memory is stored, how long it remains, who can inspect it, whether security teams can delete it, and whether untrusted content can become persistent instructions.
They also need to understand whether one user can indirectly influence another user’s agent through shared memory or shared context.
As long-running agents become more common, memory security is likely to become its own meaningful product area.
Boston’s Advantage Goes Beyond Startups
Boston’s early position makes more sense when we look at the broader ecosystem rather than individual companies.
Massachusetts already has a deep cybersecurity base that includes startups, public companies, universities, research groups, and major regulated industries.
Those industries include healthcare, financial services, biotechnology, manufacturing, defense, and higher education.
Agent security sits directly at the intersection of capabilities the region already understands well.
Boston has cybersecurity expertise.
It has AI research.
It has enterprise software talent.
It has major cloud and infrastructure companies.
It also has customers operating in industries where uncontrolled automation can create serious legal, financial, or safety consequences.
That combination is difficult to reproduce quickly.
MIT and Cambridge Give Boston a Research-to-Product Feedback Loop
Agent security is not a market that established products alone can solve.
The underlying technology is changing too quickly.
Research on prompt injection, secure execution, contextual security, identity, privacy, formal verification, and multi-agent systems can move rapidly into commercial products.
MIT CSAIL’s 2026 work on contextual security for agents is one example of how closely academic research now overlaps with enterprise product needs.
That creates a potentially valuable local feedback loop.
AI RESEARCH
↓
NEW AGENT CAPABILITY
↓
NEW SECURITY PROBLEM
↓
SECURITY RESEARCH
↓
STARTUP / PLATFORM PRODUCT
↓
ENTERPRISE DEPLOYMENT
↓
NEW REAL-WORLD SECURITY DATA
└──────────────────────→ back into research
Cities with both strong AI research and strong cybersecurity ecosystems have an advantage in building this loop.
Boston is one of them.
Regulated Industries Could Give Boston an Early Customer Base
Boston’s strongest enterprise sectors are also the sectors most likely to demand strong controls around autonomous software.
Healthcare provides an obvious example.
An agent that interacts with patient information needs narrow permissions, privacy controls, auditability, and carefully designed authority boundaries.
Financial services creates similar requirements. Agents touching trading systems, customer accounts, compliance records, payments, or material financial information cannot be allowed to act without clear identity and controls.
Defense organizations face even higher requirements around autonomy, accountability, and traceability.
Biotechnology companies may need to protect valuable research, intellectual property, and regulated processes.
This gives Boston-based agent-security companies access to nearby industries with real, high-value security problems.
They do not need to invent theoretical use cases.
Finding #5: Boston May Be Building Three Agent-Security Markets at the Same Time
Our research suggests that the emerging market can be divided into three broad layers.
Layer One: Agents That Perform Security Work
Companies such as 7AI and the agentic capabilities Rapid7 gained through Kenzo sit in this layer.
Their main economic promise is labor leverage.
The customer is paying for software that can investigate, analyze, triage, and resolve more security work without requiring an analyst to manually handle every step.
Layer Two: Security That Controls Agents
Neo and parts of Akamai’s strategy sit closer to this layer.
Their value increases as enterprises deploy more autonomous software.
The customer is paying for identity, visibility, policy enforcement, behavior monitoring, and runtime controls around agents.
Layer Three: Trust Infrastructure for the Agent Supply Chain
Agentic Highway represents an early version of this layer.
This part of the market focuses on inventory, evidence, standards mapping, dependencies, provenance, and eventually perhaps certification or machine-readable trust records.
The customer is paying for proof about what an agent is, how it was built, and what it should be trusted to do.
Boston’s Emerging Agent-Security Stack
┌─────────────────────────────────────────────┐
│ SECURITY AGENTS │
│ Autonomous investigation and response │
│ 7AI · Rapid7 / Kenzo │
├─────────────────────────────────────────────┤
│ AGENT CONTROL │
│ Runtime rules · identity · behavior │
│ Neo · Akamai │
├─────────────────────────────────────────────┤
│ AGENT TRUST / INVENTORY │
│ Assets · evidence · dependencies │
│ Agentic Highway │
├─────────────────────────────────────────────┤
│ ENTERPRISE SYSTEMS │
│ SaaS · APIs · Cloud · Data · Endpoints │
└─────────────────────────────────────────────┘
These companies will almost certainly overlap as the market matures.
The more important point is that several infrastructure layers are already appearing.
That suggests agent security is unlikely to remain a small feature inside generic AI software.
What Boston Businesses Should Do Right Now
Companies do not need to wait for the agent-security market to mature before improving their own controls.
The most important first steps are operational rather than complicated.
Start With an Agent Inventory
The first priority is simply finding out what already exists.
Companies should not limit the inventory to software officially described as an “AI agent.”
They should also look for coding tools, browser extensions, workflow automations, AI features inside SaaS products, MCP servers, department-built bots, scripts using large language models, customer-facing agents, and experimental systems connected to company information.
For every important system, record the owner, business purpose, model, tools, credentials, data access, external connections, autonomy level, and production status.
Without this basic inventory, agent governance becomes guesswork.
Write an Agent Job Description
Every production agent should have a short operating description.
It does not need to become a giant policy document.
The goal is to make the agent’s role clear.
The description should explain what the agent is supposed to accomplish, which systems it may use, which information it may access, which actions it may perform automatically, and which actions require a person to approve them.
Weak Definition
“Help the finance team.”
This is far too broad because it does not define authority.
Better Definition
“Read invoices received through the approved accounts-payable mailbox, compare invoice fields with purchase orders in the ERP, flag mismatches, and prepare a payment recommendation. The agent may not create vendors, modify bank information, or submit payments.”
That definition gives both security teams and business owners a clear operating boundary.
Separate Read, Recommend, and Execute Permissions
Many organizations accidentally give agents too much authority because they treat access as one simple yes-or-no setting.
A better approach is to separate three types of permission.
An agent may be allowed to read information without changing it.
It may be allowed to prepare an action without performing it.
It may be allowed to execute some low-risk actions while escalating higher-risk actions to a person.
These distinctions reduce the potential blast radius when an agent makes a mistake or encounters malicious instructions.
Treat Credentials as a First-Class Agent Risk
Agents should not receive broad reusable credentials simply because those credentials make integration easier.
Companies should use scoped identities wherever possible.
Credentials should expire quickly when practical, access should be limited to specific tools, and credential use should be logged.
An agent that needs access to five customer records should not receive permission to reach five million.
This sounds simple, but it is one of the most important controls a company can implement.
Put Human Approval at High-Impact Boundaries
The phrase “human in the loop” is often used too loosely.
A person who reviews a log the next morning is not meaningfully controlling an action that happened the night before.
Human approval should sit directly in front of actions where mistakes could be expensive, difficult to reverse, or legally important.
That may include large payments, changes to production infrastructure, deletion of user accounts, external publication, legal commitments, sensitive data exports, and major permission changes.
The goal is not to force people to approve every action.
The goal is to keep human authority at the points where consequences become serious.
Log the Full Decision Chain
Traditional logging may show that an API request happened.
Agent logging needs to provide more context.
Security teams should ideally be able to see what task the agent was pursuing, which information it read, which tools it called, what action it proposed, which policy allowed the action, whether human approval was required, which identity executed the final step, and what happened afterward.
That evidence becomes critical during incident response, audits, and compliance reviews.
Test Agents the Way an Attacker Would
Normal software testing asks whether an application performs its intended job.
Agent testing also needs to ask whether somebody can manipulate that behavior.
Security teams should place malicious instructions inside files, hide adversarial text inside webpages, test compromised tool output, try to force the agent to reveal secrets, attempt to make it use unauthorized tools, give it conflicting instructions, and see whether one agent can influence another.
They should also test whether memory can be poisoned or whether an agent can be tricked into exporting information.
This is where agent-specific red teaming becomes valuable.
Measure Agent Security With Business Metrics
Security teams should avoid measuring agent safety only through the number of prompts blocked.
The more useful metrics focus on visibility, authority, and outcomes.
| Metric | Why it matters |
| Percentage of production agents inventoried | Measures visibility |
| Percentage with named business owners | Measures accountability |
| Percentage using scoped identities | Measures permission quality |
| High-impact actions requiring approval | Measures authority control |
| Unauthorized action attempts blocked | Measures enforcement |
| Agent incidents by root cause | Shows where controls fail |
| Mean time to revoke an agent | Measures kill-switch readiness |
| Percentage with complete action logs | Measures auditability |
| Unused agent permissions | Measures excessive access |
| Third-party dependencies per agent | Measures supply-chain exposure |
These metrics make agent security measurable instead of leaving it as a vague governance discussion.
Every Important Agent Needs a Kill Switch
Organizations need a reliable way to stop an agent quickly.
That becomes difficult when the agent has multiple credentials, scheduled jobs, API tokens, browser sessions, cloud functions, delegated identities, or integrations with several external tools.
Simply disabling one application may not stop every path through which the agent can continue operating.
The kill switch needs to remove operational authority, not just hide the user interface.
A mature security design should be able to answer one question immediately.
If this agent starts behaving dangerously at 2:00 a.m., how do we stop its next action?
If the organization cannot answer that question clearly, the agent probably has too much freedom.
Procurement Teams Need a New AI Agent Questionnaire
Agent security is quickly becoming a vendor-management problem as well.
Businesses buying AI software should start asking questions that would have sounded unusual only a few years ago.
They should ask whether the product contains autonomous agents, whether those agents can call external tools, which identities they use, whether customers can restrict their actions, whether human approval is supported, whether complete action logs are available, whether long-term memory is used, and whether MCP servers or external tools are involved.
Companies should also ask how quickly an agent can be disabled, whether customers can export audit records, whether the agent can execute code, and what data can leave the customer’s environment.
A vendor claiming to use “enterprise-grade AI” does not answer any of these questions.
The Biggest Opportunity May Be the Agent Control Plane
There is a useful historical parallel with cloud computing.
Cloud platforms created enormous application opportunities, but they also created major cybersecurity categories around identity, configuration, posture management, observability, workload protection, and data security.
Agents may follow a similar path.
The companies building autonomous software may create enormous value.
Another group of companies may become equally important by controlling that software.
The winning security layer could become the place where enterprises define who an agent is, what it can access, what it can do, when it needs approval, what behavior is considered abnormal, and how its actions are recorded.
That would effectively become a control plane for machine workers.
Neo’s runtime positioning, Akamai’s identity work, and Agentic Highway’s inventory strategy all point toward different versions of this idea.
Existing Cybersecurity Companies Cannot Ignore the Market
It would be a mistake to assume startups will control every part of agent security.
Established cybersecurity companies already own valuable enforcement points.
Identity vendors can see authentication.
Endpoint vendors can see processes.
Network companies can see traffic.
Cloud-security platforms can see workloads.
Browser-security companies can see user and agent behavior.
Data-security companies can see sensitive information.
API-security companies can inspect application interactions.
SOC platforms can see investigations and incidents.
Each of these positions can be extended toward agents.
Rapid7 and Akamai are already showing how that might happen.
The strategic question may eventually become less about whether agents need security and more about which existing control point becomes the natural place to enforce it.
The answer may differ by environment, which creates room for both startups and larger security vendors.
Boston Could Benefit Because Enterprise Buyers Already Know Its Security Companies
Cybersecurity buying is different from buying consumer AI tools.
A clever demonstration is not enough.
Enterprise buyers care about reliability, integration, support, auditability, evidence, and long-term trust.
Boston already has large cybersecurity and infrastructure companies selling into demanding enterprise environments.
Akamai reported $4.208 billion in revenue for 2025, including $592 million of security revenue during the fourth quarter, while employing more than 11,500 people globally.
Rapid7 reported $832 million in annualized recurring revenue for the first quarter of 2026.
That gives Boston something many emerging AI hubs do not have.
The region has startups experimenting with new agent-security models, but it also has established public companies capable of distributing agentic-security technology into large enterprise environments.
What Investors Should Watch
Agent security will almost certainly attract companies that add the word “agentic” to existing products.
The more useful question is whether the product controls a genuinely new source of risk.
Investors should look past the demo and examine where the company sits in the execution path.
Does the Product Sit in the Action Path?
A platform that observes what happened after an agent acts may still be useful.
A platform positioned between intention and execution may have much stronger control.
Does the Company Own Unique Security Data?
Agent-security products may become more valuable as they observe more actions, permissions, tools, dependencies, policies, and attacks.
A company that builds a strong dataset around real agent behavior may create a meaningful long-term advantage.
Does the Product Become More Valuable as Agent Count Grows?
The best infrastructure businesses often become more important as complexity increases.
If an enterprise grows from five agents to five thousand, inventory, identity, permission management, dependency mapping, and runtime enforcement all become harder.
Products solving those problems may become more valuable as adoption increases.
Can the Company Prove Risk Reduction?
Fear alone will not sustain this market.
Customers eventually need measurable results.
That may mean fewer excessive permissions, faster investigations, better alert coverage, fewer successful unauthorized actions, stronger audit evidence, or lower incident impact.
What Founders Should Watch
Founders building agentic software should treat security architecture as part of the product itself.
It should not be something added at the end.
An agent built without scoped identity, complete logging, permission boundaries, dependency records, and approval controls can become expensive to secure after customers begin using it.
For companies selling into Boston’s banks, hospitals, biotech firms, universities, defense organizations, and large enterprises, strong security may also become a sales advantage.
A startup that can clearly explain what its agent can and cannot do may move through enterprise procurement more easily than a startup focused only on intelligence or speed.
A Practical 90-Day Agent Security Plan
Businesses do not need a multi-year transformation program to improve agent security.
A focused 90-day plan can create meaningful progress.
Days 1–30: Discover
The first month should focus on visibility.
Find official agents, department-built workflows, browser extensions, coding agents, AI features inside SaaS products, scheduled automations, MCP servers, and prototypes connected to company information.
Assign an owner to every important system.
Document its tools, credentials, data access, and authority.
The goal is not perfect security.
The goal is to eliminate unknown autonomy.
Days 31–60: Reduce Authority
The second month should focus on permissions.
Remove broad credentials.
Separate read access from write access.
Define spending, data, and execution limits.
Add approval checkpoints before high-impact actions.
Identify agents that cannot be disabled quickly and create shutdown procedures.
By the end of this phase, every important production agent should have clearly defined authority boundaries.
Days 61–90: Test and Monitor
The third month should focus on resilience.
Attempt prompt injection.
Test hostile files.
Manipulate tool output.
Try to escalate privileges.
Test memory poisoning.
Attempt unauthorized data exports.
Then examine whether the logs explain the entire chain of events.
Create a small dashboard showing agent inventory, permission levels, blocked actions, human approvals, incidents, and kill-switch readiness.
At the end of 90 days, the organization should understand not only which agents exist but how safely they operate.
The Agent Security Budget Could Come From Several Departments
Another reason this market could become large is that the buyer is unlikely to be one person.
The CISO cares about attacks.
The CIO cares about software governance.
Compliance teams care about evidence.
AI platform teams care about safe deployment.
Developers care about testing and tools.
Risk teams care about authority.
Internal audit cares about traceability.
Legal teams care about accountability.
Procurement teams care about third-party agents.
Agent security therefore sits across several existing budget categories.
That often happens when a technology begins changing how the enterprise operates.
The Biggest Risk for the Category Is Security Theater
Fast-growing markets attract weak products.
The phrase “AI security” is broad enough that almost any dashboard can be marketed under it.
Buyers should therefore ask very specific questions.
Can the product discover an unknown agent?
Can it show every tool the agent can use?
Can it identify excessive permissions?
Can it block a dangerous action before execution?
Can it prove which identity performed the action?
Can it revoke that identity immediately?
Can it show the complete action chain afterward?
Can it test indirect prompt injection?
Can it map third-party dependencies?
Can it export evidence for auditors?
Specific questions make it much easier to separate real control from marketing language.
Our Boston Research Has Important Limits
This analysis is deliberately conservative.
We required a clear public connection to both agentic systems and cybersecurity, along with a Boston or Cambridge operating link.
That almost certainly understates the real market.
Large cybersecurity companies may have internal agent-security projects that have not yet been announced.
Early startups may still be in stealth.
Broader AI companies may be building security features without using the same language.
Funding databases may also contain financing that cannot yet be confidently linked to a specific agent-security strategy.
For that reason, our five-company dataset should be treated as a verified lower-bound sample rather than a complete market census.
Even with that limitation, the signal is meaningful.
We found companies working across several layers of the stack and at least $291.5 million in measurable financing or acquisition value attached to only three capital events or businesses in our sample.
What Would Prove Boston Has a Lasting Lead?
An early lead does not guarantee long-term leadership.
Boston companies still need to turn technical advantages into large enterprise businesses.
Established vendors need to keep investing.
Security research needs to become practical products.
Local companies need to act as design partners.
Founders need to continue building in the region.
Talent needs to remain available.
Boston will also face intense competition from Silicon Valley, New York, Israel, and other global technology centers.
The most useful evidence will not be the number of companies using the phrase “agentic security.”
It will be production adoption.
Watch customer counts.
Watch the number of autonomous actions processed.
Watch recurring revenue.
Watch enterprise deployments.
Watch acquisitions.
Watch hiring.
Watch whether companies begin creating dedicated budgets for agent-security controls.
Those numbers will tell us whether the category is becoming durable.
The Bigger Story: AI Security Is Moving From Protecting Software to Governing Digital Actors
The biggest shift may not be technical.
It may be conceptual.
For decades, businesses treated software primarily as a tool. A person decided what needed to happen, and software executed a relatively predictable instruction.
AI agents blur that relationship.
Software can now receive a goal, examine an environment, choose among possible actions, use tools, and continue working toward an outcome.
Once that happens, security has to govern something that behaves more like a digital actor than a traditional application.
The business needs to know its identity, purpose, permissions, dependencies, behavior, limits, history, and responsible owner.
That creates a market much larger than prompt filtering.
It creates demand for identity systems, inventory products, runtime controls, permission platforms, testing tools, supply-chain security, audit systems, behavior monitoring, agent-focused SOC products, and governance software.
Some of those categories already exist in early form.
Others will emerge as agent adoption grows.
Boston already has companies operating across several of these layers.
7AI is showing how agents can become security workers. Rapid7 is bringing autonomous investigation into an established cybersecurity platform. Neo is placing policy between agent decisions and enterprise actions. Agentic Highway is focusing on inventory and trust. Akamai is extending identity and behavioral controls into a world where software increasingly acts on behalf of people.
That does not mean Boston has already won the market.
The market itself is only beginning to form.
But the ingredients are unusually visible.
Boston has capital, startups, established cybersecurity companies, university research, regulated enterprise customers, and experienced security talent.
More importantly, it has a clear business problem to solve.
The next phase of enterprise AI will not be defined only by how intelligent an agent becomes.
It will also be defined by whether a business can confidently answer a more important question:
Can we trust this software to act?
The companies that help enterprises answer yes may build some of the most important cybersecurity businesses of the agentic era.
Boston has a meaningful opportunity to build a large part of that market.
