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. 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. |
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.
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.
One honest caveat
When a request fails, we store the provider’s error message so you can see why. Providers write their own error text, and some quote a fragment of the input back in it — a content-policy refusal, for example. We do not ask for that and we do not parse it, but it means a failed request can leave a trace of its content in the error field. It is deleted with the rest of the request record on the schedule in clause 10.
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. We publish each endpoint’s declared data policy in the catalog so you can see it before you route to it, and where a provider’s policy is unclear we mark it as retaining and training rather than assuming the generous reading. Providers we cannot verify are labelled unknown, not favourable.
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.
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. [PIA-2026-001 is drafted (docs/QUEBEC-PIA.md) but NOT in force: it needs counsel review and Privacy Officer sign-off. Replace this with the reference and approval date once signed. Do not publish this page to Quebec users before then]
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) | 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. |
| Provider credentials | Until you delete them, or your account closes. |
| 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. |
| 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.