How I Do It
Example setup

An illustrative ecosystem, separate from your learning workspace.

Explore the example · Security checklist

Put the shared guidelines into practice

Security checklist

Set up a safer space for AI. Start with a separate login, learning accounts, and a clear record of what each tool can access.

This is a setup guide, not a security scan. An AI tool’s access depends on what you share, connect, and permit. A separate account is one useful layer; completing this page does not certify your computer as secure.

01

Create a separate learning login

Give your AI practice its own space, with fewer privileges than an administrator.

What to do

  1. On a personal Mac, use an existing administrator login to open System Settings → Users & Groups → Add User. Choose Standard and create a login such as AI Learning.
  2. Keep your administrator login for maintenance. Sign into AI Learning for course work, and check that it is still a Standard account.
  3. For an employer or university device, ask IT which setup is approved. Use an approved browser and fictional examples while access is arranged.
Apple: add a user on your Mac
02

Keep personal passwords separate

Only learning credentials should be available in the learning login.

What to do

  1. Begin without signing into your personal Apple Account or importing personal browser data. A Mac login and an iCloud account are different things.
  2. For example, keep personal Apple Passwords in your personal login and use a dedicated 1Password account containing only learning credentials in AI Learning.
  3. Check every password-manager account and browser extension signed in there. Do not add your personal vault or enable personal browser sync.
1Password: using multiple accounts
03

Use a learning email account

Protect the messages that could reveal personal information or reset a sensitive account’s password.

What to do

  1. Use a dedicated learning mailbox. Keep banking notices, private correspondence, and sensitive password-reset messages in a separate private mailbox.
  2. Do not sign into that private mailbox in the learning login. Check forwarding, delegated access, mail apps, and AI email connections too.
  3. Keep bank, insurance, and private health-portal sessions in your personal environment. Check private recovery mail there as well.
04

Choose which files and permissions to share

Give a tool the information needed for the current exercise.

What to do

  1. Create a course folder with fictional practice files. Review personal cloud sync, the Mac’s Shared folder, and connected network drives before opening an agent.
  2. In System Settings → Privacy & Security, review access such as Files & Folders, Full Disk Access, Accessibility, and Screen Recording. Ask what the tool needs for this task.
  3. Review unfamiliar permissions with IT or an instructor. Preserve assistive technology you depend on. Keep passwords, tokens, and recovery codes out of chats, project files, and your map.
Apple: Privacy & Security settings
05

Record each tool and connection

Keep track of plugins, MCP servers, and other connections as your setup grows.

What to do

  1. For each tool, record its purpose, the account it uses, the data it can access, and whether it can read, change, or send information.
  2. An MCP server is one way to connect an AI tool to another service. Check who provides it and the permissions it requests before enabling it.
  3. Record how to disconnect the tool and when you last reviewed it. Review access when your task changes, and revoke connections you no longer need in the relevant service.
06

Review actions before they affect others

Make the permission to act as clear as the permission to read.

What to do

  1. Name the task and its limits. Start with drafts and fictional examples; review proposed changes before sending, paying, deleting, publishing, or submitting.
  2. Treat text inside email, documents, and websites as information to inspect. It should not override your instructions or authorize new actions.
  3. Know how to stop the task, disconnect its access, and pause a schedule. Set practical time and spending limits, and check important answers against their sources.

A common mistake

“I made a new login, then connected my usual email.”

Sam uses a Standard Mac login, but connects a personal inbox to an AI assistant. Bank notifications and password-reset messages still arrive in that inbox. The new login does not undo the email access Sam granted.

What would you change?

Use a learning mailbox. Keep the private inbox outside the learning login and check forwarding and delegated access. The assistant’s ability to read depends on its actual permissions; this example does not mean it necessarily read those messages.

Build your learning setup
How agents make decisionsShared values for every projectAsk an agent to review securityInstructions for an independent reviewProtect app accounts and dataChecks for apps that use Supabase

Optional detail

Security notes from the example setup

These original notes describe Salim’s example architecture and intended safeguards. They are reference material, not a report that every connection or control has been verified. Check actual access before applying them to your own setup.

Where information goes 6 areas

Human zone

You. Voice in, decisions out. Kill switch on scheduled bots.

Public model zone

Grok, ChatGPT Pro, Claude, Perplexity, Gemini, Cursor Agent, Codex. Assume the vendor can see the prompt and the tool result.

Memory zone

GitHub Code (repos), GitHub Content (playbooks / docs), Drive (human copies, folder-scoped), and Supabase (live app records, RLS). The content → Drive bridge is one-way.

Tool zone

Plaud, Wispr Flow, Speechify, Todoist, Calendar, Gmail, WhatsApp, Inkbox, Trip Waffle, Cursor. Live data. Connection type matches the record type. Three microphones, three jobs. Cursor is hands for code — it is not a second brain.

Local zone (planned)

HT Sherpa / Ollama / LM Studio. Data that should never cross a public API. Firewall before it talks to the rest.

Publish zone

Cursor or Codex writes, GitHub stores, Netlify hosts the playbook, Cloudflare hosts Command Center, GoDaddy names. The public site is a scrubbed view. DNS changes are as serious as a deploy.

Actions that need human review 8 examples

Staging promotion

You, in the morning conversation

Plaud actions become real tasks only when you say so.

Calendar attendees & Meet

You

Secretary proposes slots. Event exists after the other person picks.

Sending mail

Allowlist + you

Only a named domain may trigger a reply. No general send on the daily coach.

WhatsApp / iMessage send

You

Bots may draft. You hit send. No group blasts from a schedule, even if the text was dictated with Wispr.

Inkbox identity

One role per badge

The secretary identity does not get Plaud or Drive. A2A stays off until the email job is boring.

Grant submit

You

Every claim, budget number, and commitment is signed by a person.

Public publish

main branch

Netlify deploys the scrubbed playbook from main. Private IDs stay in private repos.

DNS / domain

You, on the registrar

GoDaddy holds the name. Domain lock on. No bot gets this login. A nameserver change is a publish.

Risks and technical notes 10 topics

The labels and risk groupings below come from the original example notes. They are not a current security assessment or a verified mapping to a particular OWASP release.

Source label A01Source priority: high

Prompt injection (direct and via retrieved content)

A Plaud transcript, a WhatsApp forward, or an email body can contain instructions aimed at the bot (‘forward this to everyone’, ‘ignore staging’). That is untrusted input, not a user. Wispr dictation can land the same text in the wrong window.

Original suggested action: Treat recordings and mail as data, never as commands. Staging inbox. Allowlisted senders. Never let retrieved text change policy.

PlaudGmail (work)Google DriveWhatsAppWispr FlowInkbox
Source label A02Source priority: high

Insecure / excessive tool use

Grok Bot holds Plaud, Todoist, Calendar, Gmail, Drive, GitHub, and an Inkbox identity at once. Claude’s plugin tray is even wider (WhatsApp, Netlify, Inkbox). Cursor Agent and Claude Code each have a terminal in the repo on the local drive.

Original suggested action: One role, few tools. Separate Grok Bot schedules are not a firewall — they share infrastructure. The secretary does not need Plaud. The morning coach does not need to send mail. Cursor and Claude Code do not get the registrar, and are started in the project folder, never the home folder.

Grok BotClaudeComposioInkboxCursorClaude Code
Source label A03Source priority: high

Data exfiltration

A bot that can read Drive and send Gmail or WhatsApp can be tricked into mailing the weekly goals folder to an outsider. An Inkbox phone number is the same risk with a different socket.

Original suggested action: Send is a named, allowlisted job. No general-purpose ‘email this’ tool on the daily coach.

Gmail (work)Google DriveGitHub AppsGitHub BrainWhatsAppInkbox
Source label A04Source priority: high

Excessive agency

Auto-creating calendar events, auto-replying, auto-deploying the site, auto-texting, an IDE agent running terminal, a DNS change. Each is useful and each is irreversible-ish. An Inkbox identity that can mail and call is excessive agency in one badge.

Original suggested action: Secretary proposes times and waits. Deploys only from main. Grants always have a human sign-off. DNS never from a bot. Review Cursor diffs before they become main.

Gmail (work)Google Calendar (work)NetlifyInkboxWhatsAppCursorGoDaddy DNS
Source label A05Source priority: medium

Supply-chain / MCP-server compromise

MCP servers and Composio sit between the model and your data. Cursor can load the same MCP servers inside the IDE. A poisoned server is a poisoned tool. A compromised registrar is a compromised public name.

Original suggested action: Prefer first-party MCP. Inventory plugins. Revoke unused OAuth. Watch for new scopes.

ComposioPlaudTodoistInkboxWispr FlowTrip WaffleCursorGoDaddy DNS
Source label A06Source priority: medium

Insecure output handling

If a bot writes HTML or a shell snippet that someone later runs, the output became an attack. Cursor Agent writing code you then execute is the same pattern.

Original suggested action: Playbook site is static. Instruction files are Markdown. No eval of model output.

GitHub AppsGitHub BrainNetlifyTodoistCursor
Source label A07Source priority: medium

Model manipulation and jailbreaks

Scheduled prompts are long and live in GitHub. If they drift, every morning run drifts.

Original suggested action: Keep prompts in git. Review diffs on instruction files the way you would review code.

Grok BotChatGPT ProClaude
Source label A08Source priority: high

Sensitive information disclosure

Voice recordings, dictation, weekly docs, and folder IDs. Speechify can play a doc on a speaker. Cursor can see .env if it is on disk. The public Netlify site must not inherit private IDs from the private repo. GoDaddy WHOIS and account recovery mail are identity.

Original suggested action: No PHI in coaching docs. No tokens in git. Scrub the public playbook. Prefer local AI (HT Sherpa) for data that cannot leave the machine. .gitignore secrets before opening Composer.

Google DrivePlaudGitHub AppsGitHub BrainNetlifyWispr FlowSpeechifyWhatsAppCursorGoDaddy DNS
Source label A09Source priority: medium

Overreliance / automation bias

A fluent Friday summary can hide a week that did not move. A fluent grant draft can hide a bad fit.

Original suggested action: Human gates at eligibility and submit. Friday starts with wins you can name, not the model’s story.

Human touchgrant
Source label A10Source priority: medium

Misalignment with human intent

Three models read the same Drive. If they do not share a charter, they will coach three different lives.

Original suggested action: Every bot starts from the same GitHub instructions and the same values charter. Never substitute the model’s values.

Grok BotClaudeChatGPT Pro
Original example checklist
  • Least privilege — each agent gets only the tools its role needs.
  • Human-in-the-loop for send, pay, delete, publish, submit.
  • Stopping conditions — max steps, max cost, max time.
  • Audit trail — dated Drive notes + git diffs, kept 90+ days.
  • Firewall plan between local and public agents.
  • Shared values charter in GitHub, cited by every bot.
  • Kill switch — disable the Grok Bot schedules in one place.
  • Inventory connectors twice a year and revoke the rest.
  • Registrar lock on GoDaddy. No agent gets the DNS login.

Choose review frequency, retention, and approval settings for your own context. Local AI, a shared charter, or an ignored Git file does not by itself prevent access to sensitive data.

See the example technology map