The Consent Layer Is a Control Layer: Auditing AI OAuth Grants in the SaaS Estate
Most UK enterprises now have a SaaS register. Fewer have a register of what those SaaS applications are connected to. The difference matters because business-led AI tools rarely arrive through procurement. They arrive as a consent prompt: a user approves an assistant, a plug-in or a summarisation service, and an OAuth grant is created. That grant is an integration. It has scopes, a token lifecycle, a data path and a failure mode. If it is absent from the integration estate, it is absent from resilience planning and audit evidence.
The register records applications, not authorisations
A SaaS register typically answers a procurement question: which products are in use, who owns the contract, what data is held and when is renewal due. It is less good at answering an identity question: which delegated authorisations exist inside those products, and what can they reach?
AI connectors exploit that gap. They often sit inside productivity suites, browsers, meeting tools and CRM platforms. Onboarding is a click. The consenting user may be a team leader, not a technologist. The connector may be a pilot that became habitual. When the pilot ends, the grant may not. When the user leaves, the token may remain until someone revokes it explicitly.
This is not a reason to ban business-led adoption. It is a reason to treat consent as a change event. In UK regulated estates, accountability for personal data and operational resilience does not stop at the procurement boundary. A connector that can read mailbox content, meeting transcripts or customer records is part of the estate, whether or not it appears in the SaaS register.
Inventory the grant, not only the application
The first control is an inventory that records the grant as a first-class object. Pull from identity provider consent records, SaaS administration APIs, browser extension inventories, secure web gateways and procurement records. Reconcile the results with the SaaS register and the supplier register. The aim is a connector register with enough fields to support review, not a one-off spreadsheet.
At minimum, record the application name, client identifier, publisher, tenant, consenting user, consent type, scopes, token lifetime, refresh status, last-used date, redirect URIs, data objects reachable, business owner and stated purpose. Distinguish delegated permissions granted by a user from application permissions granted by an administrator. The former are easier to create and harder to see; the latter are more powerful and should already be governed, but AI features can blur the line.
Scope names are not self-explanatory. Mail.Read, Files.ReadWrite.All and offline_access are meaningful to an engineer, but they do not tell a risk committee what data is exposed. Map each scope to a data classification and a business process. Where a vendor uses opaque scopes, ask for a data-flow description and treat absence of clarity as a finding.
Score connectors by data sensitivity and business criticality
A flat list of connectors will not prioritise action. Score each connector on two axes: what it can reach and what depends on it. Data sensitivity should reflect UK data protection categories, contractual classifications and regulatory data sets. Business criticality should reflect whether a process can continue without the connector, how many users depend on it and whether it supports customer-facing or regulatory obligations.
A practical score combines data class, scope breadth, user population, last-used recency, vendor assurance and whether the connector can write or delete data. Read-only access is not low risk: exfiltration is a read operation. Write access raises integrity and availability concerns. A connector with broad read scopes, no named owner and no recent use is a strong candidate for revocation. A connector with narrow scopes, a clear owner and a tested fallback can be allowed with review.
Use tiers rather than a single risk number: prohibit, restrict, review and allow. Prohibit where scopes exceed any plausible business need or the vendor cannot evidence appropriate controls. Restrict where a compensating control is possible, such as scope reduction or a managed gateway. Review where the business case is real but the evidence is thin. Allow where ownership, scope and lifecycle are documented. Recertify on the same cycle as access reviews, and sooner if the vendor changes terms or the model provider changes.
Fold connectors into integration health and resilience
Every connector is an integration, so it belongs in the integration health check. Record its authentication method, token expiry behaviour, error handling, monitoring and deprovisioning path. Test what happens when the token expires, the vendor revokes access or the AI provider has an outage. If a business process silently depends on a connector, that dependency should appear in the business impact analysis.
Resilience questions are straightforward. Can the process continue manually? Is there a fallback that does not require the connector? Does the connector cache or copy data into a third party? What is the exit route if the vendor is terminated? The answers belong in the same evidence pack as restore tests and supplier reviews, not in a separate AI innovation file.
Make consent a governed event
The operating model matters more than the first inventory. Configure identity providers to restrict user consent for high-risk scopes, route admin consent through review and notify integration owners when new grants appear. Add connector review to joiner-mover-leaver processes. Include revocation evidence in quarterly access reviews. Report a small set of metrics: unregistered connectors, mean time to revoke, percentage with a named owner and percentage of high-risk connectors with compensating controls.
In the UK context, this aligns with existing accountability and resilience expectations rather than creating a parallel AI governance programme. The consent layer is a control layer. If the SaaS register cannot see it, the integration estate is incomplete.
