What is a security.txt file and does your AI startup need one

If you have never heard of a security.txt file, you are not alone, and yet it is one of the smallest, cheapest pieces of security hygiene an AI startup can put in place. It takes about ten minutes to create, costs nothing, and quietly signals to security researchers, security teams doing vendor checks, and automated scanning tools that you take vulnerability disclosure seriously. This article explains what it is, what a proper one looks like, and whether it is actually worth your time.

What a security.txt file actually is

Security.txt is a standardised, plain text file that tells anyone who finds a security vulnerability in your product exactly how to report it to you. It is defined by an official internet standard, RFC 9116, published by the Internet Engineering Task Force in 2022, so it follows a consistent, predictable format that tools and researchers already know how to look for.

The file lives at a specific, predictable web address, ideally yourdomain.com/.well-known/security.txt, with a fallback location directly at yourdomain.com/security.txt also permitted. It has been adopted by major companies including Google, GitHub, and LinkedIn, and the idea behind it is simple. Instead of a security researcher guessing which inbox to email, or giving up and posting the vulnerability publicly out of frustration, they check one predictable location and find clear instructions.

What actually goes in it

The specification defines a small set of fields, and only one of them is strictly required, though several others are strongly recommended in practice.

• Contact. The only required field. How someone should report a vulnerability to you, typically an email address or a web page. You can list more than one.
• Expires. Not technically required but strongly recommended. A date after which the file should be considered stale, written in a specific timestamp format. This exists because an old, abandoned security.txt file with a dead contact address is worse than none at all, so the standard forces you to signal freshness.
• Encryption. A link to a public key if you want researchers to be able to report sensitive findings encrypted.
• Preferred-Languages. Which languages your team can handle a report in.
• Canonical. The authoritative location of the file itself, useful for verifying you are looking at the genuine version.
• Policy. A link to your vulnerability disclosure policy, if you have one, explaining what a researcher can expect from reporting to you.
• Acknowledgments. A link to a page crediting researchers who have responsibly reported issues in the past.

A minimal, genuinely useful example looks like this.

• Contact: mailto:[email protected]
• Expires: 2027-01-01T00:00:00.000Z
• Canonical: https://yourcompany.com/.well-known/security.txt

That alone meets the standard properly. Adding a Policy link and an Encryption key is good practice once you have them, but is not required to get real value from the file.

The common mistakes worth avoiding

A few details trip people up, and getting them right is the difference between a file that works and one that quietly fails.

• The file must be placed at the well known location, yourdomain.com/.well-known/security.txt, not just at the root. The root location is an acceptable fallback, not a replacement.
• The Expires date needs the full timestamp format with a timezone, not a plain calendar date. An incorrectly formatted or past date can make parsers treat the whole file as invalid.
• Any web based contact link must be HTTPS, not HTTP.
• Do not point Contact at a generic inbox like info@ or support@. Use a dedicated address that actually reaches whoever handles security at your company, even if that is just you right now.
• Check your robots.txt configuration is not accidentally blocking the well known directory, which some default setups do.
• Set the Expires date no more than about a year out, and put a reminder in your calendar to review and renew it, because a stale file erodes exactly the trust it was meant to build.

Does an AI startup actually need one

Here is the honest assessment, because not everything worth doing is worth rushing to do first. Security.txt is not a security control. It does not prevent an attack or fix a vulnerability. Its entire value is communicative, giving researchers and reviewers a clear, standard path to tell you about a problem instead of struggling to find one or, worse, giving up and disclosing it publicly.

For an AI startup specifically, there are three genuine reasons it is worth the ten minutes.

It costs nothing and takes almost no time, so there is no real reason not to have it once you know it exists. It is exactly the kind of small, low effort signal that a security conscious enterprise buyer notices during a review, alongside things like your access controls and your data handling. And automated security scanning tools, some of which buyers or their security teams run against vendors as part of due diligence, specifically check for its presence, so having it can quietly improve how you come across in an automated assessment you may not even know is happening.

It will not win you a deal on its own, and it certainly will not compensate for weak security elsewhere. But it is one of the very few pieces of security hygiene that costs literally nothing and takes minutes, so the honest recommendation is simply to add it, then move on to the work that actually matters more.

How to set one up

In practice this is a five minute task. Write the file with your Contact and Expires fields at minimum, adding Policy and Canonical if you have them. Save it as security.txt. Place it at yourdomain.com/.well-known/security.txt, served as plain text over HTTPS. Confirm it loads correctly by visiting the URL directly, and check that nothing in your server configuration is blocking that path. Then put a calendar reminder in for a month before your Expires date, so you renew it before it goes stale.

The honest takeaway

Security.txt is a small, standardised file that tells anyone who finds a vulnerability in your product exactly how to reach you, and it takes minutes to set up properly. It will not make your AI product secure by itself, and it is not a substitute for the deeper work of securing your data flows, your agents, and your infrastructure. But it is one of the cheapest, easiest pieces of security housekeeping available, it is something buyers' automated checks specifically look for, and there is genuinely no good reason not to have it in place today.