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.
• 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. The pre-tool-use hook described below is one concrete way to sever a leg — 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.

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:

• Passwords 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.

The third 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.

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's the protocol's PCI gate. 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: 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:

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, 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). 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: 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. 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: 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, special-category data flagged before it's collected — with a lawyer, not an agent, holding the pen. And once money flows, a commercial layer joins it: SCA 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.