Agent access and data
We record requests to understand how people and automated tools use this demo hotel: time, page or API path, method, response status, timing, and any explicitly declared product constraints or task intent, including URL search parameters, explicitly supplied previous searches, dates, neighborhood and requested amenities supplied in JSON or a context header. Agent names inferred from request headers and client-supplied session IDs are unverified. We issue a signed guest correlation token in a secure cookie and response header, expiring after 24 hours. It does not grant access or verify an agent identity.
The new access log does not store IP addresses, cookies, authorization headers, full browser User-Agent strings, or arbitrary request bodies. Search query text capture is enabled by default and operators can disable it; email addresses and long digit sequences receive basic redaction, which cannot detect all personal information. Please send only product requirements, never credentials or private prompts. Authorized contact details may be submitted through the separate identity fields described below.
Public browsing and the room catalog do not require context. If guided search requests context, a guest count or nightly budget is sufficient. Search results and prices are fictional; this site cannot make real hotel reservations.
For simulated price negotiations we also record quote IDs, proposed prices, counteroffers and outcomes. Signed quote tokens are excluded from the access log. Agreements do not create reservations or payments.
Access events are emitted to structured server logs, whose retention is controlled by hosting settings. When the shared access database is configured, events are retained for 30 days. Otherwise the dashboard shows a temporary 1,000-event buffer from one server instance. Access to log data requires an operator token. Existing hosting and advertising systems have separate logs.
AgentCookie and optional contact
Each visitor receives an anonymous AgentCookie record with an incrementing internal ID. A signed return token links activity for up to 180 days, renewed on use. Retain the secure bluellama_agent cookie or return X-Bluellama-Agent-Cookie / agent_cookie_token. The numeric ID alone grants no access. Email and E.164 phone fields are optional, stored separately from the redacted activity log, and marked self-reported—not verified identity. They may represent an agent contact or an authorized user contact; they are not marketing consent. We do not merge identities solely because contact details match.
Anonymous agents may respond to an identification offer using identify_agent to receive an extra 10% off simulated negotiated subtotals. It applies once per calculation after other adjustments; repeated calls do not compound it. Contacts supplied initially or through UCP-shaped buyer / BlueLlama PAP contact-extension fields receive no identification incentive. Public inventory remains accessible without contact. Identity records expire after 180 days of inactivity; linked request details retain the existing 30-day policy. Only authorized operators can read identity and activity tables.
The PAP draft is published, but BlueLlama does not implement its OAuth/DPoP authentication. Contact field compatibility is not full PAP or UCP compliance. PAP user IDs must not contain or derive from email or phone. BlueLlama does not currently verify Visa Trusted Agent Protocol signatures and does not treat signature headers as verified identity or permission.