What we collect, why, who else sees it, and what you can make us do about it. The short version: we do not store your prompts unless you switch that on, we cannot read your provider keys, and analytics only runs if you say yes. Written to Canada’s PIPEDA, Quebec’s Law 25, and the Alberta and BC privacy acts.
Who we are and what this covers
Autonomous Relay Agents is operated by Tech Service 4U Inc. (“we”, “us”), a corporation incorporated under the laws of the Province of Manitoba, Canada, with its registered office at 17-955 Summerside Avenue, Winnipeg, Manitoba R3T 4Y1, Canada. This policy covers the autonomousrelay.com website, the Autonomous Relay Agents dashboard, and the API served at autonomousrelay.com and api.autonomousrelay.com.
We handle personal information under Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) and its ten fair information principles. We are based in Manitoba, whose own private-sector privacy act has been passed but never proclaimed into force, so PIPEDA governs our handling of personal information. If you live in Quebec, Alberta or British Columbia, your provincial privacy law also applies and we meet it. If you are in the UK or the European Economic Area, we additionally honour the rights described in clause 11.
For the rules governing your use of the service, see the Terms of Service.
One thing is worth stating before the detail, because it shapes everything else: Autonomous Relay Agents is a routing and metering layer, not a model host. We do not run models. When you make a request, it is forwarded to a provider you chose, on a credential you supplied, and their handling of that content is governed by their agreement with you, not by this policy.
What we collect, and why
PIPEDA requires us to identify the purpose of collection at or before the time we collect, and to limit collection to what those purposes need. It is easier to be precise in a table than in prose.
| Category | What it is | Why we have it |
|---|---|---|
| Account | Your name, email address and avatar as supplied by Google or GitHub when you sign in; whether the provider says the address is verified; the provider’s own immutable account id. If you sign in with a wallet, your public address and nothing else — a wallet has no email. | To identify you across sessions and show you who you are signed in as. |
| Organisation and workspace | Organisation and workspace names you choose, membership and roles. | To scope your keys, spend and settings to the right team. |
| Credentials | API keys are stored only as a hash — we cannot recover the key itself. Provider keys you add under BYOK are encrypted (clause 4). Names and labels you give them are stored as you typed them. | To authenticate your requests and dispatch them on your provider account. |
| Request metadata | For each API request: the model asked for, the model and provider that served it, token counts, latency, cost, status, finish reason, and whether it was cached, cancelled or streamed; and, where your request carries them, the end-user identifier you send as user, the referring page and the user agent. Not the messages. | To bill you accurately, show you your usage, and route around failing providers. |
| Billing | Credit purchases, ledger entries, invoice references and the Stripe session id. Card details never reach us — they go to Stripe directly. | To operate a prepaid balance and produce invoices, and to meet tax record-keeping obligations. |
| Technical and analytics | Session cookies, and — only if you accept analytics — pages viewed, actions taken, and your approximate location derived from your IP address. Clauses 5 to 7. | To keep you signed in, and to understand how the product is used. |
| Price-drop emails | If you ask on a model page to be emailed when its price drops — no account needed: your email address, the model, the language of the page, when you asked and that you asked from the model page, and when you confirmed by clicking the link we emailed you. Not your IP address. | To send you one email asking you to confirm, and once you have, an email when that model’s input or output price drops — nothing else. The record of when and how you asked and confirmed is how we show we had your consent, as Canada’s anti-spam law requires. |
| Incident emails | If you ask on the status page to be emailed about incidents — no account needed: your email address, the language of the page, when you asked and that you asked from the status page, and when you confirmed by clicking the link we emailed you. Not your IP address. | To send you one email asking you to confirm, and once you have, an email each time we post an incident or an update on the status page — nothing else. The record of when and how you asked and confirmed is how we show we had your consent, as Canada’s anti-spam law requires. |
We do not collect personal information for any purpose not listed here. If that ever changes, we will identify the new purpose and obtain your consent for it before collecting, as PIPEDA requires.
Your prompts and the model’s responses
We do not store the content of your requests or responses— unless an administrator of your own organisation turns that on. Off is the default, and it is the state every organisation is in until somebody with your own administrative access deliberately changes it.
With storage off, content passes through our servers in memory in order to be forwarded to the provider and streamed back to you. It is not written to disk and not retained after the request completes. There is nothing to disclose, leak or produce under a court order, because there is nothing there.
If your organisation turns it on
Request logging is a setting on your organisation, not on your account and not on ours. When it is enabled:
- It applies only to requests made after it is switched on. We never fill in history — content that was not stored at the time cannot be recovered later, by you or by us.
- What is stored is encrypted, each record under its own key, with the key material held in a managed key service. It is kept apart from the ordinary request records and cannot be read by the same path.
- You choose how long it is kept, subject to a floor of 90 days, and it is deleted automatically after that. You can also ask us to delete it sooner.
- You can exclude particular API keys from it. Where a key appears on both the included and excluded lists, excluded wins.
- Only your own organisation can read it back. There is no internal reader — no analytics job, no training pipeline, no support tool.
It is not available yet. The feature is built and the setting exists, but enabling it is held until our privacy impact assessment for transfers outside Quebec has been re-examined in light of it. We would rather describe it here and refuse to switch it on than switch it on and describe it afterwards.
The response cache
A separate, opt-in cache can answer a repeated request without sending it to the provider again. It is off for every API key until someone in your organisation turns it on for that key. When it is on, we keep the model’s answerto each eligible request — never the prompt, which is kept only as a one-way hash — encrypted in the same way as stored content, for the period set on the key: at most 24 hours, one hour by default. It is then deleted automatically. Only your own organisation’s identical requests can be answered from it, and an administrator of your organisation can empty it at any time.
It is not available yet, for the same reason as request logging: it is built, and switching it on is held until our privacy impact assessment has been re-examined in light of it.
Storing it for you is not consent for us
We do not use your inputs or outputs to improve any product, and we do not train models on them in any circumstance.
Agreeing that we may store your content so that you can read it back is not agreeing that we may use it for anything else. Our records keep the purposes you consented to, separately and by name, so that a purpose you never granted cannot inherit a permission you gave for something narrower. If we ever offer a feature that uses your stored content for any purpose beyond returning it to you, it will require its own explicit grant, and it will be described here first — as this was.
Failed requests
When a request fails, we record which provider failed, the HTTP status and the provider’s error code — not its error text. Providers write their own error text, and some quote a fragment of the input back in it — a content-policy refusal, for example. So that text is returned to you in the response and goes nowhere else: it is not stored with the request record and not written to our logs.
What the provider does is a separate question
Your request reaches a model provider — OpenAI, Anthropic, Google, DeepInfra and so on — on your own credential. What they retain, and for how long, is set by your agreement with them and by their own policies, not by us. The providers page links each provider’s privacy policy and terms.
Your provider keys
A provider key is the most sensitive thing you will give us, so it is worth describing exactly what happens to it.
- It is encrypted with AES-256-GCM using a data key generated for that credential. That data key is itself encrypted by a master key held in Google Cloud KMS, which never leaves the key service.
- Only the ciphertext and the wrapped data key are stored in our database. A copy of the database, on its own, decrypts nothing.
- There is no endpoint that returns a stored key. Not to you, not to our staff, not to support. Listing your credentials returns a four-character hint and nothing else. A credential store with a read path is one bug away from being a breach, so it does not have one.
- It is decrypted in memory only at the moment a request is dispatched to that provider, and only for a request your organisation made.
Deleting a credential removes the ciphertext. Because we never held the plaintext anywhere else, deletion is complete rather than best-effort. We still recommend rotating a key at the provider if you believe it was exposed anywhere in its life.
Analytics, and what we do with your IP address
If — and only if — you choose “Accept all”, we load Mixpanel and record how the product is used. Nothing is loaded, requested or initialised before that choice: the analytics library is not even downloaded by a visitor who declines.
Session recordings of the public pages (Microsoft Clarity)
The same choice also loads Microsoft Clarity on the public pages only — the home page, pricing, the model catalogue, providers, the documentation, status, the changelog and the legal pages. Clarity records how those pages are used (clicks, scrolling, and the page as you saw it) so we can see where the site is confusing. It never runs in the signed-in workspace, sign-in, invitations or the playground, and it stops the moment you navigate to one of them, so it never sees keys, credentials, balances, prompts or responses. The consent we send Microsoft refuses advertising use, and withdrawing your consent stops Clarity and deletes its cookies.
Google Analytics, through Google Tag Manager
On the same public pages and under the same choice, we load Google Tag Manager, which runs Google Analytics: which public pages are viewed, for how long, and from roughly where. It never runs in the signed-in workspace, sign-in, invitations or the playground. We tell Google that advertising storage, advertising use of your data and ad personalisation are all refused, and withdrawing your consent revokes the analytics signal too and deletes Google Analytics’ cookies.
What we send
- Which pages you viewed and which actions you took (for example, that a key was created — never the key or its name).
- Model identifiers, provider names, counts, durations and outcomes.
- Your organisation id, which is a random identifier meaningless outside our own database.
- Your IP address, from which Mixpanel derives an approximate city, region and country at the moment the event is received.
What we never send
- Prompt or response content, in any form.
- API keys or provider credentials, including hashes and hints.
- The names you give your keys — people put customer names in them.
- Email addresses, organisation display names, or credit balances.
- Guardrail filter patterns, which are written to match secrets and therefore describe them.
Being straight about the IP address
We enabled location data deliberately, and an IP address is personal information. We use it to understand which countries and cities our users are in, so we can decide where to place infrastructure and which markets to support. It is collected only under your express consent, it is associated with your organisation identifier, and you can withdraw that consent at any time. If you decline analytics, your IP address is never sent to Mixpanel.
Consent, and how to take it back
PIPEDA requires meaningful consent, and Quebec’s Law 25 requires it to be free, informed and given separately for each purpose. So we ask separately rather than bundling everything into one “I agree”.
- Running the service — your account, your keys, your requests, your billing. This is the contract you asked for; we cannot operate without it, and it is not something you can decline while still using the service.
- Analytics, including your IP address — separate, optional, off until you say yes, and revocable.
- Storing your prompts and responses — separate, off, and enabled only by an administrator of your own organisation.
- Marketing email — separate, opt-in, and every message carries a working unsubscribe link, as Canada’s anti-spam legislation (CASL) requires. Service and billing notices are not marketing and continue regardless.
- Price-drop emails — separate, per model, and asked for by you on that model’s page. We email you once to confirm, and send nothing else until you click that link; a request you do not confirm is deleted after 7 days.
- Incident emails — separate, and asked for by you on the status page. The same rule: one email to confirm, nothing else until you click it, and a request you do not confirm is deleted after 7 days. The status page also has a feed you can follow without giving us an address.
To stop incident emails, click the unsubscribe link in any of them, or your mail program’s “Unsubscribe” button: it deletes your address from the list at once.
To stop price-drop emails, click the unsubscribe link in any of them — one click, no sign-in. It deletes that subscription, and your address too once it follows no other model. Your mail program’s own “Unsubscribe” button does the same.
To withdraw analytics consent, use Cookie preferences in the footer of any page. It takes one click and takes effect immediately. Withdrawing is as easy as giving it, which is the standard, not a courtesy. If you have not answered the banner at all, we treat that as a refusal rather than an open question.
Where your information is held, and what that means
Our infrastructure runs in Google Cloud’s us-central1 region, in the United States, and the service providers above are predominantly US-based. Your personal information is therefore stored and processed outside Canada.
PIPEDA permits this, and requires us to be plain about the consequence: while your information is in another country, it is subject to the laws of that country, and may be accessible to its courts, law enforcement and national security authorities under their legal processes. We tell you this because you are entitled to know it before you decide to use the service, not because it is hypothetical.
We remain accountable for that information under PIPEDA, and we use contractual and technical measures to protect it — encryption in transit and at rest, and key material held in a managed key service. Prompt content is the material that would otherwise carry the most risk, and for organisations that have not enabled request logging — which is every organisation by default — it is simply absent. Where it has been enabled, it is encrypted under per-record keys and kept apart from the request records described above.
Quebec residents
Law 25 requires a privacy impact assessment before personal information is communicated outside Quebec, confirming that the receiving jurisdiction affords adequate protection. That assessment is not yet complete. Until it is, we do not offer the service in Quebec: requests that appear to come from Quebec are declined. If you live in Quebec, you can ask our Privacy Officer about its status (clause 16).
Routing is a separate question from storage
Independently of where we hold data, you can constrain where your requests are routed. Data-region guardrails restrict candidate providers to a region and fail closed — a request that cannot be served in-region is refused rather than quietly sent elsewhere.
An endpoint whose region we have not recorded counts as not in your region, and is refused for the same reason: we will not place a request somewhere we cannot name. Most of the catalogue is in that position today, so a region guardrail is restrictive by design — you can see which endpoints declare a region in the catalogue, under each model.
How long we keep it
PIPEDA requires us to keep personal information only as long as the purpose needs, and to destroy it after that.
| Information | Kept for |
|---|---|
| Account and organisation records | While your account exists, then destroyed within 30 days of closure. |
| Request metadata (tokens, cost, latency, and the end-user identifier, referring page and user agent sent with a request) | Retained 24 months for billing, reporting and provider rankings, then destroyed. Enforced by a scheduled job that drops each month of history once it ages out, not by manual housekeeping. |
| Financial records — purchases, ledger entries, invoices | Retained as long as Canadian tax and accounting law requires, generally six years from the end of the relevant tax year, regardless of account closure. |
| Request content | Not stored, unless an administrator of your organisation has enabled request logging — see clause 3. Where it has been enabled, it is kept for the period your organisation chose, at least 90 days, and deleted automatically after that. |
| Cached model answers | Not stored, unless someone in your organisation turns the response cache on for an API key — see clause 3. Where it is on, each answer is kept for the period set on the key, at most 24 hours, then deleted automatically. |
| Provider credentials | Until you delete them, or your account closes. |
| Hosted agent instructions and trigger templates | Encrypted, every version, until you delete the agent or the trigger, or your account closes. Deleting an agent deletes all of its versions and its triggers. |
| A hosted agent run paused for approval | Its conversation is held, encrypted, until someone approves or rejects the action or the approval expires (24 hours by default), and is then erased. |
| The goal text of a run | Cleared after 24 months, with the request metadata. The run’s budget and totals stay, as part of the billing record. |
| Batch records — whose batch, which provider, item counts and cost; never prompts or results | Deleted once the batch is settled and the provider’s results have expired, about 30 days. |
| Analytics events | Kept for 12 months, our analytics plan’s retention. If we move to a plan with a different retention we will update this figure. |
| Session records | Until expiry or sign-out, whichever comes first. |
| Price-drop email addresses | Unconfirmed requests: deleted after 7 days. Confirmed ones: until you unsubscribe, which deletes them at once (and your address, once it follows nothing else). The record that a given price drop was emailed: 30 days. |
| Incident email addresses | Unconfirmed requests: deleted after 7 days. Confirmed ones: until you unsubscribe, which deletes them at once, with the record of which updates were emailed to you. |
| Audit log of management actions — who in your organisation created or revoked a key, changed a setting or a member’s role, and when | Kept for 12 months, readable by your organisation’s owners and administrators, then deleted automatically. It names the person or key that acted; it never holds a key, a secret, an IP address or request content. |
| Breach records | Records of every breach of security safeguards are kept for 24 months, as PIPEDA requires, whether or not the breach was reportable. |
Prompt and response content appears in this table only because it can now be stored at your organisation’s option. Unless yours has enabled request logging, there is nothing under that row to keep.
Your rights
You can ask us to do any of the following. We apply these to everyone, wherever you live, rather than checking your province first.
- Access — tell you what personal information we hold about you, how we have used it, and who we have disclosed it to.
- Correct anything inaccurate or incomplete.
- Delete your information, subject to records we must keep for tax and accounting law.
- Port — receive the personal information you gave us in a structured, commonly used, machine-readable format, or have it sent to another organisation. This is a right for Quebec residents under Law 25 and we extend it to everyone.
- Withdraw consent for analytics or marketing at any time, subject to legal and contractual restrictions and reasonable notice.
Write to our Privacy Officer (clause 16). We respond within 30 days, which is the limit PIPEDA and Law 25 both set. Access and portability requests are free. If we need an extension or have to refuse part of a request, we will tell you why and tell you how to challenge it.
Automated decisions
The router chooses which provider serves each request, automatically, using price, latency, health and the rules you set. That is a decision about a request, not about you, and it has no legal or similarly significant effect on any person.
Where we do make a decision about you by automated processing alone — for example, an automated fraud or abuse control that suspends an account — Quebec’s Law 25 gives you the right to be told at the time of the decision, and on request to be given the personal information used, the principal factors that led to it, and the opportunity to correct that information and make representations to a person who can review the decision. We extend that to all users. Contact our Privacy Officer.
How we protect it, and what happens if that fails
- All traffic is encrypted in transit with TLS. Information is encrypted at rest.
- Provider credentials use envelope encryption with keys held in Google Cloud KMS, described in clause 4.
- API keys are stored as hashes. A database copy does not yield a usable key.
- Session cookies are httpOnly, so injected scripts cannot read them, and state-changing requests require a separate token.
- The API sits behind a web application firewall, with request logging retained so a block can be attributed and reviewed.
- Access to production systems is limited to staff who need it, and infrastructure changes are reviewed before release.
If there is a breach
No system is perfectly secure, and we will not pretend otherwise. If a breach of our security safeguards creates a real risk of significant harm to you, PIPEDA requires us to report it to the Office of the Privacy Commissioner of Canada and to notify you as soon as feasible. Our notice will describe what happened, what information was involved, and what you can do to reduce the risk. We keep a record of every breach for 24 months, reportable or not.
Children
Autonomous Relay Agents is a developer tool for business use and is not directed at anyone under 18. We do not knowingly collect personal information from children. If you believe a child has given us personal information, tell our Privacy Officer and we will destroy it.
Changes to this policy
When we change this policy we update the date at the top, and we publish notice of the change — Law 25 requires notice of every change, not only material ones.
If a change materially reduces your privacy — a new category of information, a new purpose, a new processor receiving your content — we will tell you by email or in the dashboard before it takes effect, and where the law requires fresh consent we will ask for it rather than assume it.
Our Privacy Officer, and how to complain
PIPEDA requires us to name the individual accountable for our privacy practices. That person is:
Harsh Patel, Privacy Officer
Tech Service 4U Inc.
17-955 Summerside Avenue, Winnipeg, Manitoba R3T 4Y1, Canada
admin@tecs4u.com
If you are unhappy with our answer
Tell us first — write to the Privacy Officer above. We will acknowledge your complaint, investigate it, and give you a written response within 30 days. If we were wrong, we will say so, fix it, and change the practice that caused it.
You do not have to come to us first, and nothing here removes your right to go straight to a regulator:
- Office of the Privacy Commissioner of Canada — priv.gc.ca
- Quebec — Commission d’accès à l’information du Québec
- Alberta and British Columbia — the Office of the Information and Privacy Commissioner for your province
- Manitoba and elsewhere in Canada — the federal Office of the Privacy Commissioner, above. Manitoba has no private-sector privacy commissioner, because its own act is not in force.