Skip to content

Vulnerability disclosure policy

Last updated: October 21, 2026

If you have found a security problem in INFRO, write to security@infro.io. This page says what is in scope, how to test without harming anybody else, what we commit to in return, and the safe harbour you have while you do it. The same contact is published in machine-readable form at /.well-known/security.txt.

How to report

Email security@infro.io with:

  • what is affected: the URL or endpoint, or the SDK and its version;
  • the steps to reproduce it, from a fresh account if you can;
  • the impact as you understand it;
  • whether anybody else knows about it yet.

A proof of concept helps. Do not attach anybody else’s data: if you saw some, say so and describe it instead. No PGP key is published today. If a report needs an encrypted channel, send a first email without the details and we will arrange one.

That mailbox is for vulnerability reports only. A security review or a questionnaire goes to sales@infro.io; a problem with an account you already hold goes to support@infro.io.

What we commit to

  • We acknowledge your report within one business day.
  • We tell you what we think the severity is and what we intend to do, and we keep you updated until it is resolved, including when the answer is that we already knew or that we will not change it, and why.
  • We tell you when the fix is live.
  • If we publish anything about the issue, we credit you by the name you choose, or not at all if you prefer.
  • There is no bug bounty programme and no payment. Said up front, because finding it out after the work is worse than knowing before it.

In scope

  • infro.io: this site;
  • dash.infro.io: the customer console;
  • api.infro.io: the gateway and every API it serves;
  • mcp.infro.io: the INFRO MCP server and the MCP gateway;
  • studio.infro.io: INFRO Studio;
  • content.infro.io: signed media links;
  • any other host under infro.io, under the same rules;
  • the published SDKs: @infro.io/sdk and @infro.io/reconcile on npm, and infro on PyPI and pub.dev.

What we most want to hear about:

  • reading or changing anything that belongs to another organization: its requests, usage, keys, members, settings or Studio files;
  • any way to recover a provider credential a customer connected. They are sealed at rest and never returned by any interface, so a way to read one is the most serious report we can receive;
  • sending a request past a budget, a spend limit, a key’s provider list or a model allowlist that should have refused it;
  • sign-in and session problems: passwords, passkeys, two-factor, SSO, SCIM, and the OAuth sign-in AI assistants use for the MCP server;
  • forging a signed media link, or one that still opens after it expires.

Not in scope

Please do not send these; we will close them without a fix:

  • vulnerabilities in your AI provider, Cloudflare, Neon, Polar or any other company’s systems. Report those to the company. How INFRO uses them is in scope;
  • denial of service, load testing, or anything that floods a service;
  • social engineering of our staff or customers, and physical attacks;
  • output from an automated scanner with no demonstrated impact;
  • missing headers, cookie flags or email-authentication records without a way to exploit them;
  • clickjacking on a page with no sensitive action, self-XSS, and CSRF on sign-out;
  • anything that needs a compromised device, browser or account to work;
  • software version numbers on their own.

The limits we already publish, such as rate limits being enforced per location, are listed on the Trust Center. A report that one of them is real is not new to us; a way to turn one into harm is.

How to test

  • Use only accounts and organizations you created. Every plan starts with a 14-day trial with a card at checkout, and it converts automatically: cancel it from Billing in the console if you do not want to be charged.
  • Requests to AI providers run on your own provider account, and your provider bills you for them. INFRO never pays for or refunds provider usage. Never use a provider key that is not yours.
  • Stop as soon as you have shown the issue. Do not read, change or delete more data than you need to prove it. If you reach another customer’s data, stop there and tell us.
  • Keep automated testing to the volume you need. Nothing you do should slow the service down for anybody else.
  • Give us the chance to fix it before you publish. We ask for 90 days from your report, or until the fix is live if that comes first. If we need longer we will tell you why and agree a date with you.

Safe harbour

If you make a good-faith effort to follow this policy, we consider your research authorised and we will not pursue or support legal action against you over it. That covers testing that avoids privacy violations, service degradation, and destruction or exfiltration of data that is not yours. If somebody else brings action over research that followed this policy, we will make it known that you acted under it.

We can only speak for INFRO. We cannot authorise testing of systems that belong to other companies, including your AI provider; their own policies apply to them.

If you are unsure whether something you want to try is covered, ask security@infro.io before you try it.

Changes

We update this policy when the platform or how we handle reports changes. The date at the top is the date of the last change. A report is handled under the version that was published when you sent it.