How InlineScan reaches your systems

What leaves our network, where it comes from, and what has to be true before anything is sent. Written so your security team can review it without asking us.

The one address

InlineScan runs in a single AWS account in ap-southeast-2 (Sydney). All outbound traffic leaves through one NAT gateway, so every connection from InlineScan arrives from one address:

52.65.192.23

That covers all of it: the DNS lookups that verify a domain, the language model calls that write narration, sign-in, and the two paths below that reach a customer's own systems. If you allowlist InlineScan, this is the address to allowlist. If you would rather block it, this is the address to block, and nothing in the product looks for a second route.

The single address is a design decision rather than an accident. One NAT gateway costs less than one per availability zone, and the trade is recorded in our infrastructure: if that zone fails, InlineScan loses outbound access entirely, which means it stops rather than finding another way out.

Three paths, and what each one needs

1. You upload a result. Nothing connects to you.

This is the ordinary path and the one most customers only ever use. You run a scanning engine yourself, against your own systems, on your own schedule. You upload the output. InlineScan reads the file, narrates it, maps it onto a control catalogue and produces a report.

There is no connection to your infrastructure on this path, and nothing to allowlist for it. Uploads are capped at 2 MB compressed and 10 MB once decompressed.

2. Red team testing, which does connect, to an endpoint you nominate.

If you ask InlineScan to test an AI endpoint, it sends prompts to that endpoint. Four things must all be true before the first request leaves:

• the target sits under a domain you have proven control of, by publishing a DNS TXT record that we look up through pinned resolvers;
• a named approver in your account has approved that domain;
• somebody in your account acknowledges that specific run, at the time, and that acknowledgement is written to the audit trail against their name;
• the run is inside quota, which is reserved before anything is sent rather than counted afterwards.

Proving you control a domain is not the same as agreeing to be tested this afternoon while it is serving traffic, which is why the acknowledgement is per run rather than a standing permission. The credential for your endpoint is held for the length of the run. It is not written to the record, the audit trail or a log.

3. Collection, which is built and is not running.

InlineScan can make the observations a browser makes on its first visit: response headers, the TLS handshake, public DNS. It does not do this today. The scheduler that would run it is disabled in our infrastructure rather than merely switched off in configuration, and the application refuses to collect unless a setting that only that scheduler sets is present.

If collection is ever enabled for your account, it requires a DNS TXT consent record that you publish and that we check immediately before every single run. Deleting that record stops collection, without a support ticket and without waiting for us.

Where your data is

InlineScan runs in ap-southeast-2. Narration is produced by a language model in ap-southeast-2. Records are held in a database in the same region, under row-level security, scoped to one tenant at a time.

The model that writes narration has no tools. It cannot make a network request, read a file, or call anything. It is given text and it returns text.

The short version, for a security review

If your security team needs something this page does not answer, ask us and we will write it down here rather than in an email.