SVG, Rust and Elm: the security gaps illustration

For architects, CISOs and developers who need one picture of where PII, card data and PHI are actually exposed.

Base64 changes how data is written, not who can read it. Compiling changes what code can do. TLS protects the wire, not the endpoints. Sandboxes limit reach, not readership. Only encryption, server-side authorization and contracts decide who can read the data.

From cron to agents: who binds the systems, and where security has to live

Before APIs, data mostly stayed inside one cloud or one data center. When it had to move, a developer wrote an EDI or ETL mapping, someone reviewed it, and a cron job ran it — nightly, or every 15 minutes. The binding between systems happened at build time, and security lived at the perimeter, on the SFTP server and in the reviewed mapping.

APIs and iPaaS (integration platform as a service: hosted tools such as MuleSoft, Celigo or Boomi that connect one system's API to another's) moved the binding to event time: every order or update travels on its own, in seconds, through integration code. Security moved into API keys, scopes and signed webhooks.

AI agents move it to runtime. A model decides, per request, which systems to connect and what data to move — and the same model can be steered by anything it reads. So AI now does much of the binding between systems. It must not do the security. If the thing that chooses the connection also decides what is allowed, the security is only as strong as the model's resistance to a well-phrased instruction.

Open the SVG full size (1600 × 1090) · Download the PDF · JPG.

Security can no longer ride along with the binding. It has to attach to four things the model can't rewrite:

1. The data. Consent state is a field on every record, and a record without it is refused, whoever asks (M3, gap 20).
2. The identity. The user and the agent are each identified, and every token is scoped to one tool's audience (A3).
3. The authority. A signed mandate carries the amount, merchant, expiry and a one-time nonce, and it is checked on every call (A4).
4. The gate. Deterministic code at the endpoint says yes or no, and writes every grant and denial to an append-only ledger (A7).

The model proposes. Deterministic systems decide. Every grant and denial is recorded. The rest of this article maps where that breaks today, from a single SVG file to SAP.

The security gaps illustration

Open the SVG full size (1600 × 4290) · Download the PDF (233 KB, one vector page) · JPG. The diagram is shown here as an image, never inlined, so its SVG cannot run code on this page — gap 3, applied to itself.

How to read it

The diagram reads top to bottom in seven bands:

1. One SVG, three ways in. The source holds a hidden <script> and patient details in <metadata>. Base64 turns it into a data: URI without changing any of it. Display decides whether the script runs: never through <img>, always when inlined or loaded in <object> or <iframe>.
2. Four words that get confused. Base64 is an encoding. A compile translates source into a different program. Machine code is what the CPU runs, and it disassembles. Bare metal is code with no operating system underneath, so a memory bug there owns the device.
3. The request path. Six boxes from the Elm client to a Rust service, each split into what it checks and what it doesn't.
4. TLS protects each hop, not the data. Lane A: a Next.js server render followed by client-side hydration. Lane B: a CRM-to-Shopify data bus.
5. Same data, three stacks. Lane C is JVM middleware (Salesforce, MuleSoft, Salesforce Commerce Cloud). Lane D is an iPaaS chain (SAP, Azure, Celigo, Magento). Lane E is Wasm (Shopify Functions, Cloudflare Workers). A table compares them on isolation, network access, memory safety, supply chain, patching, Consent Mode v2 and idempotency.
6. Isolation and transport. Where the wall sits in a virtual machine, a Docker container and a Kubernetes cluster, and how data crosses it.
7. The gaps. All 31, each with its fix.

SVG: a picture, or a program

An SVG is XML. Besides shapes it can carry <script>, onload= handlers, <foreignObject> with embedded HTML, outside references, and text and metadata that hold names and IDs. Base64 keeps every one of those, about a third larger, and hides <script from any filter that only reads text.

<img src> renders in the browser's image sandbox: no script, no outside references, no DOM. Inlining promotes the file to a node in your document, where script runs. Safe SVG for Webflow and UIkit shows how to keep stylable, animatable SVG without spending that sandbox: an allow-list sanitizer, then inline. For anything an uploader supplied, display it with <img>, send Content-Security-Policy: sandbox on .svg responses, and serve uploads from a separate asset domain.

Treat an exported chart as the data it shows. An SVG of patient results is PHI, wherever it is cached or shared — the same point What Survives the Transform makes about XMP inside media files.

Read by a model: what the eye sees and what the model reads

An SVG is text, which is why a crawler or a language model can read one without a vision model guessing at pixels. The <title> and <desc> inside each diagram on this site tell the whole story in words for that reason. The same property is the risk: what a model reads and what a person sees can be two different messages. Text a reviewer never sees still reaches the model:

Each one is a ready-made prompt injection: an instruction the person approving the file can't see and the agent reading it can. The fix is to give the model only what the eye gets:

1. Normalize before reading. Parse with usvg, the Rust parser behind resvg. It resolves CSS, expands <use>, and drops scripts and unknown elements into one simple tree. Check that tree, not the raw markup.
2. Extract only visible text. Keep text that sits inside the canvas, isn't clipped or masked away, has real opacity and size, and contrasts with what is behind it.
3. Compare the words with the picture. When <title> or <desc> says something the visible text doesn't, flag the file instead of passing it on.
4. Hand it over as data. The extracted text goes to the model inside a marked, untrusted document block, never next to its instructions — typed, gated and ranked before it is tokenized, as Hyperscaler vs Distributed puts it. OWASP lists this indirect route under LLM01, prompt injection.

The goal is one message: the file tells a person and a model the same thing.

Rust: ownership as access control

Rust appears three times in the diagram. Each idea maps to a chapter of The Rust Book:

• The Rust service at the end of the request path. A ConsentGrant is moved into the function that sends data out, so one consent cannot cover two exports (ownership). A reporting function that takes &PatientRecord cannot change it; only &mut can, and only one at a time (references and borrowing). A Pii<T> wrapper whose Debug prints [REDACTED] and which does not implement Serialize cannot reach a log line or a JSON response. And with no unsafe, whole classes of memory bugs are ruled out.
• Bare metal. #![no_std] firmware, where memory safety is the only wall. Firmware Asset Publishing covers the publishing side.
• The Shopify Function in lane E: Rust compiled to Wasm, with no network access. Gap 22 covers the host imports that remain.

pub fn send_to_ads(data: Pii<Email>, grant: ConsentGrant) -> Result<(), Error> { /* … */ }

let grant = consent::verify(&req)?;   // the only way to get one
send_to_ads(email, grant)?;
send_to_ads(other_email, grant)?;     // compile error: use of moved value `grant`

The limit is printed on the Rust box: types force a check to happen; they cannot prove the check is the right one.

Where memory gets managed: compile time, not runtime

Memory safety, simply: a program is memory-safe when it can only read and write the memory it is allowed to, and only while that memory is still valid. It can't write past the end of a buffer, use memory after freeing it, free it twice, or read memory nobody initialized. In a memory-unsafe program, one malformed input can do exactly those things — and that is how a bad file becomes an attacker running their own code inside your process. The Chromium project finds that around 70% of its serious security bugs are memory-safety problems, which is why CISA asks software makers to publish roadmaps to memory-safe languages.

A common mental model is that Rust compiles to bytecode and a runtime manages its memory, the way the JVM does. Neither is true, and that is the point of Rust. The JVM manages memory at runtime; Rust proves it at compile time.

Open the SVG full size (1600 × 820) · Download the PDF · JPG. The black tag marks where memory is managed in each pipeline.

Rust to Wasm is the one case with bytecode, and even there nothing manages memory at runtime: the host only puts a wall around the module's memory.

Three consequences for security:

• No runtime to patch, but you rebuild. A JVM security fix can ship as a runtime update. A Rust fix means recompiling and redeploying the binary.
• Secrets can be wiped. Rust frees memory at a known point, so zeroize can overwrite a key when it goes out of scope. JVM Strings can't be changed and the garbage collector may copy them, so a secret can't be reliably erased (gap 19).
• Nothing to escape, except unsafe. The compile-time proof holds everywhere except inside unsafe blocks — the first thing to search for in a Rust review.

Why memory safety matters for AI and the machine layer. Prompt injection attacks the model's reasoning. Memory bugs attack the machine underneath it, and AI makes them easier to reach:

• Agents parse untrusted input at machine speed. Every image, PDF, SVG, 3D file, web page and tool output an agent touches goes through a parser, and parsers are where memory bugs live. A crafted file is a bug report delivered at scale, with no person watching (M2).
• Injection can become code execution. A prompt injection that gets an agent to fetch an attacker's file (A5) hands that file to a native decoder. If the decoder is memory-unsafe, the attacker moves from steering the model to running code in the service that holds its tokens and keys.
• Model files are inputs too. Python's pickle format runs code when a model is loaded; safetensors was built to store weights safely instead. Native model loaders, tokenizers and image decoders are C and C++ under the hood, sitting next to the credentials.
• The gate has to be the strongest code in the system. In the cron-to-agents picture, deterministic code decides yes or no for every agent action. If that gate can be overwritten through a memory bug, the identity, mandate and ledger checks are only suggestions. Write it in a memory-safe language — Rust, or TypeScript in a Worker isolate — and keep unsafe out of it.
• AI writes more code than people review. Generated C and C++ repeat the classic memory bugs at volume. In a memory-safe language, the compiler is the reviewer that never gets tired.

Is a garbage collector like Redis or a cache? Only in that both decide when something is removed. A garbage collector reclaims memory inside one process, and only what nothing refers to any more, so it never removes something in use. A cache such as Redis or Workers KV is a separate store of copies, shared across processes, that removes entries by policy (expiry, least recently used) even if someone will ask for them again. Neither one erases securely: memory freed by a garbage collector keeps its bytes until it is reused, and an expired cache entry may survive in snapshots and replicas. A cache is also one more copy of the data — sessions and PII in a cache need the same access controls as the database (gaps 6 and 11).

Parsing an untrusted SVG: what the compiler catches, and what it doesn't

An uploaded SVG is a stranger's instructions, and every number in it can be a trap: a width of four billion, a path that claims more points than it holds, a reference to an element that doesn't exist, groups nested a hundred thousand deep. A C renderer depends on the programmer to check each one; miss one and memory gets written past its end. librsvg, the SVG library used by GNOME, ImageMagick, libvips and Wikipedia's thumbnails, began in C and was rewritten in Rust for this reason; resvg was written in Rust from the start. The Rust compiler turns each check into a rule:

Most of this is decided before the program runs: code that could break memory does not compile, so that class of bug never ships.

What the compiler does not catch:

• Exhaustion. A billion copies of one element through nested <use>, a 100,000-pixel canvas, a filter chain that never finishes. All memory-safe; all able to stop a server. Set explicit limits on depth, element count, canvas size and reference loops, with a timeout around the render, whatever the language.
• SVG working as designed. <script>, onload= and <foreignObject> are dangerous because they run, not because memory breaks. They are stripped by a sanitizer (gap 3), not by a compiler.
• Code under the parser. unsafe blocks, and the C font, image and compression libraries a renderer may link to.

Elm: no hidden side effects

Elm is the first box of the request path. Functions are pure, so a view that renders patient data cannot send it anywhere. Opaque types decide in one module what any screen may show. Ports are the only exit to JavaScript, which gives you one list to audit, and Elm packages cannot contain JavaScript.

The box's "does not" side is gap 8. The browser is untrusted: anyone can edit the compiled JavaScript or call the API directly. Elm protects your users from your own bugs, not your server from attackers — the same split the Dark Factory article draws between the Elm Architecture and Webflow + Xano. Every rule has to be enforced again in the Worker or Xano.

Wasm, containers and VMs limit reach, not readership

A Wasm module gets its own linear memory and can only call what its host gives it. A Worker runs in its own V8 isolate. A container shares the host kernel; a VM brings its own. Each is a wall around what code can reach. None decides who can read the data inside it. Where Your Code Runs Is a Business Decision prices the same options by cost and risk.

Two container facts tie straight back to band 1. Kubernetes Secrets are base64 in etcd until you turn on encryption at rest — gap 24 is gap 1 again. And pod-to-pod traffic is plaintext by default until a NetworkPolicy and mTLS or WireGuard say otherwise.

Gap index and fixes

Where each numbered circle appears, and the control that closes it.

Browser, machine and agent: three callers, one endpoint

The same Worker or Xano endpoint is called by three kinds of caller, and each one fails differently. A browser is a person whose code you can't trust. A machine is code with no person behind it. An agent is code choosing what to do for a person who isn't watching.

Open the SVG full size (1600 × 2022) · Download the PDF · JPG. Gaps here are lettered: B for browser, M for machine, A for agent.

The endpoint's first question is which kind of caller is this? One rule for all three fails all three:

Assumptions that break as you grow

A JVM that never leaves its VM can get away with assumptions that stop holding one stage at a time. Each stage keeps every problem from the stages before it.

The last column is the one teams plan least for. Making a system legible to AI — structured data, llms.txt, clean JSON-LD, Markdown descriptors — is how answer engines and agents find and recommend it. The same legibility makes it readable, quotable and steerable by every model that fetches it, so anything an agent can read is something an attacker can phrase as an instruction (A1).

Four runtimes, four resolution planes, one join

The platforms a commerce stack connects don't just run different languages. Each one decides who a customer is, what a product is, and what that customer agreed to on its own terms — a separate resolution plane.

Rust, Wasm and Javy are Shopify's extension layer — the code you write — not its core. Python is the client side of Google Merchant, not Google's runtime. And "Adobe is Java" holds for AEM but not for Adobe Commerce.

Open the SVG full size (1600 × 1200) · Download the PDF · JPG. Security gaps at the join are marked in red.

Only data crosses between planes, never runtimes. A JVM, a Ruby process, a Wasm module and Google's services never share memory; they exchange JSON over HTTPS. So memory safety protects within each plane and stops at its edge. Between planes, the security boundary is the data contract — a schema checked on every payload — and the join that enforces it.

The join is your code: middleware, an iPaaS flow or an agent. It is the only place the four planes meet, so it is where the gate from From cron to agents and the consent field belong — and where the gaps concentrate:

No plane learns about another plane's opt-out or erasure on its own. If a customer withdraws consent in Shopify, Salesforce, Adobe and Google still hold their own copy of "yes" until your join tells them otherwise — and keeps the receipt that it did.

Binding: owned events vs latent iPaaS, and the clean room for AI

A clean room, for AI-first automation, is a controlled place where data from more than one party is joined and analyzed while no party, model or agent sees another party's individual records. Agents learn from the combined data without ever receiving a row. Four rules make it one:

1. Only consented records enter — a separate consent scope, checked on the way in.
2. Only reviewed templates run — no free-form queries, from people or from agents.
3. Only aggregates above a privacy threshold leave — never rows or identifiers.
4. Every query is logged — who or what asked, which template, what came out.

Open the SVG full size (1600 × 1420) · Download the PDF · JPG. Security gaps are marked in red.

Recommended binding: owned events

1. The source emits a signed event — a Shopify webhook, or delivery through EventBridge or Pub/Sub.
2. The edge checks it — the HMAC on the raw body, an idempotency key from the event ID, and the consent state before anything leaves (the egress gate).
3. A durable queue carries IDs, minimal fields and the consent state — not whole payloads.
4. An idempotent processor upserts by stable keys — offerId, Shopify global IDs, Salesforce record IDs — through each plane's API.
5. A ledger records every mapping and every yes and no.

The rule underneath is reference, don't replicate: bind systems by ID and resolve details when they are needed. When you must copy, copy the minimum, and carry the consent state with it.

How Shopify and Google data meet

There is no joint Shopify–Google clean room product. Data meets in one of three ways, and only two of them are clean rooms:

What an agent may learn

An agent asks a question, the question runs only as a reviewed template, the clean room joins consented records under salted hashes, threshold and difference checks drop anything too small or too overlapping, and the agent gets counts and rates back — never a row or an identifier.

C2 is the AI-era risk. A person rarely runs hundreds of nearly identical queries; an agent can, and subtracting their results isolates one person. Ads Data Hub's difference checks exist for exactly this, and a homegrown clean room needs the same protection.

Localized AI: crawler files, locale-aware retrieval and LoRA adapters chosen by consent

robots.txt and llms.txt can't carry consent. They are public, site-wide files that tell crawlers which pages to fetch or read first. They hold nothing about any person, and Google's ad and audience systems never look in them for consent. A localized AI stack needs two channels kept apart: one decides which content AI may read, the other decides which people your systems may use.

Open the SVG full size (1600 × 1490) · Download the PDF · JPG. Security gaps are marked in red.

The content channel, bot by bot

• Googlebot feeds Search, AI Overviews and AI Mode. There is no separate AI Overviews opt-out; nosnippet, max-snippet or blocking Googlebot are the only levers.
• Google-Extended decides whether Gemini models may train on or ground answers in your content. It doesn't affect Search ranking or AI Overviews.
• Storebot-Google is the shopping crawler. It checks product pages against Merchant Center data (price, availability, automatic item updates). Blocking it can get products disapproved.
• llms.txt is a community proposal: a Markdown map of the pages you want language models to read. Google has said it doesn't use it; some AI tools and agents do. It has no enforcement and no consent meaning.

The Merchant API carries products, never people, so it needs no consent state. Shopper data reaches Google only through tags that carry ad_storage, analytics_storage, ad_user_data and ad_personalization, and through Customer Match and enhanced-conversion uploads with their own ad_user_data and ad_personalization consent fields. A shopper's consent state has to be attached to every event at the edge before anything leaves (gap 20).

Loading localized content for retrieval (LangChain)

LangChain doesn't know about locales. Localization works when every document carries its locale in metadata, and retrieval filters by locale first, then falls back to another language.

new Document({
  pageContent: item.text,
  metadata: {
    locale: "ko", market: "KR",
    canonical_id: item.baseId,          // same ID for every translation of this item
    source: "webflow",
    translation: "human",               // or "machine"
    url: item.localizedUrl,             // cite the localized page
  },
});

Embed every locale in one index with a multilingual model (Workers AI @cf/baai/bge-m3), and create Vectorize metadata indexes on locale and market so they can be filtered. Retrieve in the user's locale and market first. When too few chunks match, add English chunks whose canonical_id has no native translation, and have the model answer in the user's language, citing the localized URL. Detect the locale from the user's explicit choice, then the Shopify market, then Accept-Language. Never from the IP alone.

LoRA adapters, chosen by locale and consent

A LoRA adapter is a small set of weights loaded on top of a base model at answer time. Choose it by locale, market and the user's consent state, and allow it to be trained only on data whose consent covers training. There are two consent questions: may these records train the adapter, and may this user's request use it right now.

The language adapter is the default. A personalization adapter is a privilege that consent turns on. Each adapter has a registry entry that records its consent basis:

{
  "id": "persona-us-loyal-v3",
  "base_model": "@cf/mistral/mistral-7b-instruct-v0.2-lora",
  "locale": "en", "market": "US", "purpose": "personalization",
  "consent_required": ["preferences", "marketing"],
  "dataset_hash": "sha256:…", "record_count": 18421, "min_cohort": 50,
  "trained_at": "2026-10-01", "retire_by": "2026-10-31"
}

function pickAdapter(reg, locale, market, consent, now = Date.now()) {
  const live = reg.filter(a => Date.parse(a.retire_by) > now);
  const persona = live.find(a =>
    a.purpose === "personalization" && a.locale === locale && a.market === market &&
    a.consent_required.every(k => consent[k]) && !BLOCKED_MARKETS.has(market));
  return persona ?? live.find(a => a.purpose === "language" && a.locale === locale) ?? null;
}

Consent comes from the Shopify Customer Privacy API (preferencesProcessingAllowed(), marketingAllowed(), analyticsProcessingAllowed(), saleOfDataAllowed()), stored on the session at the edge. The Worker calls env.AI.run(model, { messages, lora: adapter.id }) and writes the adapter, locale, market and consent state to the ledger. Workers AI accepts LoRA only on its -lora base models; wrap the call in a RunnableLambda if the LangChain chat wrapper doesn't pass lora through.

Rules by locale

Training runs inside the clean room: only records consented for training, pseudonymized, with cohorts below min_cohort dropped. You can't remove one person from trained weights, so retire_by forces a retrain without the people who withdrew, and the privacy notice says so. Adapters never go to Google: Google Ads audience targeting still runs only through consent states and Customer Match consent fields.

L3 is the confusion at the heart of this section. Allowing a crawler is a decision about content. It never grants consent to use a person's data, and an agent acting for a user may not read either file at all.

Audience targets in a CMS: definitions, not members

An AI-enabled audience collection in Webflow stores definitions, never members. It holds no emails, hashes or customer IDs. Membership is resolved at sync time in Shopify, Klaviyo or BigQuery, checked against each person's state, and sent to Google with consent fields attached. An agent may propose an audience as a draft item; a person approves it by publishing.

Open the SVG full size (1600 × 1430) · Download the PDF · JPG. Security gaps are marked in red.

Each audience carries targeting conditions (consent, DSR, device, location and campaign rules) that a person must meet. Each person's own state stays in Xano and the ledger. Webflow gets back only aggregate state snapshots.

Audience Targets

Supporting collections

agent_api is its own device class: an AI agent shopping for a user gets no persona adapter unless the user's mandate covers it.

Audience States: aggregate snapshots, written by the sync

One item per audience, campaign, market and device class for each sync: the State (Synced · Held below cohort · Blocked by consent · Blocked by DSR · Blocked by market · Error), Matched by definition, Excluded: open DSR, Excluded: consent not granted, Excluded: blocked market or location, Excluded: device not allowed, Sent to destination, Consent coverage (percent), Snapshot at and Ledger entry. Every count below the audience's Min cohort is left empty: small counts sliced by device, market and campaign can identify a person (C2).

Per-person state, outside the CMS

{
  "subject": "hmac:7e1a…",
  "consent": { "ad_user_data": true, "ad_personalization": true, "marketing": true, "preferences": true, "training": false, "source": "shopify_customer_privacy", "at": "2026-10-12T09:14:00Z" },
  "dsr": { "open": null, "last": { "type": "access", "closed_at": "2026-08-02" } },
  "device_class": "mobile_web",
  "location": { "country": "US", "region": "CA", "source": "shopify_market" },
  "campaigns": ["spring-sale"]
}

For each person the definition matches, the sync checks in this order and stops at the first failure:

1. DSR: an open request, or one of the excluded types, excludes the person. Deletion and opt-out win over everything else.
2. Consent: every purpose in Consent required, and the destination's required consent fields, must be granted.
3. Location: the person's market must be listed and not blocked; that market's regime rules apply.
4. Device: the device class must be listed, and allow personalization if a LoRA adapter is attached.
5. Campaign: the campaign must be Live, in its dates, with its consent requirements met.
6. Cohort: below Min cohort, the state is Held below cohort and nothing is sent.

Customer Match uploads carry ad_user_data and ad_personalization. The ledger keeps each person's decision; Webflow gets only totals. The agent creates items through the Data API (POST /v2/collections/{id}/items) with isDraft: true and can't publish. The sync reads only published Live items and refuses any item whose definition hash doesn't match the approved one.

VM, container or managed database — and the storage wrappers

Where the database runs decides who patches it, where its data sits, and which wall you are relying on. In every case the app points to the database: connections start at the app, and the database never connects back to it.

Hardware (cloud host)
└─ Hypervisor                       ← the wall between VMs
   └─ VM: guest OS (its own kernel)
      └─ Database process
         └─ Data files ─── on an attached virtual disk (EBS, Persistent Disk, Managed Disks)

A managed service moves the operating system and the patching to the provider. It does not move the access model. Keys, IAM bindings, bucket policies and public toggles stay yours — that is the shared responsibility line, and almost every public data leak sits on your side of it.

Container, Docker, Kubernetes, and a container in the cloud

Four words, four different layers. They are easy to blur because they usually appear together.

The same image runs under all of them. Build it once with Docker, and it can run on a laptop, in a Kubernetes cluster or on a cloud service unchanged.

"A container in the cloud" comes in three amounts of control:

A Cloudflare Worker is not a container. It is a V8 isolate: lighter, starting in milliseconds, with no filesystem and no kernel of its own. That is why the Worker sits in front and a container is reached only through it, when you need a full Linux process.

Security follows the layer, not the brand. The image carries its own risks wherever it runs (secrets baked into layers, gap 26). Kubernetes adds cluster risks (Secrets as base64, gap 24; plaintext pod traffic, gap 25). A serverless container service removes the cluster risks but keeps the image risks and your access settings.

Kubernetes Secrets and SVG bundles: the same wrapper

A Kubernetes Secret and an SVG that embeds images as data: URIs use base64 for the same reason: to carry bytes inside a text format (YAML for one, XML for the other). In both, anyone who gets the text can decode it in one line, and a scanner that only reads text sees nothing but the encoded string.

Open the SVG full size (1600 × 960) · Download the PDF · JPG.

They differ in one way that matters: only the Kubernetes Secret can be locked. The cluster puts RBAC in front of it and can encrypt it in etcd with a KMS provider. An SVG has no lock to turn on — once the file is shipped, its bytes are its contents. And only the SVG can execute: an inlined outer SVG runs its script, while a nested SVG loaded through <img> or <image> is drawn as a picture.

The shared lesson:

• Decode before you scan (gap 2). Secret scanners must decode data: values; SVG sanitizers must open nested data URIs before judging them.
• Keep secrets out of both (gap 1). A Secret YAML committed to Git and an SVG with an embedded payload leak the same way: to everyone who gets the file.
• Only one has a lock (gaps 24 and 7). Turn on RBAC and etcd encryption for Secrets. For SVG, carry nothing private at all — no patient labels, no IDs in <metadata>.

The wrappers, by provider

"Encrypted at rest by default" means the provider's disks are encrypted. It does not mean your data is hidden from anyone who holds a valid key, token or IAM role — and those are what leak. For PII, card data and PHI, keep the access model narrow, prefer identity-based access over long-lived keys, and encrypt sensitive fields yourself where the provider would otherwise see them.

Known foot guns

A foot gun is a feature, API or default that makes it unusually easy to shoot yourself in the foot: a perfectly natural-looking use causes the bug, outage or leak. The blame lands on the design, because the design invites the mistake. The remedy is the same every time: make the safe path the default, and make the dangerous path explicit and loud — the way Rust spells it unsafe and React spells it dangerouslySetInnerHTML.

Related

• Safe SVG for Webflow and UIkit — inline SVG without inheriting the upload's privileges
• GUIs when you still ship JavaScript — Webflow, Elm, Javy, Tauri and Rust down to machine code
• Entitlement Security — one architecture, two trust models
• Where Your Code Runs Is a Business Decision — VMs, containers and isolates
• Hyperscaler vs Distributed — C and C++ renderers, their Rust replacements, and why a safe renderer can move to the device
• What Survives the Transform — metadata, re-encodes and where media should live
• Also published on the game11ty reference site: SVG/Rust/Elm: The Security Gaps Illustration and Machine Code/Rust/WASM, SVG/Native, Server/Client