Andes Consent: cookie consent and evidence with banking-grade security

Andes Consent is the cookie consent system we built for organizations where security isn't up for negotiation. It comes in two pieces: a 16 KB script with zero dependencies that runs under strict Content Security Policies (CSP) and Trusted Types, and a receipt manager that stores every visitor decision as evidence no one can edit. It's in production today at a regional financial institution.

// The challenge

Asking for consent sounds simple until the platform runs to banking security standards and someone has to prove, years later, what each visitor agreed to. The key challenges were:

• The guard who opens the door Commercial consent platforms often require unsafe-inline or eval, exactly what a strict CSP forbids. The script meant to protect privacy ended up weakening the site's security.
• Real blocking, not cosmetic Analytics scripts and third-party iframes can't run before the visitor agrees, without breaking load order or script integrity.
• A cookie isn't evidence When a regulator asks what someone agreed to two years ago, and what text they were looking at, that browser cookie is long gone. And a log the team itself can edit proves nothing.
• A fragmented regulatory map A corporate site in the region answers to GDPR, CCPA, the Texas privacy act, and the laws of Brazil, Mexico, Chile, Colombia, and El Salvador. California's rules also require honoring the Global Privacy Control signal visibly and not asking again once someone has opted out.
• Accessible to everyone The banner is the first thing every visitor sees; it has to work with a keyboard and a screen reader.

// The technology solution

Andes Development built two pieces that work together or on their own.

The script is small, auditable, and designed from day one to live under a strict CSP:

• Vanilla TypeScript, zero dependencies A single file that works on any site, with size budgets enforced on every build: about 16 KB of JavaScript and 3 KB of CSS, gzipped.
• Safe under a strict CSP Tested with nonce + strict-dynamic and with Trusted Types. No eval, no Function, no HTML injection, with prototype-pollution hardening and a frozen public API.
• Declarative prior blocking Scripts are tagged in the HTML and only activate with consent, keeping their order, nonce, and integrity hash (SRI). Third-party iframes show as facades until the visitor accepts.
• Bounded trust An allowlist of origins for gated scripts. Remote configuration is validated on load and can never widen that trust.
• Signals for Google and for California Google Consent Mode v2 in basic or advanced mode, dataLayer events, opt-in and opt-out modes, and cookie cleanup when consent is withdrawn. When the browser sends Global Privacy Control, the preferences dialog shows the visitor that their signal was honored, and an opt-out survives policy changes without asking again for 12 months.
• Brand and accessibility A Shadow DOM banner with five layouts, per-brand themes in light and dark mode, English and Spanish, and WCAG 2.2 AA checked automatically on every theme.
• Verifiable delivery Every release ships as a package with SRI hashes, so clients host it on their own infrastructure.

The receipt manager takes in every decision and keeps it as evidence:

• Insert-only receipts The database refuses any edit or delete, no matter who sends it, a platform administrator included. Only the retention cleanup can remove expired receipts, and every cleanup run is logged.
• Every receipt tied to the text the visitor saw Each policy revision is archived with its configuration and its English and Spanish text. Once the first receipt arrives, that revision locks; later corrections can only be added as notes.
• The IP is never stored It's kept only as a hash with a key unique to each client, and that key can be rotated.
• Bounded intake A receipt is accepted only with a valid site token, an origin on that site's allowlist, and a valid format, with limits per visitor, per site, and per IP, and an 8 KB cap per request.
• Lookups for compliance teams Compliance staff pull up a visitor's history by consent ID, and every lookup is audited. CSV and Excel exports are protected against formula injection, and only the person who requested one can download it, through a signed link.
• Controlled access Separate panels for the client and for the Andes team, roles per client (compliance, viewer, and developer), mandatory two-factor authentication and passkeys, and passwords set only from an emailed link. Retention is set per client, with five years as the default.

The receipt manager is optional: the script can also send receipts to the organization's own server. And it doesn't implement the IAB TCF framework, by design: it's built for corporate sites and regulated platforms, not programmatic ad networks, and that choice is part of what keeps it at 16 KB.

// Results and key wins

A consent system your site's security doesn't have to tolerate, because it can audit it:

• 16 KB

  The full script gzipped, with no dependencies and a size budget validated on every build.

• 361 tests

  195 unit tests and 166 end-to-end tests across Chromium, Firefox, and WebKit, plus a security audit with every finding fixed.

• 3 layers

  The application model, a database trigger, and foreign keys keep a receipt from being edited or deleted before its retention period ends.

// The bottom line

Andes Consent solves two problems we keep seeing on corporate platforms: asking permission without weakening the site's security, and proving later what permission was given. It's small, auditable, and built with the same rigor we bring to banking. Today it runs on a regional financial institution's site, where every visitor decision becomes a receipt the compliance team can put on the table.