Ten reads whose responses carry row-level records or named accounts are reachable by an agent only after your org grants it. They are the scored records behind a model, the per-record factors, both score-history reads, the score and training-data exports, signal events, and the three timing reads. The browser path is unchanged: a person signed into the product reads their own records exactly as before.
Three properties hold. It is opt-in, so an owner or admin takes an explicit action and nothing is consented by plan tier or by any other setting. An org that has never been asked is refused, with no backfill and no default on. It is revocable, and the gate reads your answer on every request and caches nothing, so there is no window in which a revoked org is still served records. An agent can read the current state and cannot grant or revoke it, which is refused before its member’s role is consulted.
An agent that is refused gets a 403 with the code
record_read_consent_required, also carried as the x-ax1om-refusal-code
header, and a message that says what was refused, that it is a decision the org
has not made rather than a defect, and where the decision gets made. Every one
of those refusals is an audit event under a refusal category, which is what
separates “my agent cannot read my records” from “my agent was told no because
nobody granted it access”. The grant and the revoke are recorded too.
One read stays out of reach. The member-activity export returns your own users’ email addresses, IP addresses and who did what, rather than CRM records, so it sits outside a consent whose every word says record-level read access. It is not permitted to an agent. The human export is unaffected.