# OPS-208 — The consent record should carry the browser user agent

> Every consent record must carry the device or browser user agent behind the submission.

- **Rule ID:** OPS-208
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `campaign.message_flow + privacy policy`
- **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the submitted form
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** CTIA, mytcrplus
- **Applies:** Applies when consent was collected by web form, checkout, account settings, third party, chat, social, email and QR code.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-208/

## Why this rule exists

When a consumer says they never filled in the form, the IP and timestamp establish that something was submitted and nothing more. The user agent is the one field on the record that speaks to how it was submitted — a real browser on a phone reads differently from a scripted post — and it is free to capture, since the header arrives with every request.

## How to fix it

Capture the User-Agent header alongside the IP address at submission and store it on the consent record. Done when a record shows the browser and device as well as the address it came from.

## Example of a compliant value

```text
Each web opt-in stores user_agent: "Mozilla/5.0 (iPhone; CPU iPhone OS 18_2 like Mac OS X) …" beside the IP.
```

## Notes

Registration-side twin: we judge whether the programme describes storing the field, never whether the stored record exists.