Cookie consent, set up by your AI agent.

5 minutes: a working cookie banner on your localhost

Open your project in the agent and paste one prompt. Name Croombit in it, so the agent reaches for the right connector.

Using Croombit: create a site called "Acme" in English and Spanish, and add the domain acme.com. Add two cookie categories, Analytics (category ANALYTICS) and Advertising (category MARKETING), both off by default, with banner text in English and Spanish, and publish them. Publish the cookie banner. Create a TEST publishable key for localhost:3000, add the Croombit script tag to this project's root layout, and make sure our analytics and ad scripts only run after consent.

What the agent does

1. create_site and add_domain — the site with its languages, and acme.com. Usable in TEST at once; the response already carries the DNS record you will publish to go live.
2. create_cookie_category ×2, set_purpose_texts, publish_purpose — the two toggles visitors see, with the exact wording that will be cited in every consent record.
3. publish_banner — freezes the banner version every decision will point to.
4. create_api_key — a TEST pk_ key whose Origin allowlist is localhost:3000. The key is shown once; the agent writes it straight into your code.
5. It edits your layout: one <script src="https://croombit.com/cmp.js" data-tc-api-key="pk_test_…">, and marks existing tags with type="text/plain" data-tc-consent="…" so they wait for the visitor's choice. Google tags also get Consent Mode v2 defaults.

Then check what actually gets stored. On a public staging URL, ask for a scan (request_cookie_scan — our crawler accepts the banner and records every cookie). On localhost, an agent that can drive a browser opens the page, accepts the banner and sends what it sees with import_cookies. Both land in the inventory already classified.

10 minutes: every other consent

Cookies are only one kind of consent. The same conversation sets up the ones your product records itself — with proof.

Using Croombit: add consent statements for our newsletter (email marketing opt-in) and for accepting the terms of service, and publish them. Create a TEST secret key, put it in .env as CROOMBIT_SECRET_KEY, and record each user's choices from our signup handler with @croombit/sdk. Then create a webhook to https://staging.acme.com/webhooks/croombit for consent.withdrawn and write the receiver, verifying the signature.

• Consent statements with versioned text — the record keeps the exact version each person saw.
• Server-side recording with an sk_test_ key: every decision goes to the append-only vault and comes back with an Ed25519-signed receipt.
• Webhooks with signature verification, so your email provider stops writing to someone the moment they withdraw.
• Optionally, a preference center (channels and topics) and expiry policies — the same way, in the same conversation.

Going live: two steps in the console

The agent works in TEST. Moving real visitors over stays with a person, on purpose:

1. Verify your domain — publish the DNS TXT record (or the /.well-known file) the agent already gave you, and press Verify. LIVE keys only accept verified domains.
2. Create the LIVE `pk_` key and swap it for the TEST one. LIVE keys can only be created in the console, never through the MCP server.

What the agent can and can't touch

• Each connection is bound to one organization and to the permissions you tick on the consent screen. Anything else returns 403 on the server, not just in the UI.
• Publishing the banner needs its own permission (banner:publish) — leave it unticked and the agent can only prepare drafts.
• API keys: TEST only. No LIVE keys, no existing secrets, no identity secrets.
• The vault is read-only, and no permission exports a person's full data, or touches team members, billing or SSO.
• Every change it makes is in the organization's hash-chained audit log, like a teammate's.

Every permission, and what each one reaches, is in the MCP documentation.