One page for your security team. A security review tends to start with one question, "what leaves?", and then ask many more... so we have tried to answer them here, in one place. An on-premise eety deployment has three paths out of your network and no others. This sheet says exactly what goes through each path, to whom, and when; what stays; what Google says in its own words; the controls we run; and the things we do not claim.
Written for the on-premise deployment. Eety Cloud has the same three paths plus eety's own hosting on Google Cloud; the security page covers that.
The server makes outbound connections for three jobs. Each row below is one path, and it reads like a customs declaration: who receives the data, what is sent, when, and what is never sent that way.
Path 1
To: Google Cloud, in your Google Cloud project or eety's, under Google Cloud terms. When: every AI step.
What is sent
What is not sent this way
Google's own statements on training, caching and retention are quoted in section 3.
Path 2
To: SerpApi, which queries Google Patents, Google Scholar and Google web search on the server's behalf. When: the state-of-the-art search in harvesting, the density verdict, and a prior-art search.
What is sent
What is not sent this way
The engines used, step by step, are in section 4.
Path 3
To: whichever public site holds the page: publishers, patent offices, Google Patents. When: the literature and known-art steps of a prior-art search only. Can be switched off.
What is sent
What is not sent this way
Egress rules for this path are in section 5.
Optional connections you control
To eety: nothing. No telemetry, no license ping, no crash reporting, no usage upload. The on-premise build removes the analytics tag and the uptime probe the cloud edition uses.
This is the part that stays home. With the database on your server and the file store on local disk, the following is written only inside your network and is backed up by you.
The database
Users, organizations, departments and roles. Matters and their references, like ACME-2026-0042. The understanding and intent of each invention, versioned. Drafts and section text, track changes, comments. Review findings. Library entries. Prior-art projects, search strings, screening results and reports. The token ledger. The audit log. Notifications and invoices.
The files
Uploaded disclosures and their attachments. Drawings, both generated and imported. Counsel drafts in Word and PowerPoint. Exports. The prior-art fetch cache and report previews. Stored under your tenant, by matter, on your disk or in a bucket you own.
The processing
OCR runs inside the deployment. Office conversion, and the generation of Word, Excel and PDF documents, run inside the deployment. Reports are streamed to the browser from your server. One honest caveat: drawings are produced by Google's image model from prompts and reference sketches, so figure content transits Google in both directions.
Paraphrase has a way of making a commitment sound stronger than it is. We have not turned Google's commitments into anything stronger; here is what the documents say, with links, and what each means for you.
Training
"Google won't use your data to train or fine-tune any AI/ML models without your prior permission or instruction."
Google Cloud, Generative AI and data governance, Vertex AI documentation.
This is the basis of "not used to train". It applies to Gemini used through Vertex AI under Google Cloud terms, which is how eety calls it, in your project or in eety's.
Caching and retention
The same page states that, for published Gemini models, customer data is cached by default, and that zero data retention is something the customer has to act on rather than something switched on for them.
Google Cloud, Generative AI and data governance, the sections on data caching and zero data retention.
So we do not say "Gemini stores nothing". If you run Gemini in your own Google Cloud project, the caching and retention settings are yours to set, and we will point you to them during deployment. If you run it in eety's project, ask us what is configured and we will show you.
Paid and unpaid tiers
The Gemini API terms distinguish unpaid services from paid services: content sent to the unpaid services may be used by Google to improve its products, while content sent to the paid services is not used that way.
Google, Gemini API Additional Terms of Service.
eety calls Gemini through Vertex AI, which sits under Google Cloud terms, and uses paid services. We do not run customer work on an unpaid tier.
SerpApi is the one service that queries Google Patents, Google Scholar and Google web search for the server. Below: each engine, the step that uses it, and what the query contains.
| Engine | Used by | What the query contains |
|---|---|---|
| Google Patents | The state-of-the-art search in harvesting (10 patent queries); the keyword, assignee, inventor and citation steps of a prior-art search, up to 300 results screened per string | A search string with its field scopes, result count, page number |
| Google Patents details | Reading a reference in full before it is graded | A publication number |
| Google Scholar | The non-patent literature step of a prior-art search (10 scholarly searches) | A search string, result count, page number, language |
| Google web search | The state-of-the-art search in harvesting (5 non-patent queries); the literature step of a prior-art search (5 web searches) | A search string; a site-restricted string for documents you add |
| Google Images, Google Play, YouTube | The literature step, for the non-patent source types that are images, apps and videos | A search string, result count |
Never sent through SerpApi: the disclosure, drafts, claims, review findings or any file. SerpApi is a sub-processor and appears on the sub-processor list, available on request. Prior-art search is enabled per organization on request.
Two steps of a prior-art search read pages on the open web: the literature step reads the papers, articles and product pages that the searches found, and the known-art step reads the URLs you pasted. The server fetches them directly, the way a browser would, with a guard that refuses private and internal addresses.
Those pages are wherever the results lead, so this path cannot be reduced to a fixed list of hosts. That leaves you three choices.
General HTTPS egress
Allow outbound HTTPS from the application host. The simplest rule, and the one the cloud edition runs with.
An outbound proxy
Route the fetches through your proxy, so your logging and filtering apply to them like any other outbound request.
Switched off
Allow only the fixed endpoints: Vertex AI, SerpApi, your mail relay. The prior-art search keeps its patent steps and loses the literature and known-art steps, and the report says so.
These are in the product today, cloud and on-premise alike. We list them here so a questionnaire can be answered straight from this page.
Tenant key on every customer table
Every row of customer data carries the organization it belongs to, and every query is scoped by it. On-premise there is one tenant: yours.
Per-matter ledger
Every token spent is recorded against a matter and a person: who ran which service on which invention, and when.
Audit log
Who uploaded, edited, exported, assigned and approved what, on every matter, kept in your database.
Department and role access
Two departments, IP / Innovation and R&D, and 8 roles. Inventors see their own inventions and the linked searches and reviews, read-only; the IP team's areas stay closed to R&D roles.
Customer-managed keys, supported
When Google Cloud Storage is used for the file store, your own encryption key can be set on the bucket. Supported, not switched on by default. On local disk, encryption at rest is whatever your disks do.
Session controls
Sessions end after 15 minutes of inactivity. Sign-in is rate-limited at the reverse proxy. Self-registration is switched off on a single-customer deployment, so only invited people can join.
A questionnaire usually asks about these. Better that you read the honest answers here than find them out halfway through a call.
No SOC 2, no ISO 27001
We hold neither certificate today. We answer security questionnaires on request from the controls listed above, and we would rather do that than show a badge we have not earned.
No SSO, SCIM or enforced MFA
Sign-in is email and password or Google sign-in. There is no SAML or OIDC single sign-on, no SCIM provisioning and no enforced multi-factor authentication today.
Not air-gapped, no private model
The AI model is Google Gemini, reached over the network. There is no offline mode that produces real output, and no bring-your-own-model option.
No installer, no automatic updates, no built-in backups
eety engineers deploy and upgrade the software under a services agreement. Backups are yours. We do not name a data-residency country: the Vertex AI region is set per deployment and written into the agreement.
All three are available on request, along with a walk-through of this sheet with your security and network teams. Last updated 26 October 2026; the date changes whenever a path, an engine or a control changes.