Executive Summary

Shadow AI and SaaS sprawl should be governed as one external-service control problem. The architecture needs to discover services and AI capabilities, tie each material service to accountable owners, evaluate data and delegated access, define an explicit policy outcome, apply enforceable controls, observe change, and remove trust cleanly when the service is no longer required.

This whitepaper defines an architecture for that operating model. It does not assume that every unknown application is dangerous or that every AI use requires blocking. The objective is proportional control: make low-risk, useful adoption easier to approve while requiring stronger evidence and restrictions when a service can reach sensitive data, privileged identities, enterprise systems, or external audiences.

CyberTech Intelligence Perspective

The right unit of governance is the service relationship and its authority. Leaders should be able to see what a service can access, which identities or integrations trust it, who owns the use, what policy applies, and how the relationship can be changed or terminated. Discovery without these answers creates awareness but not control.

Evidence Base for the Architecture

The architecture combines established and current guidance. NIST SP 800-207 provides the foundational zero-trust concept of protecting resources without assuming trust based on network location. [1] CISA's SCuBA Technical Reference Architecture shows how cloud business applications can combine identity, endpoint posture, configuration, visibility, and cloud-access controls in a federal architecture. [2] The Cloud Security Alliance's SSCF implementation guidance provides a structured set of SaaS security capabilities for operational use. [3]

Current AI and identity guidance adds newer control pressures. CSA research on OAuth ghost tokens highlights the lifecycle risk of delegated AI/SaaS authorisations that outlive their original purpose. [4] Microsoft documentation shows how enterprise products can discover AI applications and sanction or unsanction them, illustrating how visibility can connect to policy enforcement. [5] [7] NCSC guidance on agentic AI emphasizes safeguards, oversight, observability, and stronger controls as machine authority grows. [6]

Why Discovery Must Lead to Ownership

A control architecture fails if discovery produces findings that no one is authorized to resolve. Every service should have a business owner, a technical owner, and a current decision. The decision should describe the permitted purpose, users, data conditions, identity and integration scope, and next review date. Services without owners should be escalated because no control can remain durable when responsibility is ambiguous.

Eight Operating Layers and Seven Control Questions

The eight layers below form the CyberTech Intelligence control architecture. Seven questions should be answerable at every layer: What is the service or AI capability? Why is it needed? Who owns it? Which data can it handle? Which identities and integrations can it reach? Which policy and technical controls apply? How is trust removed if the decision changes?

1. Discover

Collect identity, browser/network, endpoint, procurement, expense, OAuth/API, and business-intake signals into one review queue.

2. Classify

Record purpose, users, data sensitivity, integration scope, action authority, and duration.

3. Own

Assign business and technical owners, escalation route, and review date.

4. Approve

Set sanctioned, restricted, prohibited, pilot, or exception status with explicit conditions.

5. Constrain

Apply SSO, least privilege, delegated-scope limits, data controls, configuration baselines, browser or access restrictions.

6. Observe

Monitor new services, permission changes, configuration drift, high-risk data events, exceptions, and owner changes.

7. Retire

Revoke accounts, OAuth grants, API keys, service identities, connectors, stored-data obligations, and renewals.

8. Measure

Track coverage, decision time, exception aging, integration review, retirement completion, and control effectiveness.

Operational Failure Scenarios

Table 1. Failure Scenarios and Corrective Decisions

Scenario

Control Failure

Corrective Decision

Employee uses an unapproved AI service with restricted business data.

Service was visible too late or data policy was not enforceable at use time.

Restrict data path; assess service; provide approved alternative; document decision.

SaaS owner leaves and no successor is assigned.

Ownership lifecycle is not connected to workforce change.

Assign new owner or retire service; review privileged access and renewals.

Dormant OAuth grant remains active after the service is no longer used.

Delegated trust has no expiry or review owner.

Revoke token; review similar grants; add lifecycle trigger.

Business team buys a duplicate SaaS product.

Procurement or expense signal is not reconciled with the service inventory.

Confirm need; consolidate or approve exception with owner and renewal date.

Admin configuration drifts from the approved baseline.

Configuration evidence is point-in-time only.

Correct setting; investigate cause; add monitoring and change review.

User is blocked but has no exception or alternative path.

Policy enforcement is disconnected from business workflow.

Provide review route, approved option, and time-bound exception criteria.

Sample Qualification Flow

Table 2. Qualification Flow for a Service Decision

Stage

Question

Outcome

1. Purpose

Is the business outcome clear and current?

Proceed only with named business owner and stated need.

2. Data

Which data must enter, leave, or remain in the service?

Approve allowed classes; restrict or prohibit unsupported use.

3. Identity

Can access use managed identity and least privilege?

Define users, admins and non-human identities.

4. Integration

What can OAuth, API, agent, plugin or connector access or change?

Limit scopes; record owner and revocation path.

5. Supplier / configuration

Which supplier and customer controls are required?

Complete due diligence and configuration baseline.

6. Enforcement

Can the decision be translated into allow, warn, restrict or block?

Implement technical and procedural controls.

7. Lifecycle

Can material change and retirement be detected and completed?

Set monitoring, review date and closure checklist.

Governance and Decision Rights

Figure 1. CyberTech Intelligence Decision-Rights Matrix

Decision Stage

Accountable Owner

Required Evidence

Exit Criteria

Service intake

Business requester and service governance

Purpose, user group, observed or requested service.

Record created and owner assigned.

Security/data review

Security, identity and data owners

Data classes, access, integration, configuration and supplier evidence.

Use conditions approved.

Policy decision

Business owner with risk owner as needed

Business need, control conditions, exception or alternative.

Sanctioned, restricted, prohibited or pilot status recorded.

Technical enforcement

Platform / identity / endpoint / cloud owner

Configured identity, data, application and browser/network controls.

Decision is technically enforceable.

Ongoing operation

Business and technical owners

Usage, changes, exceptions, configuration, integration and access reviews.

Thresholds met or corrective action active.

Retirement

Business owner and technical closure owner

Dependency, account, token, data, contract and renewal closure.

Trust and obligations closed.

CyberTech Intelligence Shadow AI & SaaS Governance Framework

Figure 2. Eight-Layer Control Architecture

Layer

Name

SaaS governance

01

Discover

Surface active external services and AI capabilities.

02

Classify

Record purpose, users, data, integration and action scope.

03

Own

Assign accountable business and technical owners.

04

Approve

Set a documented use status and conditions.

05

Constrain

Enforce identity, data, configuration and integration boundaries.

06

Observe

Monitor material change, exceptions and control health.

07

Retire

Remove access, delegated trust, data obligations and renewals.

08

Measure

Track coverage, decision speed, exceptions, lifecycle health and control effectiveness.

Shadow AI & SaaS Governance Readiness Score

Rate each domain from 0 to 4: 0 = absent; 1 = informal; 2 = documented; 3 = implemented and tested; 4 = measured and continuously improved. Maximum score: 40. Readiness percentage = total score divided by 40, multiplied by 100. Suggested interpretation: Basic 0-24%; Developing 25-49%; Defined 50-69%; Managed 70-84%; Adaptive 85-100%. This is an internal readiness aid, not a certification or external rating.

Shadow AI & SaaS Governance Readiness Score

Domain

Executive Assessment Question

Ready-State Evidence

Discovery

Are material services and AI use discoverable?

Current service register with multiple evidence sources.

Classification

Is purpose, data, user, integration and action scope recorded?

Completed service classification.

Ownership

Are business and technical owners current?

Named owners and review date.

Policy

Are approved, restricted and prohibited uses explicit?

Use decision, conditions and exception route.

Identity

Are users, admins and service identities governed?

Role and identity register.

Integration

Are OAuth/API scopes and connectors reviewed?

Scope, owner and revocation evidence.

Data

Can sensitive-data handling be governed and evidenced?

Data policy and enforcement evidence.

Monitoring

Are new use and material change observed?

Alerts, review queue and closure.

Retirement

Can all trust and obligations be removed?

Tested closure and revocation process.

Measurement

Are coverage, aging, exceptions and control health reported?

Metrics, thresholds, trend and owner.

Control Principles for Security and Assurance Teams

  • Every material external service should be discoverable and represented in the governed inventory.

  • Every service should have a current business owner and technical owner.

  • Every high-impact integration should have visible identity, permission scope, purpose and revocation path.

  • Every policy decision should translate to a usable control, exception route, or approved alternative.

  • Every material change should trigger proportionate re-review.

  • Every retirement should close accounts, delegated trust, data obligations and commercial renewal.

  • Every control claim should be supported by local evidence rather than assumed from supplier marketing.

Governance Maturity Model

Figure 3. CyberTech Intelligence Governance Maturity Model

Maturity

Operating Pattern

Leadership Priority

Reactive

Unknown services are addressed case by case; ownership and delegated trust are incomplete.

Establish inventory and service ownership.

Defined

Service records, approval conditions, owners and review paths exist.

Standardize access, data and configuration requirements.

Controlled

Decisions are enforced; changes and integrations are monitored; retirement is managed.

Improve exception aging, automation and evidence quality.

Adaptive

Review depth and controls change based on measured service authority and risk.

Scale only where evidence shows control effectiveness.

Executive Recommendations and Conclusion

  • Govern AI services and SaaS integrations by the data, identity, permission and action authority they receive.

  • Make supplier due diligence and customer-side configuration part of the same approval decision.

  • Require a technical expression for each policy outcome so "approved" and "prohibited" are not only labels.

  • Treat delegated OAuth and API access as lifecycle assets that must be reviewed and revoked.

  • Use the first 90 days to prove one business function can move from discovery to decision, enforcement, evidence and retirement cleanly.

The practical architecture for shadow AI and SaaS sprawl is not a larger blocklist. It is a governed service lifecycle. When inventory, ownership, identity, data, integrations, policy, monitoring, and retirement share one decision model, the organization can support legitimate adoption while preserving the ability to explain, constrain, and remove enterprise trust.

Convene an AI and SaaS Control-Architecture Working Session

Bring security, IT, identity, data/privacy, procurement, and one business owner together. Map one high-use AI service through the eight layers, resolve any missing decision right, and agree on the minimum evidence required to keep or expand its enterprise access.

About CyberTech Intelligence

CyberTech Intelligence provides research-led cybersecurity intelligence, executive content, and market engagement programs. This publication is vendor-neutral and intended for education, decision support, and claim-safe GTM planning.

Research and Citation Governance

External sources are used only within their stated scope. Government and standards guidance is treated as control guidance, independent research is attributed to the publishing organization, and vendor documentation is used only for vendor-specific capabilities or observed datasets. CyberTech Intelligence does not infer that a named organization has an incident, control weakness, buying project, budget, or risk posture without direct evidence. CTI frameworks and readiness tools are editorial operating models, not certifications, audits, legal conclusions, product ratings, or forecasts. Editorial QA control completion: 10/10.

References

  1. National Institute of Standards and Technology, “SP 800-207: Zero Trust Architecture,” August 11, 2020. https://csrc.nist.gov/pubs/sp/800/207/final  Accessed September 21, 2026. Relevance: foundational zero-trust principles for resource protection and explicit trust decisions independent of network location.
  2. Cybersecurity and Infrastructure Security Agency, “Secure Cloud Business Applications Technical Reference Architecture,” public reference architecture. https://www.cisa.gov/sites/default/files/2022-12/SCuBA_TRA_RFC_EG_508c.pdf  Accessed September 21, 2026. Relevance: federal architecture illustrating identity, endpoint posture, cloud-access policy, secure configuration and visibility for cloud business applications.
  3. Cloud Security Alliance, “SSCF Implementation Guidelines,” final-draft implementation guidance for SSCF v1.0. https://cloudsecurityalliance.org/artifacts/sscf-implementation-guidelines-v1  Accessed September 21, 2026. Relevance: actionable guidance for operationalizing SaaS security capability requirements.
  4. Cloud Security Alliance AI Safety Initiative, “OAuth Ghost Tokens: Enterprise AI Integration Supply Chain Risk,” May 5, 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-oauth-ghost-tokens-ai-integration-risk-202/  Accessed September 21, 2026. Relevance: current research on dormant delegated authorizations, OAuth scope, AI/SaaS integrations, and token lifecycle risk.
  5. Microsoft Learn, “Discover AI apps and data,” current product guidance. https://learn.microsoft.com/en-us/security/security-for-ai/discover  Accessed September 21, 2026. Relevance: vendor-specific example of discovering AI apps, sanctioning or blocking use, and assessing AI data exposure.
  6. UK National Cyber Security Centre, “Managing the cyber risk of agentic AI,” August 20, 2026. https://www.ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai  Accessed September 21, 2026. Relevance: current official guidance on safeguards, oversight, observability and stronger controls for higher-authority AI systems.
  7. Microsoft Learn, “Govern discovered apps in Microsoft Defender for Cloud Apps,” updated August 10, 2026. https://learn.microsoft.com/en-us/defender-cloud-apps/governance-discovery  Accessed September 21, 2026. Relevance: vendor-specific operational guidance for sanctioning, monitoring, warning on, and blocking discovered cloud applications.