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 every path below that reaches 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.

Four paths, and where each one stands

On no path does InlineScan test your network or infrastructure: it does not scan your ports, run vulnerability scanners against your hosts, attempt to sign in to your systems, or fuzz them. Red team testing, path 2, is the one path that sends adversarial input, and it does so only as prompts to the endpoint you nominate.

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

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 MiB compressed and 10 MiB once decompressed.

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

If you ask InlineScan to test an AI endpoint, it sends prompts to that endpoint, and to nothing else. 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 observes your domain from outside, only with your consent. Running today.

InlineScan can observe a domain from outside it, with passive requests of the kind a browser or a mail server makes:

• one HTTPS request for the home page, and at most one more where the domain redirects from its apex to a single label directly under it, such as www;
• lookups of named public DNS records (SPF, DMARC, DKIM, CAA, MX, NS, MTA-STS, TLS reporting and DNSSEC), asked of public resolvers rather than of your own name servers;
• up to five TLS handshakes, which record the certificate and each protocol version the server accepts, TLS 1.0 and 1.1 included. No application data is sent on any of them.

It asks for no path but the home page, and it sends no sign-in attempt and no form. It runs when an approver in your account asks, and once a day on a schedule, one host at a time. Three things must all be true before a run sends anything:

• the domain is proven by a DNS TXT record, approved by a named approver in your account, and the proof is current;
• a DNS TXT consent record that you publish is in place, and it is looked up immediately before every single run. Its value is unique to your account, and we give it to you when you ask to turn collection on;
• the run is inside quota, at most four a day for a host, reserved before anything is sent.

Deleting the consent record stops collection, without a support ticket and without waiting for us. Every result collection produces is labelled as InlineScan's own observation, and that label cannot be uploaded by anyone.

4. Connected providers, which read your configuration through access you grant. Amazon Web Services and Microsoft 365 in pilot; Google Workspace, Oracle Cloud and Google Cloud coming.

Where an approver in your account connects an Amazon Web Services account or a Microsoft 365 tenant, InlineScan reads its configuration once a day, read-only, through access your own administrator grants using the provider's own mechanism, and files the result against a domain you have proven and an approver has approved. Both connections are available, and both are in pilot. The first Amazon Web Services connection has been activated and reviewed. Google Workspace, Oracle Cloud and Google Cloud connections are built and not available yet.

• InlineScan never asks for, and refuses, a password, access key or client secret issued by you. Its requests to the provider leave from the address above.
• Only an approver in your account can make or end a connection, and each one is filed against a domain your account has proven and approved.
• Each review runs as one task in InlineScan's own AWS account, with a pass that works for that review alone. The task has no access to InlineScan's database.
• Results from a connected account are labelled as collected by InlineScan, so a reader can tell them from an export you uploaded.
• Nothing is changed in your environment. InlineScan refuses to activate an Amazon Web Services role that carries more than its template's read-only policies, and before every Microsoft 365 review it checks again that its application holds only the read-only access it asked for.

For Amazon Web Services, your administrator creates a read-only role named InlineScanReadOnly from InlineScan's published CloudFormation template. The role trusts only InlineScan's scan task, and only when it presents an ExternalId InlineScan issues for your connection. You end it by deleting the stack, or by changing the ExternalId in the role's trust policy.

For Microsoft 365, your administrator consents to InlineScan's own application and assigns it the read-only Global Reader role. InlineScan holds a certificate of its own for that application, and never one of yours. Microsoft's consent screen shows the application as unverified until Inline Code's publisher verification is complete. You end it by deleting the InlineScan enterprise application in your tenant.

Ending access at the provider stops the next review. A review already under way can go on reading until it stops at its own time limit. This page will describe Google Workspace, Oracle Cloud and Google Cloud, and what each needs, before any of them is offered.

Where your data is

InlineScan runs 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. Narration is produced by a language model hosted in Australia.

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.