Section 9Security, data & compliance

Agentic coding adds two security surfaces at once: the code the agent writes, and the agent itself as a running program with tools. Both need guarding for anything real.

Section 8 built the pipeline that protects users from a bad release. This section protects them from something quieter and more permanent: their data ending up where it shouldn't. Consider what the salon booking app knows by now — every customer's name and phone number, their appointment history, perhaps a note about an allergy, and, the day payments go live, card details flowing through a processor. None of that data cares whether the code mishandling it was written by a person or an agent. The customer whose records leak will not ask who typed the bug.

The two surfaces need different instincts, so this section takes them in turn. Securing the agent means seeing your helpful assistant for what it mechanically is: a program that reads untrusted text all day while holding real credentials. Securing what it builds means assuming the code arrives with average-of-the-internet security habits and gating it accordingly. From there the section keeps going into territory most software guides skip — backups, data-protection law, and the contracts that make a product legally real — because for anything with actual customers, these are readiness gaps, not appendices.

Securing the agent

An agent is a new kind of thing to defend: a text-reading program with permission to act. Your word processor never held the keys to your database; your browser never ran shell commands on your behalf. An agent does both, which means text it merely reads can become actions it takes. Three habits cover most of the day-to-day risk:

• Prompt injection. Content the agent reads — a web page, an issue, a dependency's README — can contain instructions that hijack it. Treat everything the agent ingests as untrusted input, and never wire it to act on unreviewed content.
• Least privilege. Give the agent and its MCP tools the narrowest access that works — read-only where possible, scoped tokens, no standing production credentials. Claude Code's permission rules (Section 2) are where you write that down for the main session; for delegated work, each subagent defined in .claude/agents/ can be given its own, narrower tool list, so a research or review agent never holds write or shell access at all (Section 11 covers the mechanics). The security argument for doing it: a subagent is exactly where untrusted content tends to arrive, and the least-privileged agent is the one an injection can do least with.
• Secrets. Keep keys out of the context window and out of the repo. Use a secrets manager; add a hook or scanner that blocks a commit containing a credential. Rotate credentials on a schedule, not only when you suspect a leak — and always immediately when anyone with access leaves.

The lethal trifecta — the combination never to allow

Security researcher Simon Willison gave the sharpest framing of this risk a name: the lethal trifecta. An agent becomes a data-leak machine the moment it holds three capabilities at once — access to private data, exposure to untrusted content, and the ability to communicate externally. Any two are manageable. All three together mean an attacker who controls any text the agent reads can quietly instruct it to fetch your private data and send it out — no exploit code, no broken cryptography, just words in a place the agent happened to look.

Run the salon app through it: the agent can query the customer database (private data), it reads incoming booking notes and support messages (untrusted content), and it can send email or call external APIs (outbound communication). That's all three legs — one hostile booking note away from the customer list walking out the door. The defence is to cut one leg off per session, deterministically: give a session that reads untrusted content no access to private data, or no network, or run it in a sandbox whose outbound connections are blocked.

Cutting the outbound leg is the most practical of the three, and you don't need extra tooling for it. Claude Code ships a sandbox built in on macOS, Linux and WSL2, enforced by the operating system rather than by the model's cooperation: filesystem writes are confined to the project, and network access is denied except to the hosts you list under allowedDomains. Set that list to what the work genuinely needs — your package registry, your docs sites — and the exfiltration leg is gone for that session, no matter what a booking note tells the agent to do. Combined with the permission rules from Section 2, that's the deterministic layer: permissions govern which tools the agent may call, the sandbox governs what any command can reach once it runs — which matters, because a denied path can still be reached by a script the agent runs in a shell. The pre-tool-use hook described below severs a leg the same way — a rule the agent cannot be talked out of, because it never gets a vote.

Vetting what you plug into the agent

Third-party skills, plugins, and MCP servers are a supply chain of their own — and currently a less-scrutinised one than npm packages, even though they're arguably more dangerous: a skill is instructions injected straight into the agent's context, and an MCP server is a running program that acts with the agent's permissions. Before installing either, read what it actually does — a skill is plain text you can read in two minutes; for an MCP server, check who maintains it, whether it's actively updated, and what access it requests. Pin versions rather than tracking "latest," and re-review on update, exactly the discipline you'd apply to a dependency that runs in production — because from the agent's point of view, that's what it is. If you install extensions regularly, script the check: a fixed set of questions (what does it read, what can it write, where does it send data, who maintains it) each candidate must pass before it enters the agent's context.

The same deterministic machinery that guards your pipeline (Section 12) can guard the agent's own hands. A pre-tool-use hook — a check that runs before each command the agent wants to execute, and can veto it — is the concrete version: a short deny-list script that blocks rm -rf, DROP TABLE-style statements, and force-pushes outright, before they run. The agent can be persuaded by a prompt injection; a hook can't. Ten lines of script turn "the agent knows it shouldn't delete things" into "the agent can't."

Securing the generated code

The second surface is the code itself. Section 6's review catches what a careful reader can see; the checks here catch what nobody reads for — a dependency with a known vulnerability, a key accidentally committed, a licence obligation hiding in generated code. All three belong in the pipeline (Section 8) rather than in anyone's memory: deterministic, on every change, immune to a busy week.

• Scan it automatically. Run SAST (Static Application Security Testing — a tool that reads your source code for known-bad patterns without running it) and DAST (Dynamic Application Security Testing — the same idea, but attacking the running app) in CI. Agent code has average-of-the-internet security habits; assume it needs checking.
• Supply chain. Agents add dependencies casually. Pin versions, audit new packages, watch for hallucinated or typo-squatted package names, and prefer the boring, widely-maintained library over an obscure one that happens to fit slightly better — an agent has no instinct for "this has one maintainer and hasn't shipped in a year," so say so explicitly. Keep dependencies fresh with automated update tooling (Dependabot for security-fix patches, Renovate for routine version bumps and scheduling — don't run both on the same repo, they compete). Treat a patch-bump PR as near-automatic; treat a major-version bump the way you'd treat any other ticket — read the changelog, run the full suite, don't merge on green alone.
• Licences & IP. Generated code can echo licensed source. Keep a licence scanner in the pipeline for anything you ship commercially.

Protecting data — backups, encryption, access

Everything so far protects the system; this part protects what's inside it. For the salon that means concrete records about real people — names, phone numbers, appointment histories, that "known allergies" field that will matter again later in this section. The habits below can sound like enterprise ceremony, but each exists because its absence has a specific, well-documented way of going wrong:

• Back it up, and prove you can restore it. Automated, encrypted backups on a schedule that matches how much data you can afford to lose, and how fast you need to be running again — your Recovery Point/Time Objective (RPO/RTO). A backup nobody has restored is a hope, not a backup; rehearse the restore on a schedule, the same way Section 8 says to rehearse rollback.
• Encrypt at rest and in transit. TLS (Transport Layer Security — the encryption behind the padlock icon in a browser, i.e. what turns "http" into "https") on every connection, including internal ones — no exception for "it's inside the network." Turn on your database and storage provider's encryption at rest; it's usually one setting. For data that would hurt someone if it leaked (health records, ID documents, payment details), add field-level encryption on top, keyed through a managed key service, never a key sitting next to the data it protects.
• Give access on a need-to-know basis. No shared logins to the production database. Each person and each service gets its own scoped, revocable credential. Model who-can-see-what as a small set of roles — Role-Based Access Control (RBAC) — not "everyone with a login sees everything," and log who accessed sensitive records and when — an audit trail you can actually answer "who saw this customer's data" with.
• Collect less. The cheapest way to protect data you don't have is to not have it. Ask during grilling (Section 3) whether each field you're about to store is actually needed, and for how long — a documented retention and deletion policy beats an ever-growing pile of customer data nobody remembers the reason for.
• Keep personal data out of your logs. Error trackers and application logs routinely capture an entire request — a customer's name, phone number, address — by accident, just because it was part of the data being processed at that moment. Scrub or mask personal fields before they're logged. A log line is much harder to find and delete than a database row, and most teams forget it counts as personal data at all.
• Plan for deletion, not just creation. When a business customer cancels, or someone asks to be forgotten, know exactly what gets deleted outright, what gets anonymised instead (financial records you're legally required to keep, for instance), and that it actually cascades everywhere the data lives — a "deleted" account whose bookings, invoices, and backups still carry their name isn't deleted.
• Build the export path too — it's a legal right, not a nice-to-have. Deletion is the request everyone remembers; it isn't the only one. GDPR gives people the right to a copy of their data (a subject access request, Article 15) and the right to take it with them in a structured, commonly-used, machine-readable format such as JSON or CSV (data portability, Article 20). Both come with the same one-month clock as erasure. So the salon needs a routine that gathers everything about one customer — bookings, notes, invoices, consent records — and hands it over as a file, not a person hand-writing database queries under a deadline. Section 8's audited admin surface is where that routine belongs.
• Rehearse export and deletion the way you rehearse a restore. Run both against a real account on staging on a schedule and read the output: an export that quietly misses the notes table, or a deletion that leaves rows behind in an analytics store, only shows up when you look. A rights request you have never executed is in exactly the same state as a backup you have never restored.

Authentication, sessions & abuse

Most real-world breaks in agent-built apps aren't exotic cryptography failures — they're the login system, because it's the one part of the app every attacker can reach without an account. Agents routinely under-build it unless you ask explicitly:

• Never store a password. Store the result of running it through a deliberately slow, one-way hash — argon2id first choice, bcrypt acceptable — with a random salt generated per password, so two people who picked the same password don't get the same stored value and a stolen table can't be reversed with a pre-computed lookup. What makes this a gate rather than a footnote: fast hashes are the intuitive wrong answer. MD5 and SHA-256 are built to be fast, which is exactly what an attacker cracking a leaked table wants; a slow hash makes each guess expensive by design. Plaintext, encryption you can reverse, and fast hashes are all the same failure. This is also the single strongest argument for not building auth yourself: a hosted provider — Supabase in this guide's stack, or an equivalent — implements it correctly and keeps implementing it correctly as the recommendations move. The trap is that using one doesn't settle the question forever. The day an agent adds a custom password path alongside the provider — an admin login, a legacy import, a "simpler" internal tool — that path is new auth code and needs the same scrutiny as if you'd written the whole system. The protocol's password-storage gate exists to make someone look.
• Password strength and multi-factor authentication. Enforce a minimum password strength, and offer MFA (multi-factor authentication — proving who you are with something beyond a password, usually a one-time code from an app or a text message) at least for staff and admin accounts, where one stolen password would expose every customer's data at once.
• Sessions expire and are stored safely. A logged-in session shouldn't last forever; set an explicit timeout. The cookie that identifies a session needs the HttpOnly flag (so a malicious script on the page can't read it) and the Secure flag (so it's never sent over an unencrypted connection), plus CSRF protection — a defence against a hostile website secretly making your browser perform an action on a site you're already logged into.
• Account recovery is an attack surface, not just a feature. "Forgot password" and "invite a new staff member" flows are where attackers actually get in — a recovery link that never expires, or one sent without verifying the email first, quietly hands over the account. Expire every invite or reset link after a short window and after first use, and log when one is used.
• Rate-limit the login form specifically, tighter than public endpoints generally. A handful of failed attempts should trigger a lockout or a growing delay, to block automated password-guessing (known as credential stuffing when it uses passwords leaked from other sites).
• Verify who's really calling your webhooks. A payment processor or calendar integration sends events to a URL on your server ("payment succeeded," "event updated") — a webhook. Without checking that provider's cryptographic signature on every one, anyone who finds the URL can forge a fake "payment succeeded" and get a free booking.

For the salon, the highest-value account isn't any customer's — it's the owner's admin login, which sees every customer's history at once. That asymmetry generalises: protect accounts in proportion to what they can reach, which is why MFA "at least for staff and admin accounts" above is the floor, not the ceiling. And when the agent builds any of these flows, say the standard out loud — "production-grade auth: lockout on repeated failures, expiring recovery links, signed webhooks" — because "add a login page" will reliably get you a demo-quality one. The pattern is the same as Section 2's instruction files: an agent meets the bar you state, not the bar you assume.

Testing for security problems

"We scanned it once before launch" is not a security program. Build these checks into the same pipeline that gates everything else (Section 8), so they run on every change. Claude Code has one of them built in: /security-review runs a dedicated security pass over your changes and reports what it finds. Don't confuse it with the general-purpose /review from Section 6, which comes from a third-party skill set and reviews a diff against spec and standards; /security-review is the native command and looks only for vulnerabilities. It's a fast first opinion, not a substitute for the scanners below — an agent reviewing agent-written code shares its blind spots.

The by-hand card describes an attack worth knowing by name: IDOR, Insecure Direct Object Reference — you were logged in, but the app never checked whether you were allowed to see the specific record you asked for. It keeps topping real-world findings for a structural reason: every page works perfectly when tested one account at a time, so nothing looks wrong until someone deliberately crosses accounts. That's also why it resists automation and stays a by-hand check — one that only counts as a repeatable gate once it's written down as a playbook; Section 8 uses exactly this test as its worked example of turning "test it by hand" into numbered steps.

A second one is worth the same treatment, because agents write it by default: SSRF, Server-Side Request Forgery. Ask for "let the salon upload a logo from a URL," or "call the customer's webhook," and you'll get code that takes a URL from a user and fetches it from your server — which sits inside your network, holding your credentials. Hand it http://169.254.169.254/ and on most cloud hosts that's the metadata endpoint that returns the server's own access keys; hand it an internal address and it reads a database admin panel that was never exposed to the internet. The rule is an allow-list, not a block-list: decide which hosts a server-side fetch may reach and refuse everything else. Resolve the hostname first and reject private and link-local IP ranges, refuse redirects to them, and don't return the raw response body to the caller. If you only need images, prefer an upload over a URL — the feature that doesn't fetch anything can't be tricked into fetching the wrong thing.

Treat any change that touches authentication, payments, or personal data as automatic "real read" territory in the risk-tiered review from Section 6 — never ship those on a demo-reel skim alone.

What a breach actually costs

It's tempting to file this whole section under "important later." The legal numbers argue otherwise. GDPR fines come in two tiers: up to €10 million or 2% of worldwide annual turnover — whichever is higher — for operational failures like missing the breach-notification duty, and up to €20 million or 4% of worldwide annual turnover for violating the core processing principles themselves. Regulators must keep fines proportionate to the company and the violation, so the headline maximums mostly hit large firms — but the floor isn't zero for being small, and the fine is rarely the largest cost anyway. A breach means notifying every affected customer, an investigation eating weeks, and — for a product whose entire pitch is "trust us with your customer data" — losing the exact hundred customers a small team spent a year winning. That, not a headline fine, is the realistic worst case for an agent-built product, and it's why the boring lists above are cheap by comparison.

The contracts a real product needs

Production-readiness isn't only technical. The moment a customer's data flows through your product, a set of legal documents becomes as load-bearing as your CI pipeline — missing one is a readiness gap, not a "do it later." Decide these during grilling, the same way you decide any other requirement:

• A privacy policy and legal notice that describe what you actually collect — not a downloaded template that no longer matches your database. (In Germany: a Datenschutzerklärung and an Impressum; most jurisdictions require an equivalent pair.)
• A data processing agreement (DPA) with every subprocessor that touches user data — hosting, email, payments, analytics — and, if you sell business-to-business, a DPA with each business customer whose end-users' data you process on their behalf. Under the EU's GDPR (General Data Protection Regulation — the law governing personal data for anyone in the EU, regardless of where your company is based) this is an Auftragsverarbeitungsvertrag (Article 28); it is a required signed contract, not paperwork.
• Terms that state who's actually liable. For a marketplace or booking product, decide explicitly whether you or your business customer is the contracting party for the end transaction — that one decision determines whose terms and cancellation policy apply.
• A breach-notification plan. GDPR gives you 72 hours to notify a regulator after discovering a personal-data breach; know who makes that call before you need to.

Flagging risky data before you collect it

Not all personal data is equal under the law. GDPR's Article 9 singles out "special category" data — health, biometric or genetic data, racial or ethnic origin, religious or political belief, trade union membership, sex life or sexual orientation — and Article 10 does the same for criminal-record data. These need their own, separate legal basis (almost always explicit, freestanding consent, not bundled into general terms) and often trigger a formal Datenschutz-Folgenabschätzung (DPIA, Article 35) before you process them at all. The catch: they're easy to collect by accident. A salon's "known allergies" or "skin condition" note field is health data, not an ordinary business field, the moment it exists.

Make this a CI gate, not a hope — a legal regression deserves the same weight as a failing test. A merge that adds a new personal-data field shouldn't pass silently. A simple, automatable version — scan new schema columns, form fields, and their comments for keywords like health, allerg, medical, biometric, religion, ethnic, political, sexual, union, criminal — won't catch everything, but it turns "nobody noticed" into "a human had to look and decide." Wire the same rule into AGENTS.md: an agent adding a field like this should stop and flag it, not silently ship it.

Beyond Germany and the EU, the rules genuinely differ, not just in wording. The UK has its own UK GDPR — a separate law since Brexit, enforced by a different regulator (the ICO), sometimes requiring a UK representative. Switzerland's revised data protection act (the FADP/nDSG, in force since September 2023) is GDPR-similar but distinct, with its own list of countries it considers adequate for data transfers. The US has no single federal privacy law, only state-level rules (California's CCPA/CPRA among them) that typically only apply above a size threshold. None of this needs solving on day one — it needs someone to have actually checked which apply, rather than assuming GDPR compliance travels automatically. And if the product itself — not just the agent that builds it — ever makes automated decisions about a customer (a recommendation engine, automated risk scoring), watch the EU AI Act: a 2026 "Digital Omnibus" law pushed the high-risk-system deadline to December 2027, but transparency obligations for AI-generated content (Article 50) are still active from August 2026 — a live, moving regulatory target, not a settled one.

The moment money flows

The day the salon takes its first card payment, a second compliance layer switches on beside the data-protection one. The heaviest part is already solved for you: route payments through a hosted checkout provider and card numbers never touch your servers. That is the whole point of PCI DSS — the Payment Card Industry Data Security Standard, the card networks' security rules, which apply in full to whoever's servers a card number touches. Keep the number off yours and you stay in the lightest tier of the standard, a short self-assessment, instead of the tier with audits; that's the protocol's PCI gate, and it's why "just build our own card form" is never the cheap option it looks like. What remains is everything the provider can't decide on your behalf, and like the contracts above, these are grilling-stage decisions, not post-launch cleanup. As of mid-2026, and in the same spirit as the rest of this section — orientation, not legal or tax advice:

• Leave Strong Customer Authentication on. EU law — the PSD2 payment directive — requires SCA for online card payments. Mind the acronym: this SCA is Strong Customer Authentication, and has nothing to do with the software composition analysis in the scanning section above — the letters are simply reused, so say which one you mean when you write a ticket. Here it means the customer confirms the charge with their bank, usually through the 3D-Secure step ("approve this payment in your banking app"). A hosted checkout handles it automatically; your only job is to not disable or route around it because it "adds friction." The friction is legally required, and completing it shifts fraud liability toward the card's bank. (PSD2's successor, PSD3, is still moving through the EU legislative process as of mid-2026 — the SCA requirement itself isn't going anywhere.)
• Failed payments are a feature to build, not an edge case. Cards expire, limits get hit, banks decline for no visible reason. Without a retry schedule and a polite email sequence — the unglamorous machinery called dunning — every soft decline quietly becomes a cancelled subscription and lost revenue. Payment providers offer automatic retries and card-updater services; turn them on, and write the emails on purpose.
• Refunds and chargebacks need a policy before the first dispute. Write a refund policy and show it at checkout. When a customer disputes a charge with their bank instead — a chargeback — you get a deadline to respond with evidence: the booking confirmation, the cancellation policy they accepted, the message history. You pay a fee whether you win or lose, and a few fraudulent disputes are simply a cost of doing business — budget for them rather than treating each one as an emergency.
• Cancellation has to actually work — and in Germany, by law, without a login. Upgrades need defined proration; cancellation must be as easy as signing up — EU consumer law generally, and Germany very concretely: § 312k BGB requires a permanently visible cancellation button on the website, leading straight to a confirmation page where the contract can be ended — no account login required. Miss it and affected consumers may cancel at any time without notice, on top of the risk of a formal warning letter (Abmahnung) from a competitor or consumer association; courts have read the duty broadly, including for fixed-term subscriptions paid once.
• Reconcile payouts monthly. The provider pays out in batches — minus fees, refunds, and chargebacks — days after the underlying transactions. Once a month, check that payouts match your own invoices and bookings: a missing webhook or a double charge surfaces here first, and the same half-hour keeps your accounting reconstructible.
• VAT for German founders. The Kleinunternehmerregelung (§ 19 UStG) exempts you from charging VAT while turnover stayed under €25,000 in the previous year and stays under €100,000 in the current one (thresholds as of mid-2026, raised in 2025) — and the upper figure is a hard limit: cross it mid-year and you switch to regular VAT immediately, not next January. Outside the exemption, VAT goes on every invoice, with prescribed invoice details and periodic returns.
• Selling digital services across EU borders. Once your combined cross-border B2C sales into other EU countries pass €10,000 a year, VAT switches to each customer's country and rate. The One-Stop-Shop (OSS) exists so you register once at home and file a single quarterly return covering all of them, instead of registering in every country separately. Both VAT bullets share one punchline: know which threshold you're near, and the moment one triggers, talk to a Steuerberater — this is a when-to-ask map, not tax advice.

Two more product surfaces open up alongside payments — each looks like a feature request until it becomes a legal or economic problem:

Interface design as a legal question — the Digital Services Act

Section 7 called dark patterns legal exposure rather than merely bad practice. This is the law it meant. The Digital Services Act (DSA) is an EU regulation, in force across the EU since February 2024, and Article 25 says plainly that providers of online platforms must not design or organise their interface in a way that deceives or manipulates users, or otherwise distorts their ability to make free and informed choices. That is the fake countdown, the pre-ticked box, the cancel button hidden three menus deep — written into a regulation, enforceable by national regulators (in Germany the Bundesnetzagentur), with penalties reaching 6% of worldwide annual turnover at the top end. The DSA also carries duties most products meet as features rather than legal text: a working way for users to report illegal content, reasons given when you remove someone's post or suspend their account, and a route to contest that decision.

Two honest limits, because scope matters more than the headline number. First, Article 25 binds online platforms — services that store content from users and show it to the public, which covers a marketplace or a review feed but not a booking tool that only shows each customer their own appointments. Second, platforms that qualify as micro or small enterprises are exempt from that whole block of obligations, which is most products at this guide's scale. What does not go away either way is ordinary consumer-protection law: the Unfair Commercial Practices Directive and its national implementations cover the same manipulative designs for every trader, platform or not, and that is the rule the salon app is actually judged by. So the practical reading is: the DSA sets the direction and the ceiling, consumer law sets your floor, and the Section 7 checklist is how you stay clear of both. One thing not to conflate — the German DDG (Digitale-Dienste-Gesetz) is the national act that designates the DSA's German enforcement and separately carries the Impressum duty the protocol cites; it is Germany's law, not the EU regulation, and the two are cited for different things.

Everything in this section shares one property: it's a guardrail you can point to — a scanner in the pipeline, a hook, a signed contract. Section 10 turns to the risk you can't point at so easily: the shape of the system itself, and how you keep a grip on it as the code outgrows you.

Quick check: what does "secure enough for real customers" mean?

Two surfaces, both guarded. The agent: treat everything it reads as untrusted (prompt injection is the number-one LLM risk), grant least privilege — narrow permission rules, and subagents restricted to the tools they actually need — keep secrets out of its context, and never let one session hold all three legs of the lethal trifecta (private data + untrusted content + outbound communication). Cutting the outbound leg is the easy one: run in Claude Code's built-in sandbox with an allowedDomains allow-list. Vet skills and MCP servers like the supply chain they are, and back the rules with hooks the agent can't be talked out of. The code: /security-review as a first pass, then SAST, DAST, dependency and secret scanning in the pipeline on every change — plus a human look at every package an agent "remembered," because slopsquatters register the names agents imagine. Send the security headers (CSP, HSTS, nosniff, Referrer-Policy, frame-ancestors), and allow-list every server-side fetch so a user-supplied URL can't turn into SSRF against your cloud metadata endpoint. Data gets rehearsed backups, encryption at rest and in transit, need-to-know access with an audit trail — and the cheapest protection of all: collect less, delete on schedule, keep it out of logs. Auth is the door attackers actually use: passwords stored only as a slow salted hash (argon2id or bcrypt, never MD5 or SHA-256 — better still, let a hosted provider do it), MFA for staff, expiring sessions and recovery links, rate-limited logins, signed webhooks, and the by-hand IDOR test written as a playbook. And the legal layer is load-bearing: a privacy policy that matches reality, a DPA with every subprocessor, a plan that fits GDPR's 72-hour breach clock, a rehearsed export path for access and portability requests as well as a deletion one, special-category data flagged before it's collected, and interface honesty as a legal duty under the DSA and consumer law — with a lawyer, not an agent, holding the pen. And once money flows, a commercial layer joins it: card numbers kept off your servers so PCI DSS stays light, Strong Customer Authentication left on, dunning and a written refund policy built in, a cancellation flow that satisfies § 312k BGB, payouts reconciled monthly, VAT thresholds watched — plus marketing email sent only on provable double-opt-in consent, and abuse answered at the product level with deposits, quotas, and targeted friction.