The Missing Warning Label: Governing AI Access to Mail and Data

For IT and Security Teams: controls to build, test and monitor

Prescription drug advertising has to put risks next to benefits while the patient is still deciding. Artificial intelligence (AI) offers don't. ChatGPT, Gemini, Claude, Copilot and the AI built into everyday apps now offer to triage an inbox, find subscriptions or draft replies, and the user sees the benefit in one sentence and a consent screen in the next. What they don't see is the threat model.

That gap lands on us. The same offer your users accept at home shows up at work as a connector request, an add-in install, an embedded assistant feature or a quietly authorized third-party app. This article treats that offer as what it is: delegated access to one of the highest-value data stores in the organization, combined with a component that will read attacker-controlled content.

Your users are getting plain-language versions of this guidance in Start Here, Go Deeper, Advanced and, for their families, AI at Home. Every level carries the same warnings. This one adds the controls.

⚠ WARNING LABEL: AI access to mail (administrator edition)

Indications: mailbox triage, subscription discovery, thread summarization, reply drafting.

Possible side effects: mailbox-wide retrieval beyond the stated task; indirect prompt injection from inbound mail, including ignored spam and compromised trusted senders; zero-click egress through rendering, previews, search and tool calls; poisoned or fabricated facts repeated with citations; irreversible disclosure, since revocation stops future access but recalls nothing; persistence through installed add-ins, standing grants and scheduled jobs.

Contraindications: unenforced scope, unvalidated output reaching a renderer, no verified cancellation and revocation path.

The risk statement

An inbox-cleanup request can initiate OAuth-delegated access to a mailbox that holds password-reset links, one-time codes, financial records, protected health information and other people's data. The assistant will retrieve attacker-controlled messages alongside those secrets, then pass model output to renderers, tools or external services. The outcomes include unauthorized disclosure, misleading guidance, unwanted state changes and persistence through automation.

Deployment decision: proceed only when the identity, data, action and egress boundaries fit the task and are enforced outside the model. A prompt, a selected label, a read-only grant, human review or a short access window is not sufficient by itself. If you can't establish the required limits, use minimized, reviewed inputs or an approved manual workflow.

Model the workflow, not the chatbot

Our personal AI security checkup asks three questions before anyone shares, installs or clicks Connect. They map directly to what Simon Willison calls the "lethal trifecta": private data, untrusted content and a way to send data out.

Add the fourth control the users' guides call "pull the plug": verified cancellation and revocation at every layer.

Treat the three questions as a disclosure-chain lens, not a complete definition of the risk. A poisoned answer that sends a user to a fake support number causes harm without exfiltration. Unauthorized decisions do too.

Key terms, aligned to the OWASP GenAI Top 10s:

• Indirect prompt injection (LLM01; ASI01 agent goal hijack): instructions that enter through lower-trust content the model was asked to process. Retrieval authorization tells you whether the assistant may read a message; it says nothing about whether the message's contents are safe to obey.
• Sensitive information disclosure (LLM02): secrets reaching outputs, logs, search queries or third parties.
• Improper output handling (LLM05): model output reaching a renderer, browser, script engine or API without validation. The mail client is a separate trust boundary.
• Excessive agency (LLM06; ASI02 tool misuse): more reach or autonomy than the task requires. Injection is far more dangerous when unrelated data and actions are within reach.
• Supply chain (LLM03; ASI04): plugins, skills, extensions and add-ins. An install is a Connect button that stays.
• Misinformation and source poisoning (LLM09; LLM08 when the poisoned source is a retrieval index): fabricated contacts or payment details planted where retrieval will find them, repeated as fact with citations.
• Memory and context poisoning (ASI06): injected content persisting into saved memory or project context and influencing later sessions.

What the email research actually shows

Two recent findings shape this use case. Read both precisely.

KnowBe4 (September 2026) reported two distinct lab paths. In the first, hidden instructions in an email's HTML, styled at near-zero opacity and passed by Gmail's content filter as valid CSS, reached Gemini in the Gmail side panel. A translation request produced a correct translation plus an injected "Translation Verification Log" containing two one-time codes, with expiry warnings, copied from unrelated messages. The side panel's output controls held: URLs carrying the data were stripped and autonomous sends were blocked, so the exposure stayed in the response shown to the user. In the second, a Google Apps Script workflow that used Gemini to draft replies saved generated HTML that transmitted a one-time password to an external server when the user opened the draft. That pipeline had recent inbox context and no equivalent output boundary; the draft's hidden image was fetched server-side by Gmail's image proxy. It ran Gemini 3.5 Flash, and KnowBe4 reports that Gemini 3.6 Flash and 3.7 Flash resisted the same injection. Read together, the tests show defense in depth working and failing: the model layer failed in one path, output controls contained it, and a custom workflow without those controls leaked. KnowBe4's ThreatLabs also reports live phishing campaigns in customer-reported mail with payloads aimed at AI assistants rather than people. Weigh the vendor's commercial interest, but treat this as an active technique, not a lab curiosity.

The engineering lesson isn't "Gemini is vulnerable." It's that retrieval authorization, context construction, model-level defenses, output interpretation and network behavior are separate layers, and the weakest one decides the outcome. Human review of a draft happens too late if rendering the draft makes the request.

Microsoft (September 2026) described EvilTokens, a phishing-as-a-service kit that abuses the OAuth device-code flow with AI-assisted lures to compromise business email. The user signs in on a genuine Microsoft page and authorizes an attacker-initiated session. A real sign-in page does not prove the request belongs to the user. Microsoft attributes more than 12,000 compromised inboxes across over 10,000 organizations to the kit since February 2026. Stolen tokens bypassed MFA; persistence came from inbox rules that concealed communications and from registering new devices; and attackers used AI assistants post-compromise to mine mailboxes and Microsoft Graph reconnaissance to map the organization. Restrict device-code flow where you don't need it, alert on new inbox rules and device registrations, and teach "approve only what you started."

Earlier work points the same way: EchoLeak (zero-click exfiltration from Microsoft 365 Copilot via a crafted email, 2025, patched), calendar-invite injection against Gemini (early 2026, mitigated), and AI-browser agent attacks (Zenity Labs' PleaseFix research, 2026). Vendors fix individual paths. The pattern keeps recurring because the architecture keeps mixing private data, untrusted content and an outbound channel.

Scopes are not task boundaries

OAuth scopes express classes of operations, not task-specific resources. A user who asks about "only my newsletters" has granted whatever the scope allows.

• Gmail API separates metadata (gmail.metadata: labels and headers, no bodies), read (gmail.readonly, which also covers settings), compose and send (gmail.compose, gmail.send), modify (gmail.modify), settings and filters (gmail.settings.basic) and full access (https://mail.google.com/, including permanent deletion). Google classifies most of these as restricted scopes. Metadata avoids bodies, but subjects and sender lines still leak plenty.
• Microsoft Graph separates Mail.ReadBasic (no body or attachments) from Mail.Read, plus Mail.Send, Mail.ReadWrite and MailboxSettings.ReadWrite. Application permissions without scoping (an application access policy, or RBAC for Applications in Exchange Online) reach every mailbox in the tenant.
• A label filter, folder selection or prompt instruction is a query restriction, not a permission restriction. Don't let marketing copy or a consent screen imply otherwise. Where the platform can't enforce a resource boundary, use a staging mailbox, an approved integration that checks each resource access, or prepared inputs.
• Embedded assistants have no new consent event. Inventory feature-native AI (Gemini in Workspace, Copilot in Microsoft 365) and OS-level assistants (Copilot on Windows, with Vision, connectors and local-file Actions; Apple Intelligence on macOS) alongside third-party grants. Govern OS-level features through device management, not just tenant settings. The absence of a consent prompt is not the absence of AI access.

OWN IT: Govern purpose, identity and data responsibility

• Name owners for the business process, data, integration, automation and incident response before choosing a model or connector.
• Define the task in writing: permitted outcome, prohibited reads and actions, success checks and the manual fallback. "Produce a list of newsletter senders for a person to review" needs no message bodies, no attachments, no send rights and no settings scopes.
• Inventory identities and grants: human, shared and service accounts; OAuth consents; connector grants; installed add-ins and extensions; stored context and memory; indexed copies; schedules, triggers, queues and retries. Confirm whose authorization applies to every operation. A shared or agent-owned connection may carry different permissions than the user's.
• Classify the data path: the exact account, feature, region, contract and processing chain. A paid or enterprise plan name doesn't prove that a purpose, connector or outbound feature is approved. An agreement covers the vendor's walls, not its doors: business associate agreements (BAAs) and data processing agreements (DPAs) govern the vendor's handling, not a stranger's email instructing the assistant or a web search carrying context to a third party.
• Take a protected baseline of grants, sessions, devices, forwarding, delegates, inbox rules, custom instructions, memories, shared artifacts and independent jobs. Record which logs exist and where the gaps are. A baseline is detection evidence, not a preventive control.

SECURE IT: Enforce least privilege and isolation

Start from no access and grant only what the task needs, with policy enforced outside the agent. Microsoft Execution Containers (MXC) has process backends for Windows, macOS, and Linux; Microsoft also documents NVIDIA OpenShell integration. Backend properties differ. A sandboxed local agent can still use a cloud model. Evaluate containment, provider access, model location, identity, and monitoring separately.

Technical note, checked October 22, 2026: OpenShell v0.1.5 inference guidance uses provider profiles and sandbox attachments. It documents removal of the older workspace-global managed inference route and openshell inference commands. Follow documentation for the deployed release and test effective permissions, credential access, revocation, and outbound destinations after changes.

• Least privilege across every axis: identities, resource sets, API operations, tools and network destinations. Prefer metadata or prepared text to full content where it suffices.
• Control embedded email AI centrally. In Google Workspace, admins can turn off Gemini for users, set a default for smart features (users can override it) and turn off dynamic email; in Microsoft 365, admins control Copilot availability in Outlook. Treat new built-in features as changes to review, and expect them to arrive on by default; consumer accounts your people also use got Gemini in Gmail (U.S.), Copilot in Microsoft 365 Personal and Family, and Apple Intelligence that way, with announcements few users read. Gmail's AI Inbox, for example, arrived for some users with options to mark, archive or delete source mail based on AI grouping. Don't add internal URLs to the image proxy allowlist without need, and encourage users to set Ask before displaying external images. Scope this to calendar and chat too: an invite is inbound content, and researchers have used invites to steer Gemini, so encourage users to add invitations only from known senders. For personal accounts on managed devices, explain the risk and let people choose, since you don't control those settings.
• Govern consent. Restrict user consent to verified publishers and low-risk scopes; route everything else through admin review. Block or tightly scope device-code flow. Require phishing-resistant MFA for administrators and anyone who can grant tenant-wide access, and prefer passkeys for all users, then authenticator apps, with SMS and email codes last.
• Allowlist installs. Plugins, skills, browser extensions and Office add-ins get the same review as any other code with data access: publisher, purpose, install location, scopes, update channel and removal path. Depending on its permissions and host application, a document add-in may read document contents.
• Isolate context. Keep unrelated secrets and stores out of the task. Inspect inherited project context, saved memory, synced content and attached files. A new chat or project label isn't proof of isolation. Long sessions and agent runs also drift as context fills or is compacted, and earlier instructions can drop out. Set checkpoints and session limits for agents, and teach people the general rule of one task, one chat, with a reviewed handoff summary when work continues.
• Separate retrieval, planning, rendering and execution. The execution component independently validates a structured, authorized operation. A model's assertion that it is permitted is not evidence.
• Keep credentials and pseudonym label keys out of model context and out of storage the assistant can reach. Limit token lifetime and audience. Understand the provider's revocation and session semantics.
• Control egress per component. Restrict outbound destinations, disable automatic web search for sensitive work, and block remote content in AI-generated output. Remember that client-side controls don't govern a provider-side renderer, search service or proxy, and an allowed domain can still host an attacker-controlled resource.

Commercial controls vary by plan, workspace and surface, and some actions may run without a separate confirmation. Evaluate the actual configuration, not the general promise.

PROTECT IT: Validate content and consequential effects

• Treat inbound mail and tool results as untrusted data. Preserve source markings and keep them separate from trusted workflow instructions. Classifiers and model alignment are useful layers; neither should be the only thing standing between the model and unrelated resources.
• Minimize before model access. For files, strip comments, tracked changes, hidden sheets, embedded objects, author metadata and image location data. Reviewed plain text can avoid many file-metadata and active-content risks. It can still contain sensitive details or malicious instructions, so minimization and output checks remain necessary.
• Pseudonymize with care. Replacing identifiers with consistent labels like [PERSON_A] reduces exposure while keeping relationships in the text. Protect the label key outside the assistant's reach. Review residual roles, dates and locations. Pseudonymized data is still personal data under GDPR and may still be regulated; label replacement does not provide anonymity, de-identification or injection resistance.
• Validate output before its destination interprets it. Prefer plain text for recommendation-only workflows. When rich content is required, sanitize and encode for the target context and disable remote resources and active content. Schema-valid output can still name an unauthorized recipient or a fake phone number; validate meaning, not just format.
• Gate every consequential operation. Check the acting identity, resource, recipient, destination, data, visibility and effect. Require renewed approval when any of them change. An approval after an external fetch prevents nothing.
• Verify consequential facts out of band. Support numbers, payment details and login pages from AI output get checked against independently maintained records. Vigilance Security, as reported by KnowBe4, found poisoned support contacts for 374 major brands, planted on high-authority sites to be retrieved by AI answers. If you run customer-facing AI, monitor the answers customers actually receive for your support, refund and account-recovery queries, and compare returned numbers and URLs with verified records.
• For the unsubscribe use case: the model produces candidates with reasons and uncertainty; a person verifies each subscription through the official service; suspicious mail goes to the phishing-report workflow, never to its own unsubscribe link.

Set input and output rules

For each approved task, record the following limits and enforce them outside the model:

• Allowed data. Identify the purpose, data owner, approved source systems, resource set, fields, date range and record limit. Specify what is allowed, what requires approval and what is prohibited for this destination. Authorization to retrieve data does not authorize every use of it.
• Preparation before model access. Remove unnecessary identifiers and secrets, or replace approved identifiers with labels. Inspect residual confidential content, attachments and metadata. Keep credentials and label keys outside model context. Apply the same checks to connector retrievals and tool results; a cleaned manual copy does not protect originals fetched through another route.
• Permitted outputs. Specify the destination system, folder, database resource or recipient, visibility, and allowed operations such as create, append or overwrite. Separately approve sending, sharing, deleting and changing permissions. Logs, traces, caches and analytics are data destinations too.
• Checks before effect. Validate the actual content, resource, recipient and operation before display, rendering, execution or writing. Enforce rules in trusted application or tool controls. Recheck after local restoration of original values. Stop or use the manual fallback if a required boundary or approval cannot be established.

Pseudonymization does not lower a data classification by itself. An approved host is not blanket permission to use every resource or action on it. Changes to data, destination, visibility or operation require a new authorization check.

Worked example: compare two bills

In an authorized test, use synthetic bills referenced as BILL-A and BILL-B. Permit only billing periods, usage, charges and a provider label. Exclude names, service addresses, account numbers and payment details. The agent may create one draft in a restricted review folder; it may not email it, change payees, make payments or overwrite source files. A reviewer checks calculations, citations, labels and the destination before release. If originals are restored, the final destination must be authorized for the restored information. Record the rule checks, reviewer approval, output reference and actual write result.

MONITOR IT: Observe reads, transfers and independent work

• Log what matters: retrievals, tool calls, consequential actions and outbound requests, correlated with the request, initiating identity, connection, resource, destination, result and policy decision. Protect and minimize the logs themselves. A model-generated summary of what it did is not an execution record.
• Alert on the quiet changes: new OAuth grants and add-ins, new forwarding and delegates, new inbox rules, new devices, memory or instruction changes, and unusual access to secrets.
• Name your blind spots. User-visible confirmations may not cover provider-side retrieval, indexing, rendering or downstream services. Treat those as residual risk with an owner, or choose a narrower workflow. An unchanged rule list and an empty Sent folder don't prove nothing left.
• Define the kill switch at every layer: current task, execution queue, retries, recurring schedules, independent scripts, connector grants and source tokens and sessions. Confirm cancellation with the platform's controls, not with a text instruction, a closed tab or an uninstalled plugin. An independent trigger can keep running under its creator's account.
• Contain without destroying evidence. Revoke grants and sessions and handle exposed credentials by type. A password reset does not by itself invalidate delegated tokens, and revocation cannot recall completed transmissions. Teach users the same: find the Stop button first, closing a window or app usually doesn't stop server-side work, and stopping isn't undoing.
• Close the loop. Findings feed the next Own IT inventory and baseline: retire unused grants, agents and data stores to shrink the attack surface and blast radius.

Keep an audit record for each run

Use a shared run reference to correlate records from the source, orchestration layer, tools and destination. Capture what is available, and document missing visibility:

• Identity and versions: initiator, executing identity, agent, timestamps, and reported model, tool, workflow and policy versions.
• Input evidence: approved source and version references, data categories, retrieved scope, and preparation checks. Record categories or counts of removals when useful, without recording the removed values.
• Execution evidence: attempted reads, tool calls and writes; actual resources, recipients and destinations; results, errors, retries and stop or revocation events.
• Control decisions: the trusted control's allow or deny result, rule or reason code, and the scope, person and time of any approval. Record renewed approval when scope changes.
• Output evidence: artifact reference and version, destination, visibility, review or restoration status, and confirmation of the actual outcome.
• Stated rationale: sources cited, assumptions, uncertainty and the brief explanation supplied by the model. Label these as model statements and compare them with the execution evidence.

A model's explanation or displayed reasoning is not a verified account of its internal process. Research has found that reported reasoning can omit influences on an answer. Do not use it as the sole audit trail or ask a later summary to stand in for missing execution records.

Minimize and protect records. Avoid raw prompts, source text, passwords, access tokens, sensitive values and label keys in routine logs. If content must be retained, give it separately approved restricted storage and retention. Validate and encode event fields to prevent log injection, restrict access, detect tampering, and keep audit evidence outside the agent's ability to edit or delete it. Document provider-side blind spots and set retention and disposal rules.

Test the boundary with synthetic data

Use an isolated, authorized tenant with made-up records and canaries, harmless unique markers that reveal unintended reads or transfers. Keep real secrets out, and don't let test data reach an uncontrolled endpoint.

Record the build, configuration, grants, inputs, expected outcomes, observed events and remaining gaps. A pass establishes only what was exercised under those conditions.

Release gate for AI access to mail

Approve deployment only when the owner can explain and show evidence for:

1. The purpose, and why minimized or prepared inputs aren't enough if broader access is proposed.
2. The exact identities, readable resources, operations and inherited context.
3. Controls on untrusted content, secrets, rendering and egress.
4. The action-approval process and independent destination validation.
5. Cancellation, source-side revocation, retention and incident ownership.
6. Available activity evidence, test results, logging gaps and the accepted residual risk.

If those can't be met for the data's sensitivity, use the approved manual or prepared-input process.

Shadow AI: govern it by enabling it

AI is a force multiplier, and it multiplies in every direction at once:

• Workforce productivity. An employee with good AI tools and skills can compress hours of drafting, analysis and research into minutes.
• Accidental data leakage. One paste into a personal assistant moves regulated or confidential data outside your contracts, retention controls and eDiscovery. One consented connector can sync a mailbox to a third party.
• Agent sprawl. Agents spawn sub-agents, scheduled jobs and automations, each a non-human identity holding delegated tokens, often with no named owner and no expiry.
• Threat actors. Attackers use AI across the kill chain. Microsoft reports that EvilTokens used AI to write targeted lures, then used AI assistants after compromise to mine mailboxes for follow-on attacks.

Shadow AI is the use of AI tools, accounts, extensions, connectors and agents without organizational approval. It grows wherever the sanctioned path is slower or weaker than the unsanctioned one. Blocking alone pushes it to personal devices and personal accounts, where you lose all visibility. A common form isn't an unapproved tool on a managed laptop at all. It's an employee typing work content into a personal AI app on their phone, photographing a screen, or forwarding mail to a personal account, often while working remotely on a personal computer. Controls on managed endpoints never see the phone camera or the personal app; mail forwarding to personal addresses can be detected and blocked, but only if you've set that up. Not using AI is a risk too: the organization pays a fully loaded cost for every employee, and an employee doing AI-suited work by hand is like one doing spreadsheets on paper. Treat AI capability as an expectation to enable, inside guardrails.

A practical program:

1. Discover. Review OAuth consent and app-access logs, browser extension and add-in inventories, SSE or CASB telemetry, expense reports for AI subscriptions, and meeting bots joining calls. Look for API keys on personal cards.
2. Provide a better sanctioned path. Approved enterprise AI with SSO, contractual limits on training and retention, admin controls, audit logs and data protections. Make it available where people actually work, including on phones through managed apps and app protection policies where your bring-your-own-device policy allows. If the approved tool is worse or harder to reach than the free one, shadow AI wins.
3. Publish a usable policy. Which data classes may go into which tools, that personal accounts are never for work data, how agents and connectors are approved, and who owns each one.
4. Train for skill, not just compliance. Name the personal-device workaround plainly and without shaming: a photo of a screen or a forwarded email is still shadow AI, and once data lands in a personal account the organization can't protect or delete it. Teach the three questions, the person-in-the-middle workflow, prompting, cross-checking responses and verification. Make effective, safe AI use part of role expectations, and budget AI usage like any other productivity tool.
5. Run a fast intake. Treat workarounds as a signal of an unmet need, not only as a violation. A lightweight request path with a committed turnaround, so employees can raise opportunities and red tape to supervisors and leadership instead of working around them. AI champions in each team help surface both.
6. Govern agents as identities. Inventory non-human identities and their grants; require an owner, a narrow scope and an expiry; and include them in access reviews and offboarding.
7. Measure and iterate. Track adoption, time saved, policy exceptions and incidents. Review quarterly, retire what isn't used to shrink the attack surface and blast radius, and feed what you learn back into Own IT.

The same pattern applies at home. The Family Edition gives parents the household version: know what's used, set clear rules, make it safe to ask, and practice together.

Write the warning label into the product

If you build or buy these workflows, put the disclosure where the decision happens, not in a privacy policy. Before requesting access, the interface should state the task, the resources actually reachable, the actions allowed, who receives copies and for how long, what stopping can and can't undo, and a lower-access route. Give users the plain version and administrators the technical one.

The label has to match the configuration. Don't say "only selected emails" when the grant permits mailbox-wide retrieval, or "you'll review before anything is sent" when a preview can make an outbound request first.

Where this fits

The NIST Cybersecurity Framework 2.0 functions map cleanly: Own IT covers Govern and Identify, Secure IT and Protect IT cover Protect, and Monitor IT covers Detect, with Respond and Recover in the kill switch and incident steps. The standards overview explains the thematic relationship to NIST and OWASP and distinguishes personal habits from organizational controls and legal duties. It is an interpretive map, not a compliance assessment.

Providers and organizations own the enforceable controls. Training people to write better prompts can't replace them. But until every offer comes with an honest warning label, the people we support need to know which questions to ask, and we need to make sure the answers are true.

---

Own IT. Secure IT. Protect IT. was the 2019 Cybersecurity Awareness Month theme from CISA and the National Cyber Security Alliance. Monitor IT is the author's addition, because the first three are a theme and setup, but adding the fourth turns it into a repeatable lifecycle and sends you back to Own IT. This is independent professional guidance, not an implementation audit, compliance assessment or legal advice. The author develops commercial security tools in this area; this article is tool-neutral and recommends no product. Products named are examples, not endorsements; scope names and features were checked in October 2026 and change often. CC BY 4.0.

Sources

• OWASP LLM02:2025 Sensitive Information Disclosure
• OWASP LLM05:2025 Improper Output Handling
• OWASP Logging Cheat Sheet
• Reasoning models do not always say what they think | Anthropic research
• Are Your AI Assistants the Next Attack Surface? | KnowBe4
• CyberheistNews Vol 16 #39: Are Your New AI Assistants Your Next Attack Surface? | KnowBe4, September 29, 2026
• Jensen Huang says AI agents need limits, supervision and restricted access | Times Brasil (CNBC), September 2026
• NVIDIA OpenShell documentation
• Unmasking EvilTokens: Getting to the root of device code phishing | Microsoft Security Blog, September 2026
• EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System | arXiv
• Google Gemini Prompt Injection Flaw Exposed Private Calendar Data via Malicious Invites | The Hacker News
• PleaseFix Vulnerabilities | Zenity Labs
• Mitigating prompt injection attacks with a layered defense strategy | Google
• Choose Gmail API scopes | Google for Developers
• Microsoft Graph permissions reference | Microsoft Learn
• OWASP Top 10 for LLM Applications 2025 | OWASP GenAI Security Project
• LLM06:2025 Excessive Agency | OWASP
• LLM05:2025 Improper Output Handling | OWASP
• ChatGPT Work Overview | OpenAI
• Installable triggers | Google Apps Script
• Turn dynamic email on or off for users | Google Workspace Admin Help
• Learn about smart features and controls | Google Help
• Manage Workspace smart features for your users | Google Workspace Admin Help
• Pseudonymisation | ICO
• The NIST Cybersecurity Framework (CSF) 2.0 | NIST
• October is National Cybersecurity Awareness Month (2019) | CISA

For the business decision, start with choosing where automation and AI can help and the employee and recurring-issue examples.

For organizational decisions, compare the total cost of existing tools, cloud, local, and hybrid approaches, including review, security controls, support, and exit. Name the budget owner, control operators, and authorized owner of remaining risk. Keep cash savings, released capacity, cost avoidance, and uncertain risk reduction separate.

Apply this in your organization

We help turn AI access concerns into data rules, limited permissions, reviewable activity, and tested response procedures. Explore responsible AI services, or discuss your priority by email.

Explore the guides

All AI safety guides | Reference library