Security

1.1How to read this document

In plain EnglishThree labels do most of the work: in place, designed for, and not decided.

Troy

Troy, the trading name used on this site and in this document. The company meant to sign a contract with you is Troy Agency Inc., incorporating federally, under the Canada Business Corporations Act, with its registered office in Ontario. That incorporation has not completed: there is no corporation number yet, and the blank is where it will go — To be completed: There is no corporation number yet, which means the federal incorporation has not completed. Until it has, Troy Agency Inc. is an intended name rather than a company: it cannot sign a contract, and calling itself “Inc.” in one would be wrong. This is the first thing to finish.[companyNumber]. Until it does, the name is an intended one rather than a company, which is one more reason nothing on this page is a contract.

The platform

The product described elsewhere on this site: the workspace, the automated Troy Score, the agents and the approval queue. It does not exist yet, and every sentence in this document about the platform is about something that has not been built. A Troy Score itself is available today, because a strategist prepares it by hand.

The service

What Troy sells today. A named strategist runs a client’s marketing inside the client’s own accounts, on an internal console assembled from third-party tools, the platforms’ official connectors and AI workflows.

Client accounts

The advertising, commerce and email accounts a client owns and grants Troy access to. They stay the client’s throughout, and so do the connection tokens.

A write

Any change made inside a client account, including creating something that is switched off — a paused ad or an unsent draft is still a write.

In place

True today, for the service as it is sold now. A reader may hold Troy to it.

Designed for

A commitment Troy is designing to. Not built, not tested, and not something to rely on yet.

Not decided

Troy has not made the decision. The page prints the open question where the answer should be, rather than filling the gap.

1.2What this document does not claim

In plain EnglishSaid out loud, so nothing here can be read as more than it is.

• No certification, audit or attestation. Troy holds none, has started none, and none is scheduled.
• No standard is claimed as met — not ISO 27001, not SOC 2, not PCI DSS, not any framework under another name. Troy does not describe itself as certified, compliant or audited, here or anywhere else.
• No encryption detail. This document names no cipher, no key length and no storage configuration, because there is no production system to describe and describing one would be invention.
• No credit for a supplier’s controls. This website runs on Vercel Inc., in Vercel's Washington, D.C. region (iad1), in the United States, so part of Troy’s posture is inherited from a company Troy does not run and has not assessed. Inherited posture is worth having and it is not a security programme, and naming a well-known host is not a way of borrowing its assurances — see clause 6.1.
• No penetration test, red team exercise or bug bounty. None has been run, and none is commissioned.
• No uptime, availability or response-time commitment. There is nothing running yet to be up, and no support target has been set.
• No insurance. Troy holds no professional indemnity and no cyber insurance. There is no policy standing behind anything on this page, and a buyer should read every commitment here in that light — see clause 6.3.
• No claim that client data stays inside Troy. Troy, Louin and Lunari Group share systems and data. Client data is held on systems Lunari Group runs, and the companies in the group can see each other's data. That is a wider circle than a reader of a security page would assume, so it is said here as well as at clause 4.3.
• No claim that a rule is enforced when it is only written down. Where a control is a policy on paper rather than something a system prevents, this document says so.

3.1Least privilege

In plain EnglishIf reading is enough, Troy asks only to read.

Troy asks for the lowest access tier that does the work in front of it, on each account separately. A Troy Score needs read-only access and Troy asks for nothing more to produce one: read-only is the lowest tier on every platform Troy connects to, and nothing in the account is changed to produce a score. Access that allows changes is asked for only where the engagement requires changes, and only for the accounts in scope.

The platform is being built in the order the ad platforms grant access — read, then draft, then act under a cap — because that is also the order in which an agent can be trusted with anything. See clause 4.4.

3.2The client owns the accounts and the tokens

In plain EnglishYou can take Troy’s access away yourself, today, without asking.

Every account Troy works in belongs to the client, and so does every connection token. Revoking Troy’s access is something a client does in their own platform settings. It is not a request filed with Troy, it does not need Troy’s cooperation, and Troy cannot prevent it.

This is in place today and it is deliberate. It is also why the service is built around a person with a seat rather than a Troy-held integration: if every token died tomorrow, the client would still control what happens next.

3.3Every write lands paused or as a draft

In plain EnglishAn agent can build the thing. It arrives switched off.

The floor of the approval queue is that an agent’s work lands as a paused ad or an unsent draft, whatever policy a client has set for the tool that produced it. Nothing reaches an audience because an agent decided it should.

Designed for, not built. Only one of the platforms Troy connects to supplies an approval step of its own, so on the others this is entirely Troy’s to build. Today the equivalent is a person: a strategist makes changes the client has agreed to, and asks when the answer is not obvious.

3.4No live change without an approval record

In plain EnglishIf it spends money or reaches an audience, a named person said yes, and it is written down.

The record is meant to name the person, the change, the time and what the setting was before. An approval is meant to be able to wait without losing its state, so that no client is pushed into approving something quickly because the request is about to expire.

Designed for. Today the record is written by Troy rather than produced by a system, which means it depends on Troy being disciplined rather than on a system refusing. That is a weaker guarantee and this document will not describe it as a strong one.

3.5Hard spend caps, enforced at the platform as well

In plain EnglishA fault in Troy should not be able to spend your money.

A cap is designed to be hard: over the cap is refused, not queued for later. The cap is meant to be set in the client’s ad platform as well as inside Troy, so that a bug, a bad instruction or a compromised agent in Troy cannot spend past a limit the client set somewhere Troy does not control.

The first version of the platform is not designed to make an unattended change to live spend, at any size. Designed for, and not built. Today, spend is changed by a strategist working to an agreed brief, under whatever budget limits the client has set in their own accounts.

Troy never holds client media money. Clients pay the advertising platforms directly, on their own payment method. That is in place today and it is not a step on a roadmap to holding it.

3.6A permanent change log, with a way back

In plain EnglishReverting adds a line. It never removes one.

Every change is intended to be written to a log that is permanent and revertible. A revert is written above the original as a change of its own; the original stays. A client should be able to read the log without asking Troy for it.

3.7No number that did not come from an API response

In plain EnglishA figure you cannot trace is not evidence.

Every figure in a Troy report traces back to the API response it came from. Nothing is estimated into a report, modelled into one, or carried over from a previous month because it looked about right. Where Troy cannot get a number, the report says the number is missing.

In place today, as a rule a strategist works to by hand. It is a data-integrity rule rather than a security control, and it is here because the most common way a marketing supplier misleads a client is with a number nobody can trace.

3.8Client data is not pooled by default

In plain EnglishComparing your account against other people’s needs your separate yes.

Using one client’s account data to build benchmarks across clients is a different purpose from running that client’s marketing, and Troy treats it as one. It is designed to need separate, specific opt-in consent, to use aggregate measures only, and never to be tied to a discount or made a condition of anything.

Pooling between clients is not the only way data moves, and this clause would be misleading if it were read as the whole picture. Troy, Louin and Lunari Group share systems and data. Client data is held on systems Lunari Group runs, and the companies in the group can see each other's data. That is described, with the part of it that is still open, at clause 4.3.

The AI vendors used in the work are OpenAI and Anthropic. Troy’s intention is to use them on plans that do not allow the provider to train on what is sent, and to choose the settings that keep it that way. That is an intention rather than a confirmed fact, and this page will not describe it as a guarantee. Where AI is used in the work, the AI disclosure document describes it.

4.1Access for a Troy Score

In plain EnglishRead-only, and you can take it back the same day.

A Troy Score is free and is prepared from read-only access to the accounts a client chooses to include, plus their public website. Nothing in the accounts is changed to produce one. Access can be removed the same day, the work stops when it is, and a report already sent is the client’s to keep and to act on, including with somebody other than Troy. What rights attach to work Troy produces in a paid engagement is a question for the service terms, not for this page.

A score is a graded read of the state of an account. It does not predict results and Troy does not claim that it does.

4.2Access for an engagement

In plain EnglishA working seat on the accounts in scope, and nothing outside them.

Where Troy’s team runs a client’s marketing, the strategist needs access that allows changes. Troy’s commitment is to ask for the lowest tier that does the agreed work, on the accounts in scope, and to explain what each request is for.

• Troy does not ask to become the owner of a client’s business account, advertising account, domain or store. Ownership stays with the client.
• Troy does not ask for access to accounts outside the agreed scope, and a request to widen the scope is a conversation, not a form.
• Where the client wants a change made by someone else — their developer, their other agency — Troy does not need access to that system to say what needs doing.

4.3Who has access, inside Troy and inside the group

In plain EnglishA named person does the work. Troy is small, and says so rather than implying a department. And Troy’s systems are the group’s systems, so the honest answer to “who has access” is wider than Troy.

Access to a client’s accounts sits with the named strategist on that client’s work and with the people who must cover for them. Troy is a small, pre-launch company; it does not have a security team, an access-review function or an on-call rota, and this document will not imply otherwise.

Troy’s commitment is that when someone stops working on a client’s account, their access to it is removed. The client can verify that themselves in their own platform settings, and should — see clause 9.

Outside the strategist, the circle is wider than Troy’s own people, and it is wider than an earlier version of this page said. Troy, Louin and Lunari Group share systems and data. Client data is held on systems Lunari Group runs, and the companies in the group can see each other's data. Engineering help in Troy’s first months may come from Lunari Group as well. So a client should read “who has access” as the named strategist, the people covering for them, and the people inside Lunari Group who run and support the systems the data sits on.

That makes Lunari Group a processor of client personal data rather than a related company at arm’s length, and it belongs on the published sub-processor list for that reason — see clause 5.1. What it does not make it is authorised. Under PIPEDA, using someone’s personal information for a purpose they were not told about needs their meaningful consent, and whether the people whose data sits on those systems — a client’s customers, and Louin’s — were told about this purpose is exactly what has not been settled. This page discloses the sharing. Disclosure is not a lawful basis, and this page does not claim to be one.

4.4Access the platform will ask for, stage by stage

In plain EnglishRead first, then draft, then act under a cap. None of it is built.

The platform is being built in the order the advertising platforms grant access, which is also the order in which an agent can be trusted. The table is the plan, not a description of anything running.

5.1Sending things to Troy

In plain EnglishEmail is not a safe place to put anything sensitive. Ask first.

Clients send briefs, spreadsheets, creative and occasionally exports from their own systems. Email is not a secure channel and Troy will not pretend it is. Troy’s commitment is not to ask for personal data it does not need, and to say so when a file contains more than the work requires.

Never send credentials of any kind, even if a message appears to ask for them. Before sending a file containing personal data — a customer export, a list, anything with names and contact details in it — ask Troy whether it is needed and how it should be sent.

Troy cannot yet tell a client every system a message or an attachment passes through: the tools that will run the business are not all chosen, and the ones already in use are not written down anywhere a client can read. What is already known belongs on the published sub-processor list. Vercel Inc. runs this website, in Vercel's Washington, D.C. region (iad1), in the United States. Lunari Group runs the systems a client’s data sits on, which is not a technicality and is set out at clause 4.3. OpenAI and Anthropic are the AI vendors used in the work. The data processing addendum proposes 30 days' notice before a new sub-processor starts, with a right to object in that period (a proposed default, not yet approved)?, so a client can object before a new one starts. What is still missing from that list is recorded at clause 6.

5.2Paying Troy, and paying for media

In plain EnglishYou pay the ad platforms yourself. Troy never touches media money.

Clients pay the advertising platforms directly, on their own payment method, and Troy never holds media money. Troy therefore has no reason to hold card details for media, and does not ask for them.

Troy’s own fees are a separate matter, and how Troy invoices and takes payment is set in the service terms rather than here. Nothing about paying Troy requires a client to share a card number with a person by email.

6.1Where the platform will run

In plain EnglishThe host is chosen and so is the region: Troy is Canadian and this site runs in the United States. The host’s security is the host’s, not Troy’s.

This website runs on Vercel Inc., in Vercel's Washington, D.C. region (iad1), in the United States, and the platform is intended to run there too. That is a decision about infrastructure, not a control Troy operates. Vercel Inc. runs the machines, and whatever it does or does not do about physical security, patching and network defence is its own; Troy has not assessed it and does not present it as an assessment.

So part of Troy’s posture is inherited rather than built, and a reader should keep the two apart. Inherited posture is worth having; it is not a security programme, it was not chosen by a security function Troy does not have, and it says nothing about how Troy itself handles access, approvals or an incident. A buyer who wants assurance about the infrastructure should read Vercel Inc.’s own published material and treat it as Vercel Inc.’s statement. A buyer who wants assurance about Troy should start at clause 1.2.

Said plainly, because a Canadian client has a right to hear it without digging: Troy is Canadian and its site is not hosted in Canada. What a visitor sends through this site, and what Troy runs on the same infrastructure later, is handled on machines in the United States and is subject to the law where those machines are, including lawful access requests made there. A client with a data-residency requirement should raise it before granting access, because nothing on this page satisfies one.

For personal data leaving Canada — which is all of it, because the site runs in Vercel's Washington, D.C. region (iad1), in the United States — the safeguard Troy would rely on is the Standard Contractual Clauses, with the UK Addendum where the United Kingdom is involved, entered into through each supplier's own data processing agreement (a proposed default, not yet approved)?. That is a proposed position rather than a checked one: it depends on facts about Troy and about each supplier that are not settled. Under PIPEDA an organisation stays accountable for personal information it hands to a processor, wherever that processor is, and the Commissioner’s published guidance is that people should be told when their information is handled outside the country. This page is part of telling them. Whether Troy’s notices and agreements are enough is a question for a lawyer and has not been asked, and it is the data processing addendum rather than this page that a client should hold Troy to.

6.2What is kept, and for how long

In plain EnglishThere are periods now. Nobody has approved them.

Server and access logs are proposed to be kept for 90 days (a proposed default, not yet approved)?. A log kept forever is a liability and a log deleted immediately makes an incident impossible to investigate, so this is a real decision rather than a formality, and the period is a conventional default rather than one measured against how long Troy would actually need — or against what Vercel Inc. keeps of its own accord, which Troy has not checked.

Data read from a client’s connected advertising and commerce accounts is proposed to be deleted within 30 days of the account being disconnected or the engagement ending, whichever is first (a proposed default, not yet approved)?. That period has to cover the copy on the systems Lunari Group runs as well as anything Troy holds itself, which means deleting on time is partly something Troy has to ask Lunari Group to do. No process for that is written down yet, and this page will not describe a deletion it cannot show. The privacy policy and the data processing addendum carry the same periods, and if this page and the addendum ever disagree the addendum governs.

How long to keep something is also a limitation question, and Canadian law pulls in two directions here. In Ontario the basic limitation period is two years from the day a claim is discovered, and the ultimate limitation period is fifteen years. PIPEDA separately requires an organisation to keep a record of every breach of security safeguards for two years, whether or not the breach had to be reported. A record destroyed on schedule can be a record Troy later needs. Whether that should change any of the periods above is a question for a lawyer, and it has not been asked.

6.3The security programme itself

In plain EnglishNobody owns security at Troy yet, and no certification is planned.

Troy has no named owner for security, no written security policy, no supplier assessment process and no schedule of reviews. This document is the first written statement of any of it.

On the data protection side there is at least a settled answer. No individual is named on this site. Privacy questions reach the person accountable for privacy at Troy through the address below — privacy@louin.io. No individual is named for security either, and Troy will not publish a name here until it belongs to a real person with real contact details who has agreed to carry it.

Troy holds no professional indemnity and no cyber insurance. That is not a gap this page papers over: there is no professional indemnity policy behind an error made in a client’s account and no cyber policy behind an incident, so a buyer who needs a certificate of insurance should take the absence as the answer and decide on it. If cover is bought, this document will say so and the version history will record the date.

One open item here is not a security control at all. The lawful basis for the sharing described at clause 4.3 is not settled, and a buyer assessing Troy should treat that as part of the same picture rather than as a separate paperwork question.

No certification is claimed, in progress or scheduled, and no date is offered for one. Naming Vercel Inc. as the host does not change that, because a supplier’s certifications are the supplier’s. When Troy can produce the report behind a certification of its own, this document will say so and the version history will record when that changed.

7.1What Troy asks of a reporter

In plain EnglishProve it, then stop. Do not take anyone’s data with you.

• Test only against Troy’s own systems. Never against a client’s accounts, a client’s website, or any advertising, commerce or email platform Troy connects to.
• Stop at the first proof. Do not access, copy, alter, keep or share anyone else’s data, and tell Troy at once if you saw any by accident.
• No denial of service, load testing, spam, or anything that degrades the service for other people.
• No social engineering of Troy’s people, clients or suppliers, and no phishing, however educational the intent.
• Nothing physical. No attempts against offices, devices or post.
• Give Troy a reasonable time to fix the issue before you publish it, and tell Troy when you intend to publish.
• Stay inside the law. Nothing in this document authorises anything unlawful, and Troy cannot grant permission over systems it does not own.

Troy does not run a bug bounty and does not pay for reports. A report that arrives with a demand for payment is treated as a demand rather than a report.

Troy will reply to a report, will not threaten a reporter who followed the rules above, and will credit a reporter who wants credit. Troy has not set a time within which it will reply, and this document does not invent one.

7.2Disclosure window and safe harbour

In plain EnglishTroy has not promised a fix deadline, and has not promised not to pursue a researcher.

8.1How quickly Troy will tell you

In plain EnglishThe law sets its own deadlines. Troy’s contract proposes one, and Troy has not tested whether it can meet it.

Troy is incorporating federally, under the Canada Business Corporations Act, with its registered office in Ontario, so PIPEDA is the statute that reaches Troy directly and the regulator is the Office of the Privacy Commissioner of Canada. People in the EU or the UK may also complain to their own national authority. Where a breach of security safeguards involves personal information under an organisation’s control, and it is reasonable to believe the breach creates a real risk of significant harm to an individual, PIPEDA requires that organisation to report the breach to the Commissioner and to notify the affected individuals as soon as feasible. Whether a given incident crosses that threshold, and which organisation has control of the information, are questions of fact rather than things this page can settle in advance: in a client engagement control usually sits with the client, and Troy’s first duty is to tell the client.

Where Troy handles personal data on a client’s behalf, control usually sits with the client, so the statutory clock is theirs and it starts when they become aware. What matters then is how fast Troy tells the client rather than whether Troy files anything itself. Troy sells in Canada and the United States. Troy does not offer its services to people in the European Union or the United Kingdom yet. A client whose own customers are in the EU or the UK may still be caught by the regimes there, and most US states impose their own duties towards their residents, California among them. Which of those bite in a given incident depends on where the affected people live rather than only on where Troy is, and Troy has not worked every combination through.

The data processing addendum proposes that Troy tells a client without undue delay and in any event within 48 hours of becoming aware of it (a proposed default, not yet approved)?. That is a conventional default written so the documents can be read end to end. It is not a deadline Troy has tested against its own capacity to meet it — Troy has no on-call rota and says so at clause 4.3 — and this document will not describe a number as a commitment before something stands behind it.

An incident on the systems Lunari Group runs is inside this, not outside it. If one happens there, it is an incident Troy tells the client about on the same terms, and Troy will say plainly that it happened on infrastructure Troy does not run rather than describing it as somebody else’s problem.

A client who needs a contractual notification deadline should ask for one in the contract rather than relying on this page. Troy would rather negotiate a deadline it can meet than publish one it cannot.