What to take away
Treat Shadow AI inventory as an input to governance, not as governance itself. Write a short acceptable-use decision: approved tools and account types, prohibited data classes, exception owners, and what happens when someone needs a new assistant or agent. Separate chatbot use from agents that can act through connectors. Measure approvals, exceptions, tested controls, and stale grants—not only “number of AI domains seen.” Build the process with native admin consoles and browser controls you can actually operate today; verify any additional vendor coverage for your deployment.
1. Inventory finds tools; governance decides conditions
The Shadow AI security guide covers how to record tools with evidence, distinguish observed use from verified accounts, and test prompt or upload controls. Keep that workflow.
Governance adds decisions that inventory alone never makes:
Without those decisions, every new Reddit “which AI do you allow?” answer becomes a one-off ticket. With them, discovery has somewhere to land: approve, provide an alternative, or block while assessment runs.
| Governance decision | Example outcome |
|---|---|
| Approved tools | Named work tenants (for example Microsoft 365 Copilot, a contracted Claude workspace)—not “any chatbot” |
| Account context | Work identity only on managed devices; personal accounts prohibited for work data |
| Data classes | Public and internal OK; customer PII, secrets, and regulated sets prohibited outside approved tenants |
| Agents vs chat | Agents need separate approval for connectors and stop-capability |
| Exception path | Named approver, time-boxed exception, synthetic-data examples for teams |
2. Write a one-page AI acceptable-use that people can follow
Aim for one page leadership will actually endorse and employees will actually read. Include:
ANSSI’s generative AI security perspective and NCSC secure-AI guidance both push teams to treat prompts, logs, and agent actions as assets—not only the brand name of the model. Align your page with that: revisit when data or permissions change, not only when a logo appears in a browser report.
Publish the page where people already look (intranet, HR handbook, onboarding). Pair it with the acceptable alternative: if you ban personal ChatGPT for customer data, say which approved path to use the same day.
- Purpose — why the company uses generative AI (productivity, customer work, engineering) and what is out of scope.
- Approved list — tools and account types; link to how to request additions.
- Prohibited inputs — concrete categories with synthetic examples (fake customer rows, fake API keys)—not vague “be careful.”
- Agents and automations — any tool that can send mail, change files, or call APIs needs an owner, scopes, and a person who can shut it down.
- Monitoring expectation — which browsers/devices are covered; what is not covered (personal phones, unmanaged browsers).
- Incident and exception — how to report a mistaken paste; how long an exception lasts.
References: Security recommendations for a generative AI system · Thinking carefully before adopting agentic AI · Managing the cyber risk of agentic AI
3. Assign roles: business owner, security/IT, and exception approver
Three named roles beat an unnamed “AI committee”:
Awareness teaches risky pastes; it does not approve scopes. Verify the edition, region and usable coverage of any proposed vendor control. Start with current Google/Microsoft consent controls, supported browser warnings or blocks, and a manual agent inventory when needed. A new vendor module is not a precondition for assigning owners and making access decisions.
- Business owner — work need and data classification.
- Security or IT owner — tenant restriction, OAuth policy, browser controls, offboarding revoke.
- Exception approver — manager plus security; time-boxed when the business cannot wait.
References: Identify and secure compromised accounts
4. Connect approval to OAuth and offboarding—or governance decays
In Material Security’s sample of 22,332 apps across 21 Google Workspace environments, 91% of AI/automation apps were first observed since January 2024; 1,064 apps had live tokens and no current active users. These findings do not measure Elba customers or every SMB.
Minimum links: register new AI/automation connections (owner, purpose, scopes); on offboarding, verify sign-in, user grants, tenant consent and agent tool credentials separately; Google suspension resets that user’s OAuth tokens, while other grants still need review. Microsoft delegated-grant deletion stops new tokens for that scope but existing access tokens can remain valid until expiry; quarterly dormancy at ~90 days; reopen approval when an agent gains a connector or action. Mechanics live in third-party OAuth apps and user access review—put them under named AI governance owners.
References: OAuth Risk Report summary · Identify and secure compromised accounts · Delete a delegated permission grant
5. Measure governance health—not only discovery volume
Prefer decision metrics over raw discovery volume:
Blocking AI domains without an approved alternative pushes work onto phones. Market threads on personal accounts, agents/OAuth, and AI inside paid SaaS keep showing that one DNS list does not cover five evidence surfaces—governance names which control owns each surface.
| Metric | Why it matters |
|---|---|
| % of discovered tools with owner + decision | Inventory without decision is incomplete |
| Open exceptions past due date | Shows whether the exception path is real |
| Grants revoked/restricted with source verification | Closes zombie access |
| Synthetic control tests on enrolled browsers | Untested policy is aspiration |
| Agents with a documented stop-owner | Chatbots and agents differ |
6. Run a 30-day SMB governance sprint
Week 1 — One-page policy; leadership sign-off; publish approved tools and prohibited examples. Week 2 — Map Shadow AI inventory to owner/decision/exception; clear top tools by users or sensitive scopes. Week 3 — Verify admin consent defaults; add OAuth revoke to offboarding. Week 4 — Synthetic browser/native tests; record gaps (unenrolled devices, binary uploads, phones); schedule quarterly dormancy.
Then calendar monthly tools-with-decision review and quarterly grant dormancy next to access reviews—do not treat the sprint as “AI finished.”
How Elba supports this workflow
Elba helps turn governance decisions into operable controls when the relevant modules are connected. Third-Party Apps and browser observations feed an application inventory so Shadow AI entries can carry owners and usage policy. Configured Browser Security Playbooks apply warnings or blocks in supported enrolled-browser journeys. Check each provider, composer, account, file format and policy. A web Copilot result does not establish native Microsoft 365 grounding or Copilot Studio connector protection; binary formats are metadata-only and incomplete inspection is not itself an upload block. Data Protection surfaces supported sharing exposures when work data is already overshared before anyone pastes it into an assistant. Security awareness and phishing practice remain available for human hygiene; they do not replace grant reviews or agent approvals.
Elba does not replace your written acceptable-use policy, legal review, or Microsoft/Google admin consent configuration. It does not claim parity with every enterprise agent-risk module on the market. Validate coverage for your browsers, enrollments, and sources before you report a control as effective.
References: Identify and secure compromised accounts
AI governance checklist for SMBs
Your checks stay on this page and reset when you reload it.
Common questions
Is Shadow AI the same as lack of AI governance?
No. Shadow AI is unapproved or unmanaged use. Governance is the set of decisions and controls that define approved use. You can have inventory without governance, and you can have a policy that nobody can follow because no approved tool exists.
Can we ban all generative AI?
You can prohibit it, but teams will often move to personal devices. Most SMBs get better outcomes by naming approved tenants, restricting high-risk data, and testing controls—then blocking what remains outside that path.
Do we need a new agent-risk product before starting?
No. Use the consent inventories and supported controls already available, record approvals and exceptions, and verify offboarding effects in each source. Check any additional product’s actual coverage, edition and regional availability before relying on it.
What belongs in the board or leadership update?
Approved-tool coverage, exception backlog, grants revoked after offboarding or dormancy, and tested control results—not a raw count of AI websites alone.
Sources & further reading
Primary documentation used to review this guide. Product settings and edition requirements can change; check the linked documentation before making changes.