Yenta privacy policy
Version: 2026-10-14. Effective date: 2026-10-14. Contact: support@yentaknows.ai.
Yenta publishes hospitality venues' and travel destinations' own information to
AI assistants. This policy covers the two things Yenta runs: the public
connector endpoints (https://mcp.yentaknows.ai/mcp, each
https://{slug}.venues.yentaknows.ai/mcp and each
https://{slug}.destinations.yentaknows.ai/mcp, together with the public web
pages served on the same hosts) and the partner control plane, where venue
staff manage their content.
The short version
- The connector is anonymous and reads, with one exception: an assistant can send Yenta a feedback report. Yenta has no consumer accounts and stores no personal information about the people who use it.
- Everything Yenta publishes about a venue is that venue's own information. Usually the venue uploads and approves it. For a few launch venues, Yenta prepared and approved it from the venue's own website and menus (see Venue content). The one exception is the two demo venues (Demo Bistro and Demo Trattoria): fictional sample content Yenta wrote and published itself, so that the connector can be evaluated without pointing an audience at a real partner. They are labelled as samples wherever they appear.
- Destination content is collected from the official tourism board's own website, under an agreement with the board (see Destination content).
- The only personal data Yenta holds is the work-contact identity of the venue staff who use the partner control plane.
If you use Yenta through an AI assistant
Connecting Yenta requires no account, no sign-up and no credential of any kind. Yenta does not know who you are and does not try to find out.
- No accounts, no profiles, no history. There is nothing to log in to, so there is nothing to keep. Yenta cannot recognise you across two questions.
- No cookies, no analytics, no advertising trackers on the connector endpoints.
- No storage of your questions. A search term is used to answer the request and then discarded with the request. It is not written to the database and not written to the logs. The one thing Yenta keeps about a search is described under What Yenta counts: when a directory search finds nothing, which published city and which filter categories it used, taken from Yenta's own fixed lists, never the words you typed. The one exception is a feedback report (below), which is stored because sending it is its purpose.
- Reads, plus feedback. No tool Yenta exposes can book anything, change
published information, or send a message to a venue. The one tool that stores
anything is
send_feedback. - Feedback reports. When an assistant uses
send_feedback, Yenta stores what it sent: the kind of report, the message, and any of the optional details it chose to add (the tool, venue or city the report is about, the model and app that sent it, and what the person was trying to do), with the time and the broad assistant family (Claude, ChatGPT, Gemini or other). No account, IP address or browser or app identifier is stored with it, and it is never shown publicly or written to the logs. Yenta's team reads reports to fix and improve the directory. Leave personal details out of a report.
Your AI assistant is a separate service with its own privacy policy. Whatever you type reaches Yenta through it, and what that provider records of your conversation is governed by their terms, not ours.
What is in the logs
Yenta's application logs are built from an allow-list of seven fields — timestamp, level, logger name, message, environment, the tenant a request belonged to, and a synthetic per-request correlation id, generated in our application, never derived from your IP, identity, or headers. Request bodies, query strings, headers and exception tracebacks are never written, because those are exactly where user-supplied text ends up. Logs are stored in Amazon CloudWatch Logs, in the same AWS region as the rest of Yenta, and are retained for 30 days and then deleted by the platform.
What Yenta counts
To know which parts of the connector are used, each request to a tool, page or read writes one usage line into those logs. It records only:
- which tool, page or read was used, and whether it came through the connector, the REST API or a web page;
- which venue or destination it was about, and the version of the content served;
- the outcome: answered, answered with no results, not available, or invalid input;
- when a directory search returns no results: the published city it was resolved to and the names of the filter categories it used (for example "vibe" or "price band"), so that Yenta can see what people look for and do not find. These come from Yenta's own fixed lists. A city that is not published is recorded only as "unresolved"; the text of the search is never recorded;
- the family of AI assistant that sent the request: exactly one of "claude",
"chatgpt", "gemini" or "other". It is worked out from the
User-Agentheader while the request is in flight; the header itself is never written anywhere.
A usage line never carries your IP address, a header, an account or session identifier, or any argument you or your assistant sent. Yenta adds usage lines up into daily totals per tool, venue or destination, surface, outcome and assistant family. Those totals contain no request-level data and are kept for up to 730 days. A partner sees the assistant-family split only for its own venues or destinations, and small figures in it are hidden.
To choose a format, Yenta also reads the User-Agent header while a request is
in flight: known search and AI crawlers are served the HTML version of a page
rather than plain text. That decision is not recorded.
Our edge applies a per-IP request-rate limit, which necessarily processes the source IP address of a request in transit. Yenta does not write it to a log or store it against any record; AWS WAF, which enforces those rules, briefly retains a rolling sample of the requests evaluated by our edge protection — including the client IP and headers — for a few hours, viewable only by us and used only for security monitoring.
Venue content
Venue content (profiles, menus, prices, dietary tags, allergen declarations, FAQs) is the venue's own information, and it is published only after someone with an owner or admin role explicitly approves the exact revision. Usually the venue or its operator supplies it and approves it. For a few launch venues, Yenta prepared the content itself from the venue's own website and published menus, and Yenta approved it. Such a venue can ask support@yentaknows.ai to correct or remove it at any time. Yenta does not infer or invent information a venue has not published. When Yenta's menu importer files a venue's own cuisine and dietary terms under Yenta's fixed vocabulary, the result is marked inferred.
Partners grant Yenta the right to republish their approved content to AI agents as a term of using the service — that term is section 3 of the partner terms. A venue can withdraw at any time: unpublishing takes their endpoint offline on the very next request, with no cache to expire.
Published venue content is business information, not personal information. If a venue chooses to put a named person's contact details into a FAQ, that is the venue's publication decision and the venue can edit or remove it the same way.
Destination content
A destination is a place, such as Los Cabos, published with the agreement of its
official tourism board. Visit Los Cabos has agreed that Yenta may use the content
of the board's official website. Yenta collects it with an automated crawler that
reads the website's public pages one at a time, follows the site's robots.txt,
and identifies itself as Yenta. It collects the destination guides, events,
offers, FAQs, areas, seasonal information and the businesses the board lists.
Listings, events, offers and guides link back to the board's page they came from.
The text is the board's own wording. Yenta's software changes it only in these ways:
- Cleaned and trimmed. Page formatting is removed, and text longer than Yenta's field limits is cut at a word boundary.
- Filtered. Past events are left out. On the English site, events written in Spanish are left out too, and businesses whose description is in Spanish are labelled as Spanish. Map points that are clearly wrong are removed: one outside Baja California Sur, or one point shared by several businesses.
- Organised. The board's categories and amenity labels become Yenta's search tags, and Spanish labels are matched to their English equivalents. Yenta puts the listed businesses in its own order, with the board's featured businesses first. Each area's map point is the average position of the businesses in it.
- What Yenta adds. The short activity highlights for each month (for example "Whale watching") are labels Yenta wrote from the board's pages. Each month's seasonal note is either the board's own paragraph from its weather page or a short summary Yenta wrote from the board's weather, whale-watching and sport-fishing pages, citing them. Yenta also works out which cuisines and dietary terms describe the destination as a whole, from the listed businesses' tags. It keeps only terms on its own fixed list and stores them marked as inferred, never as the board's statement.
Nothing else is added or reworded. Each collection is approved in Yenta's partner control plane before it goes live; Yenta, not the board, approves it. A business listed by the board can ask the board or support@yentaknows.ai to correct or remove its listing. Like venue content, it is business information, not personal information.
If you work at a partner venue
The control plane is where venue staff onboard, upload menus, and approve content. It is not public: every request is authenticated, and it is the only part of Yenta that holds personal data.
What is stored, and why:
| Data | Why it exists |
|---|---|
| Your identity-provider subject (the opaque ID your login provider issues) | Identifies you across sessions; it is what every permission check joins on. |
| Your email address, as verified by your identity provider | Contacting you about your organization's content. |
| Your organization membership and role | Deciding what you may see and change. |
| Audit events: what changed, when, in which organization, by which subject | Answering "who approved this revision" — a requirement of publishing content on a venue's behalf. |
| The subject of whoever reviewed a content revision | The same, recorded on the revision itself. |
That is the complete inventory. Yenta stores no name, no phone number, no address and no payment details for control-plane users; there is no billing system in this version of the product.
Audit events record identifiers, counts and versions — never content bodies, names or email addresses. "Revision 8f1c… was approved by subject auth0|… at 14:02, and became content version 3" is the shape of every entry.
How long it is kept
- Your user record and memberships: for as long as you have access.
- Audit events: deleted after the configured audit-retention window, 730 days by default, by a quarterly maintenance task run by Yenta operators.
- Content revisions: kept while the venue keeps them, including superseded ones, because they are the record of what was published when.
- Application logs, including usage lines: 30 days in Amazon CloudWatch Logs (see above).
- Daily usage totals: up to 730 days. They contain counts, not requests.
- Database backups: retained on a rolling 7-day window; deletions reach backups as those backups age out.
Deleting your account
Ask your organization's owner, or email support@yentaknows.ai from the address on the account. Deleting a user removes the user record and, with it, every membership and every grant of access — immediately, everywhere.
One thing deliberately survives it: audit events keep the bare subject string. An audit trail that can be rewritten by the person it describes is not an audit trail, and partners rely on it to answer who approved what. After a deletion those rows retain an opaque identifier that no longer resolves to a person, name or email address in any Yenta system, and they are deleted in the ordinary course when they reach the retention window above.
Your organization's venue content is not yours to delete: it belongs to the organization and stays with it. To take a venue offline, unpublish it.
Where the data lives
Yenta runs on Amazon Web Services in a single region, in private networks with no public database endpoint. Logs are kept in Amazon CloudWatch Logs in that region. Data is encrypted in transit (TLS on every public surface) and at rest. Yenta does not sell data, does not share it with advertisers, and has no analytics or data-broker integrations.
Changes and contact
Material changes to this policy will be posted here with a new effective date.
support@yentaknows.ai — privacy questions, data-access and deletion requests, and anything else.