Prompt Security, control over AI inside a company

Prompt Security, control over AI inside a company

Prompt Security is a platform showing which AI tools your staff use, what they paste into them, and blocking what should not leave. Separately it protects applications you built in house, filtering prompts and model responses.

That distinction matters when picking a tool. Most products in this category handle only the second part, protecting your own application. Here the starting point is the first: people in the company using chats and code assistants regardless of whether anybody approved it.

A change of owner and name

Before you go looking for pricing, accept that the product is no longer independent.

SentinelOne announced the acquisition of Prompt Security on 5 August 2025, and the deal closed a month later, on 5 September. Publicly reported figures differ between sources: around two hundred and fifty million dollars at announcement, around a hundred and eighty million in cash and stock at completion. The official announcement of intent gave neither number, so treat them as reporting rather than as figures confirmed by the parties.

The company was founded in 2023, so two years passed between founding and acquisition. The product is being absorbed into the SentinelOne security platform as part of their strategy around generative AI and agents.

Two practical effects follow. Sales run through a security vendor's enterprise channel, with a sales conversation replacing self serve signup. And for companies already on the SentinelOne platform the integration is an argument, while for everyone else it means a conversation with a vendor they did not previously have in their stack.

Two problems in one product

Worth separating them, since conflating the two leads to buying something you do not need.

The first problem is unofficial AI use. Accounting pastes a spreadsheet into a free chat, somebody in legal drops in a draft contract, a developer sends a code fragment with an access key in it. Nobody acts maliciously, everyone wants to finish a task faster. Security learns about it by accident or not at all.

The second problem is a vulnerability in the application you built yourselves. The model accepts instructions from users and from content fetched externally, so a suitably crafted sentence can override the system prompt or pull out another customer's data.

Those two problems have different owners inside an organisation. The first belongs to security and compliance, the second to the engineering team. A product covering both often gets bought by one side and deployed by the other, which is the source of a good share of deployment friction.

Visibility, where every rollout starts

The first week with a tool like this almost always looks the same: watching.

Detecting unofficial use rests on a browser extension distributed through device management plus observation of network traffic. The output is a list of tools actually used in the company, and that is usually the moment of surprise, since the count exceeds management's assumptions by orders of magnitude.

That list is valuable in itself, whether or not you block anything afterwards. It shows where people see bottlenecks in their work, and it makes better material for a licensing decision than any survey.

The second layer is content. Semantic analysis recognises personal data, health data, financial information, and source code, then removes or replaces it before transmission. Custom classifications can be added, project names under a confidentiality agreement for instance.

Be realistic about effectiveness here. Meaning based recognition catches more than regular expressions, while no solution catches everything, and the stricter the settings the more false alarms land in daily work.

The limits of a browser extension

This is where hard questions belong before a contract gets signed.

The extension sees what happens in the browser on a company device. It does not see an app on a personal phone, a chat client installed as a program, an API call from a terminal, or an assistant embedded in a code editor unless a separate integration exists for it.

The consequence is predictable: effective blocking in the browser moves some traffic where the tool cannot reach. An employee wanting to finish a task will reach for their phone. That is not a flaw in this particular product but a property of the whole category, and easy to forget during a sales demonstration.

The practical conclusion is that blocking without an alternative works poorly. Blocking plus an approved tool that internal data may be pasted into works considerably better, since it gives people a route rather than a wall.

Protecting your own applications

The second half of the product resembles solutions such as Lakera Guard: you pass text entering and leaving the model through an API, receive a verdict, and decide what happens next.

Detection covers direct and indirect injections, escapes from constraints, and attempts to extract the system prompt. The vendor quotes response times below two hundred milliseconds and support for more than two hundred and fifty models, and both figures deserve treating as claims to verify against your own traffic.

Adversarial testing is a separate element, generating attack attempts and checking which get through. That is often the most useful feature in the set, since it produces a number instead of a feeling of safety. A report stating that seven attempts in a hundred succeeded argues better with a board than any vendor claim.

Indirect injection deserves separate attention, since with agents it is today's main attack route. An instruction hidden in a fetched page, a document, or a tool response enters the model's context exactly like text a user typed, except nobody typed it deliberately.

Code assistants, the hardest case

One situation deserves separate treatment, since in technology companies it generates the most argument while appearing rarely in sales material.

An assistant embedded in an editor sees the open project. That means code, configuration, sometimes an environment variable file passes through the model, and with inline completion it happens without the developer consciously deciding to send anything. Nobody pastes anything, so control based on detecting pastes will not fire.

Three answers exist and each carries a different price. The first is settings inside the tool itself: turning off training on your code, a list of excluded files, a business mode. That is the cheapest and the most often skipped, since it requires only walking through settings, which nobody finds time for.

The second is a locally running tool where code never leaves the machine. Suggestion quality falls short of large models, while the problem disappears at its source.

The third is an intercepting layer in front of the assistant's traffic, and this is where platforms of this type come in, provided they carry the right integration. Ask about it directly and name the specific tools your team uses, since coverage is uneven and shifts release to release.

There is also a question to answer before choosing anything: what are you actually protecting. Internal application code is rarely a secret worth the investment by itself. Access keys, production data sitting in test fixtures, and an algorithm that is a market advantage fall into an entirely different category, and those deserve rules first rather than blocking everything equally.

Prompt Security against the alternatives

The last row deserves honest consideration before buying anything. On a thirty person team, a clear rule, one approved tool, and a single training session handle most of the risk at a fraction of the cost. A platform of this class starts making sense when scale rules out talking to everyone, and compliance demands evidence rather than assertion.

The distinction between the first row and the second and third comes down to one question: do you need the staff side. If you are building a product and do not manage workstations, you are paying for a half you will not use.

A rollout order that works

Order matters more here than the choice of vendor, and deserves planning before the first install.

Start with observation and no blocking, for two to four weeks. You collect the list of tools and data types, and along the way learn the scale of false alarms before they hit anyone.

Then decide what is allowed. That is an organisational decision rather than a technical one, and it requires talking to the departments affected. The approved tool list should be built with the people who use them, otherwise you produce a list everybody works around.

Blocking is only the third step, and first for the categories with the lowest error rate, usually card numbers and access keys. Softer categories such as source code or customer names come later, after checking how much normal work they stop.

The last step is the message. A block saying only "denied" produces a support ticket. A block saying what it concerns and where to go instead produces the right behaviour.

Pricing and how it is bought

Pricing is not published, and after the move under SentinelOne the product sells alongside the rest of their platform, so the figure depends on seat count, scope, and what you already hold from that vendor.

Judging quality requires a trial against your own traffic, and that is the only meaningful test. Accuracy comparisons run on public data sets measure something other than your company, since your people paste your data, in your language, in your formats.

When costing the whole thing, remember two items outside the invoice. The first is security team time spent reviewing events, since the tool generates plenty and without somebody watching them the entire investment becomes an archive. The second is handling tickets from staff blocked unfairly, which in the early weeks can be substantial.

Common mistakes

The first is switching blocking on from day one. False alarms then hit real work, and the tool earns a reputation as an obstacle that cannot be rebuilt afterwards.

The second is blocking with no alternative. Without an approved tool, traffic moves to personal devices where you see none of it, so the statistics improve while the risk grows.

The third is treating the extension as full coverage. Beyond the browser on a company device sit phones, locally installed programs, and API calls, which can be a larger share of traffic than assumed.

The fourth is skipping output checks in your own applications. An injection that entered through a fetched document reveals itself in the answer, and there it can still be stopped.

The fifth is relying on a filter rather than on limited permissions. An agent able to delete data needs restrictions independent of whatever the model read in its prompt, since no filter catches everything.

The sixth is having no owner for events inside the organisation. A tool whose alerts nobody reviews satisfies a formal requirement and reduces no risk.

FAQ

Is Prompt Security still a separate company?

No. The SentinelOne acquisition closed in September 2025, and the product moved into their security platform. Sales run through that vendor's enterprise channel, so a licence comes with a sales conversation rather than self serve signup.

How does it differ from Lakera Guard?

In scope. Lakera Guard protects the application you built, filtering prompts and responses. Prompt Security does the same and adds a staff layer: detecting unofficially used AI tools and controlling what people paste into them.

Does the browser extension see everything?

No. It sees the browser on a company device. A personal phone, a locally installed program, an API call from a terminal, and some code editor assistants stay out of reach unless a separate integration exists.

What does it cost?

Pricing is not public, and post acquisition the product enters the SentinelOne platform offering, so the figure depends on seat count and scope. Comparing it against alternatives requires a trial against your own traffic.

Can it run on our own infrastructure?

The vendor lists an on premises deployment alongside the hosted version, so where requirements forbid sending content outside it is worth asking directly. If the answer falls short, local library solutions cover part of the scope without that problem.

Acquisition details sit in the SentinelOne announcement, and market context in industry coverage.