Chapter 14: Security and Trust — Building Inside the Guardrails

Picture Vanessa Crowder, the Chief Marketing Officer of a $620-million regional wealth-management firm based in Hartford. It is a Tuesday afternoon in March. She is sitting in a conference room with her firm’s Chief Information Security Officer, Daniel Park, and the lead auditor from a Big Four accounting firm. The auditor has a single page in front of him. He slides it across the table.

The page is a summary of forensic findings. For the past three months, members of Vanessa’s marketing team — six people, every one of them a high performer with the firm for at least four years — have been pasting client portfolio data into the free consumer version of ChatGPT. Names. Account values. Performance returns. They have been doing it to generate first drafts of client-facing performance commentary. The drafts came back faster and cleaner than what their in-house copywriters could produce. Adoption was unanimous. Productivity went up. No one told the security team because no one thought to.

The auditor’s page does not need to be read twice. Under the terms of the firm’s consumer-tier ChatGPT usage, that data became part of the training corpus. It is now, in effect, in the model. The firm is required to notify its clients. It will need to notify its regulator. Vanessa watches the number on the bottom of the page — the auditor’s estimate of remediation cost — and feels the floor of her career tilt.

There were no bad actors. No phishing email. No insider threat. Just six smart people, a useful tool, and a culture that had never sat them down for the fifteen-minute conversation that would have prevented all of it.

This chapter is about preventing that scenario.

The Security Posture — Four Questions Before You Deploy Anything¶

Here is the analogy worth holding onto for the rest of this chapter. Think about hiring a brilliant new employee on her first day. She is talented. She is going to be a force multiplier. You give her a laptop. You give her email. You give her access to the systems she needs to do her job.

You do not follow her around watching everything she touches. That would be insulting, exhausting, and ineffective. Instead, you do four other things. You define what she can and cannot access. You write down — or inherit — clear policies about how data is handled at your company. You sign an NDA. You build a culture where she knows what is appropriate and what is not.

Once those four things are in place, you trust her to do her job. Not because trust is naïve. Because the guardrails are doing the work that watching her would have done — only better, more consistently, and without burning out either of you.

AI security is the same.

You do not need to audit every prompt. You need to set up the guardrails once and then let the work happen inside them. The mistake almost every business makes in their first year of AI adoption is to try to do this in reverse — to deploy fast, then bolt on security after a near-miss. Do it the right way around. Set the rules first. Then move fast inside them.

The starting place is four questions. Before you deploy any AI tool to your team — and especially before you let it touch client data, financial information, or proprietary work — you need clear, written answers to these four questions:

1. Where does my data go? What jurisdictions does the vendor process it in? Does it leave your country? Does it leave your network at all?

2. How long is it retained? Days? Thirty days? Indefinitely? Until you ask for deletion?

3. Who can see it? Just the model? The vendor’s employees? The vendor’s contractors? A subprocessor in another country?

4. What happens if it leaks? What is the vendor’s incident-response process? What is your contractual recourse? What is your obligation to notify your clients or your regulator?

These four questions are not a checklist for the IT team. They are a checklist for you — the operator, the leader, the executive who is going to be answering for the choice the day the auditor walks in.

The reason this matters is not abstract. In 2024 alone, multiple Fortune 500 firms quietly issued internal directives banning consumer-tier AI tools after discovering that engineering, legal, and HR teams had been routing confidential information through them. Samsung famously did this in 2023 after engineers pasted proprietary source code into ChatGPT and the company realized it had no way to retrieve it. These were not exotic security failures. They were ordinary failures of organizational hygiene — a useful tool deployed faster than the policies that should have surrounded it. The companies that get this right do not move slower than their competitors. They move at the same speed, but with a single page of answers to four questions sitting in a folder where the auditor can find it.

There is a related point worth making explicitly. The four questions apply to every tool, not just the obvious ones. The chatbot in your marketing automation platform. The AI writing assistant in your email client. The transcription service your sales team is using. The meeting-notes tool somebody installed last Thursday because it had a fourteen-day free trial. Each of these is an AI tool. Each of them sees your data. Each of them needs the four-question test before it earns a place in your stack. If you do not maintain a list of which tools you have approved and which you have not, you do not have a security posture — you have whatever your most aggressive individual employee decided to install this week.

Data Usage — What the Model Sees¶

Here is the single most important distinction in this entire chapter, and the one most professionals have never been told.

Consumer AI products and enterprise AI products often run on the exact same underlying model. The pricing is different. The packaging is different. But the model is, in many cases, identical. What is not identical — what is in fact the entire point of the enterprise product — is the contract that surrounds it.

In the consumer version of most AI tools, your prompts are typically used to improve the model. That is the bargain. The product is offered at low cost or no cost, and in exchange, the work you do with it becomes part of the training data that makes the next version better. This is not malicious. It is the basic economic logic of consumer software, and it is disclosed in the terms of service that almost no one reads.

In the enterprise version, that bargain is reversed. You pay for the product. Your data is, by contract, not used for training. It is not retained beyond what is required to deliver the service. It does not leak across customers. It does not show up in the next model. The enterprise tier exists, in large part, to make this guarantee.

Why does this matter so much for business users? Because the moment your team is producing work that touches client information, trade secrets, internal strategy, or anything regulated, the question of “is this data being used to train a model” stops being abstract. It becomes the question that determines whether your firm is in compliance with its own promises to its clients and its regulators.

Think back to Vanessa Crowder’s marketing team. The actual mechanical work they were doing — generating draft performance commentary from client portfolio data — was the same work the firm’s enterprise tools could have done. The only difference was the contractual wrapper around the conversation. On the consumer tier, that data fed the model. On the enterprise tier, with the right agreement in place, it would not have. Same model. Same prompts. Same outputs. Catastrophically different consequences.

The implications run deep in regulated industries. A law firm whose paralegals use consumer tools to draft client correspondence is creating a privilege problem. A healthcare provider whose nurses use a consumer transcription app to summarize patient notes is creating a HIPAA problem. A financial advisor whose team uses consumer tools to analyze portfolio holdings is creating an SEC problem. None of these professionals intend to violate anything. They are using a tool that helps them work better. The failure is upstream — at the level of the firm that never told them which tier to use and never gave them a sanctioned alternative.

The fix is straightforward in concept and demanding in execution. Every business that takes AI seriously needs to maintain a short, plain-English list of which tools are approved for which kinds of work. Drafting an internal memo? Any approved tool. Drafting a client-facing document? Enterprise tier only, named in the list. Working with regulated data? Specific tool, specific configuration, specific approval. The list does not need to be long. It needs to be unambiguous, easy to find, and updated when the world changes. The single largest reason teams default to whatever tool they find on their own is that nobody told them which tool to use. The list closes that gap.

A useful test, for any individual employee, is what some firms call the “screenshot test.” Before you paste anything into an AI tool, ask yourself: would I be comfortable if someone took a screenshot of this prompt and posted it on the public internet tomorrow? If the answer is yes, the consumer tier is fine. If the answer is no, you need a tool with an enterprise contract behind it. The test is not technical. It is intuitive. And it gets the right answer in about three seconds.

Zero Data Retention — The Contractual Layer¶

Zero Data Retention — usually abbreviated ZDR — is the contractual term that most directly answers question two of the four: how long is my data retained?

In its purest form, the answer under a ZDR agreement is: zero. The vendor processes your prompt and your data only long enough to generate a response. The moment the response is delivered, the data is discarded. Nothing is logged. Nothing is stored. Nothing is used for training. Nothing survives the request.

This sounds technical. It is, in practice, the single most important contractual concept business leaders need to understand in their dealings with AI vendors. Here is why.

Without ZDR, even an enterprise-tier AI vendor typically retains your prompts and outputs for some period — commonly thirty days — to support things like abuse monitoring, debugging, and customer support. That retention is reasonable. It is the standard operating model for most cloud software. But for some industries, even thirty days of retention by an external vendor is unacceptable. A defense contractor cannot have its design discussions sitting on a third party’s servers for thirty days. A health system cannot have patient-record fragments accessible to a vendor’s support team for any window of time. A law firm cannot have privileged client communications retained anywhere outside the firm’s own control.

ZDR is the mechanism that resolves this. By contract — not by promise — the vendor agrees that your prompts and outputs are not retained. The technical implementation is configured to enforce this. The audit trail is structured to prove it. When the auditor or the regulator asks where your data lives, the answer is: nowhere outside the moment of the request.

The three major frontier AI vendors all offer ZDR as a contractual option for enterprise customers, though the specifics differ in ways that matter.

The detail to internalize is not the specific vendor offerings — those will evolve. The detail to internalize is that ZDR is a thing you can ask for, by name, in a contract negotiation, and that the vendors that take enterprise customers seriously have a path to providing it.

The mid-market healthcare company Wellfront Specialty Clinics, a chain of ninety-two outpatient cardiology clinics across the Mid-Atlantic, learned this lesson the hard way during their AI rollout. Their first attempt was to deploy a popular consumer-tier AI scribe tool to help cardiologists generate visit notes faster. The pilot saved each physician an estimated forty-five minutes a day. The pilot also, when reviewed by the compliance team three weeks in, was determined to be a clear HIPAA violation: patient encounter data was being processed and retained outside the firm’s BAA-covered vendor list. Wellfront stopped the pilot, spent two months evaluating enterprise alternatives, and ultimately landed on a vendor that offered a ZDR configuration plus a Business Associate Agreement that covered the entire workflow. The productivity gains were preserved. The compliance risk was eliminated. The total delay was about ten weeks — a fraction of what the alternative would have cost the firm if the issue had been discovered by an external auditor rather than an internal one.

The lesson Wellfront drew from the experience was the one this section is making. ZDR is not a luxury for the most paranoid customers. It is a standard tool of enterprise AI procurement, and it should be on the checklist for every deployment that touches anything sensitive. Ask for it. Get it in writing. Move on.

Building Inside the Guardrails — Four Operational Practices¶

Contracts and configurations are necessary but not sufficient. The day-to-day safety of an AI deployment is determined by four operational practices that the team actually follows. Get all four right and your security posture becomes durable. Skip any one of them and your other three start to compensate for the gap until they cannot anymore.

Practice one: principle of least privilege. Give each AI tool — and each user of each AI tool — access only to the data and systems they actually need to do their work. Not more. The instinct of new deployments is to wire up the AI with broad permissions because narrowing them feels like extra work. It is extra work. It is also the single most consequential thing you can do to limit the damage of any future mistake. The marketing AI does not need access to the financial planning models. The sales AI does not need access to the HR records. The customer-support AI does not need access to the merger documents in the executive folder. Scope each tool to exactly what its job requires and revisit those scopes quarterly.

Practice two: separation of test and production environments. When you are experimenting with a new AI workflow — a new prompt, a new automation, a new connection between two systems — do that experimentation in an environment that does not touch real client data, real financial records, or real production systems. Use synthetic data. Use a dummy account. Use a sandbox. Once the workflow is proven, promote it into production with a deliberate handoff. This separation is the difference between a useful experiment that taught you something and an experiment that becomes an incident report. Every mature engineering organization runs this way. AI deployments need to run the same way, even though the tools feel low-friction enough to make the discipline feel unnecessary.

Practice three: audit trails. Every consequential AI action in your business should be logged. Who initiated it. When it happened. What data was touched. What output was produced. What downstream action was triggered. This is not paranoia. It is the basic infrastructure of accountability. When something goes wrong — and over a long enough time horizon, something always goes wrong — the audit trail is what lets you understand what happened, contain the damage, notify the right people, and improve the system. Without it, you are reconstructing events from memory in a room full of frightened people, which is not where you want to be making important decisions.

Practice four: the human approval gate for high-stakes actions. Any AI action that has irreversible or high-consequence effects — sending a client-facing email, executing a financial transaction, modifying a legal document, posting to a public channel, deleting production data — should require explicit human approval before it fires. This is not because the AI is untrustworthy. It is because the asymmetry between the cost of a wrong action and the cost of waiting two minutes for a human review is enormous, and the right place to absorb that asymmetry is at the moment of the action, not in the cleanup afterwards. Set the threshold for what counts as “high-stakes” deliberately and write it down. The thoughtful default for most businesses is that anything client-facing, anything financial, and anything legally binding requires a human signature before it leaves the organization.

The pattern across the firms that get this right is the same. They do not invent exotic security architectures for AI. They apply the same operational disciplines they have always applied to systems that touch sensitive data — the same disciplines the IT and security teams have been refining for thirty years — and they apply them to AI tools with the same rigor. There is nothing mysterious about AI security. There is only the willingness to treat AI deployments as the consequential infrastructure they are, rather than as a productivity novelty that someone installed.

A useful framing: imagine that every AI workflow in your business is going to be examined six months from now by an external auditor who has never met you and has no interest in your good intentions. The auditor will ask three questions. Who had access to what? How do you know what happened? Who approved the things that mattered? If your answer to each of those three questions is short, clear, and supported by evidence you can produce on demand, you are running your AI deployment well. If your answers are long, fuzzy, and rely on what people remember, you are running it badly. The discipline is to keep your future self ready for that conversation.

The Cultural Layer — Why the Fifteen-Minute Briefing Matters¶

Here is the uncomfortable truth this chapter has to deliver. None of the contractual or operational work in the previous sections matters if the people in your business do not know it exists.

Every major AI security incident at a real business in the last three years has had the same shape. A capable, motivated employee found a useful tool, used it well, and exposed the firm to a risk no one ever explained to them. The IT team had a policy. The security team had a document. The compliance team had a quarterly briefing slide. None of those artifacts made it to the moment when the person in front of the keyboard had to make a decision about whether to paste the client portfolio data into the chat box.

The fix is so simple that businesses routinely skip it. It is a fifteen-minute conversation, delivered to every employee, that covers exactly five things:

1. Here are the approved tools — and a short list of which to use for which kind of work.

2. Here is what data is sensitive — in plain language, with examples relevant to this employee’s actual job.

3. Here is the screenshot test — before you paste anything into any AI tool, ask yourself whether you would be comfortable seeing it on the public internet tomorrow.

4. Here is who to ask — a specific named person or channel for the moments when an employee is not sure what to do.

5. Here is what happens if you are not sure and you do it anyway — the firm’s incident-reporting process, framed as a way to surface mistakes early rather than as a way to punish them.

Fifteen minutes. One page. A small follow-up email a week later. That is the entire intervention. The leverage of it is enormous.

The reason this works is psychological. Most employees, given clear rules, will follow them. Given unclear rules, they will improvise. Given no rules, they will use whatever tool helps them get their work done — and they will not feel guilty about it, because nobody ever told them they should. The fifteen-minute briefing converts the ambiguous situation into a clear one. After the briefing, the team member who would have pasted the portfolio data into ChatGPT now has a moment of pause, remembers the screenshot test, and uses the approved tool instead. The same intelligence. The same productivity. None of the catastrophic exposure.

The mid-sized accounting firm Pearlman & Strauss LLP in Minneapolis ran exactly this briefing in early 2024 after a near-miss with a junior tax associate who had been using a consumer AI tool to draft client-facing tax letters. They built a single-page handout — five rules, large type, no jargon — and walked every employee through it in ninety days. Twelve months later, the firm’s compliance officer reported that the firm had moved from “no idea what tools the team was using” to “every team member can name the firm’s three approved tools and can articulate the screenshot test from memory.” The firm had also seen a small but real increase in the volume of incident reports — which was not a bad thing, because the increase came from employees flagging their own uncertainty before taking an action, exactly the behavior the briefing was designed to produce.

The cultural layer is the multiplier on everything else in this chapter. Without it, your contracts and your operational practices are paper. With it, they become the lived reality of how your business actually runs.

The Trust Compound — Why Security Pays Back¶

There is one more idea this chapter needs to leave you with, and it is the idea that pulls everything else together.

Security work feels, in the short run, like overhead. It feels like the thing slowing you down while your competitors race ahead with their consumer-tier tools and their no-policy approach. In the first month, sometimes the first quarter, that feeling is sometimes even accurate. The team that invested in contracts and configurations and briefings will be visibly slower than the team that just installed the tool and went.

Then the curves cross.

The team that did the work has now built something they can trust. Their clients can be told, in writing, exactly how their data is handled. Their regulators can be answered, in writing, on the first request. Their auditors can be given, in writing, evidence of every consequential AI action in the last year. None of these things are events. They are properties of the system the team built. Every new AI deployment after the first one inherits them. Every new employee joins a culture where the rules are already legible. Every new client gains confidence from the simple fact that the firm has its act together.

The team that skipped the work, meanwhile, is doing fine — right up until they are not. The near-miss becomes a real miss. The shortcut becomes an incident. The lack of audit trails becomes the central problem in a tense meeting with a regulator. The recovery from any of these events consumes more time, money, and credibility than the entire security investment would have cost in the first place. And after the recovery, the team has to do the work anyway, under duress, while the brand bleeds.

This is the trust compound. It looks like the technical-debt curve from software engineering, because it is the same curve. Pay early or pay much, much more later. The teams that internalize this and choose to pay early do not just avoid incidents. They unlock a kind of organizational speed that the ad-hoc teams cannot match. They can sign client contracts that the ad-hoc teams cannot. They can enter regulated markets that the ad-hoc teams cannot. They can adopt new AI capabilities faster because the underlying governance is already in place. The guardrails do not slow them down. The guardrails are the thing letting them go fast safely.

Come back to Vanessa Crowder in the conference room in Hartford. The cost on the bottom of the auditor’s page is not just the remediation. It is the eighteen months of distraction that will follow — the depositions, the client conversations, the regulator filings, the rebuild of internal processes that should have existed all along. By the time her firm finishes that work, the competitor down the street that took six months to set up its AI rollout the right way will have shipped three years of accumulated capability. Vanessa’s firm will catch up. It always does. But the lead time her competitor built was paid for, in advance, in the form of contracts read and briefings delivered and audit trails configured. None of that work was glamorous. All of it compounded.

The chapter has been pragmatic throughout, so let it end pragmatically. You will not build perfect AI security. No one does. What you will build, if you do this work well, is a system you can stand behind — to your clients, your regulators, your team, and yourself. That is the goal. Not perfection. Just a system you can defend on its worst day, and a culture that knows why the rules exist on every other day.

Set the guardrails. Then trust the system you built. That is the whole job.

Case Study: A Near-Miss at Halcyon Federal Credit Union¶

Background¶

Halcyon Federal Credit Union is a $3.1-billion regional credit union headquartered in Spokane, Washington, with thirty-one branches across the Pacific Northwest and approximately 410,000 members. Founded in 1957 to serve aerospace workers, Halcyon has grown into a full-service financial institution with a notably tech-forward reputation among credit unions of its size — it was the first credit union in its region to offer instant-issue debit cards, the first to deploy a fully digital mortgage application flow, and one of the first to launch a member-facing AI chatbot for routine account questions. Its Chief Information Security Officer, Marisol Renteria, joined the firm in 2021 after eleven years at a large national bank, and she had built a security organization that the firm’s board explicitly considered one of its competitive assets.

In the spring of 2024, Halcyon’s Chief Operating Officer, Devin Yost, authorized a six-month internal experiment to evaluate generative AI tools across three departments: member services, lending operations, and marketing. The pilot was structured carefully — each department received a list of three pre-approved enterprise-tier tools, a one-page briefing on data handling, and a single point of contact in Marisol’s organization for any questions. The pilot ran for five months without incident. In month six, a quarterly internal audit surfaced a finding that would test every part of the firm’s security posture.

The Situation¶

The finding was specific. A team lead in lending operations — a sixteen-year Halcyon employee with an unblemished record — had been using a free, consumer-tier AI tool to help draft denial letters for declined loan applications. She had not been told she could not. The pre-approved tools list had focused on member services and marketing; lending operations had been mentioned only in passing during the briefing, and the team lead had reasoned that since her work product (the denial letters) was not member-facing data but her own writing, the consumer tool was acceptable. Over the course of seven weeks, she had pasted approximately 340 partial loan application records into the tool — names, loan amounts, declined-reason codes, and credit context — to get faster first drafts. The drafts were excellent. None of the letters that went to members contained AI-generated errors. The work product was unimpeachable. The data exposure, however, was real: that information was now in a consumer vendor’s training corpus, with no contractual mechanism for retrieval or deletion.

Marisol’s team treated the finding as a near-miss rather than an incident — no member had been harmed, no regulatory threshold had been crossed, and the data exposure, while real, was bounded and traceable. Devin Yost, however, faced a harder question. The firm’s existing controls had failed in a specific way: not because the rules were unclear, but because the rules had not anticipated the exact kind of work the team lead was doing. The team lead had acted in good faith, made a defensible interpretation, and exposed the firm anyway. The board’s audit committee, briefed the following week, wanted to know three things. First, what change to the firm’s controls would prevent the next variation of this scenario? Second, how would the firm assure itself that no other version of this exposure was happening, undiscovered, in other departments right now? Third, what was the right cultural response — punishment, training, restructuring, all three, or none — for an employee who had done diligent work that nonetheless created risk? The committee gave Yost thirty days to come back with a plan.

Discussion Prompt¶

Using the four-question security framework from this chapter (where the data goes, how long it is retained, who can see it, and what happens if it leaks), evaluate where Halcyon’s controls actually failed in the lending-operations near-miss, distinguishing failures at the contractual layer from failures at the operational and cultural layers. What specific changes to the firm’s pre-approved tools list, briefing materials, and ongoing audit cadence would close the gap that allowed this scenario to develop? Then consider the cultural question Devin Yost must answer for the board: how should the firm respond to an employee who acted in good faith but created risk, and what would a response that strengthens future reporting (rather than suppressing it) actually look like in practice?

Discussion Guidelines¶

Initial Post (due before class)

• Minimum 400 words

• Directly address the discussion prompt using concepts from this chapter

• Include at least one APA-formatted citation — from the course text or a peer-reviewed source

• Avoid summary; demonstrate analysis and original thinking

Peer Responses (minimum 2)

• Minimum 250 words each

• Each response must include at least one APA-formatted citation

• Engage substantively — build on, challenge, or offer a contrasting perspective grounded in evidence

• “I agree” or “Great post” responses do not meet the requirement

• Maintain a professional and respectful academic tone

Applied Exercise: Build Your AI Security Posture in 30 Minutes¶

Estimated time: 25–30 minutes. You’ll produce a one-page security posture document — a list of approved tools, the four questions answered for each, and a draft of the fifteen-minute employee briefing — that you can hand to your team next week.

The goal of this exercise is not to design a perfect security program. The goal is to produce the artifact that closes the largest gap most businesses have today: a single page that any employee can read and understand. Both tracks below use AI to help you do the analysis. They differ in how the work feels.

Before starting either track, if you have never used Claude Code before, work through the official quickstart at https://code.claude.com/docs/en/quickstart. It is the recommended starting point and will get you to a working session in about ten minutes.

Track A — Claude Desktop¶

Estimated time: under 10 minutes. A single conversation. No tools, no installs.

This is the business-friendly default. You will do the security audit and draft the team briefing as a plain conversation — the same artifacts Tracks A and B produce, just pulled out of a chat window instead of an agent run.

1. Open Claude Desktop (download from claude.ai/download) or use claude.ai in your browser.

2. Describe your current AI usage honestly. Which tools does your team actually use (ChatGPT, Claude, Copilot, Gemini, Perplexity, niche vertical tools)? What kinds of data get pasted in (client names, contracts, financials, code, HR data)? Which subscriptions are consumer tier and which are enterprise or business with a data-protection agreement? Do not sanitize the picture — the audit only works if the inputs are true.

3. Ask Claude: “Based on what I’ve described, what are my top three security risks and what should I do about each?” Read the answer carefully. Push back if anything feels off.

4. Ask a follow-up: “Draft a 15-minute briefing I could give my team about responsible AI use, based on the risks you just identified.”

5. Save both outputs to a single doc. That document IS the security posture and the cultural layer from this chapter. Send the briefing to your team this week.

Your Submission: Your submission is all three artifacts Claude produced from your security audit: the approved-tools list with the four security questions answered for each tool, the 15-minute team briefing, and the ranked risk gaps list. Copy all three into one document. Write two sentences: (1) which risk gap surprised you most and what will you do about it in the next two weeks, and (2) who on your team most needs to read the 15-minute briefing? Submit the three artifacts + two sentences.

Track B — Claude Code¶

1. In your Claude Code session, paste the following structured prompt: “I am the [your role] at a [size and industry] company. Help me audit our current AI usage. Ask me one question at a time about which AI tools my team uses, what kind of data each tool touches, and what tier (consumer or enterprise) we are on. After you have a complete picture, produce three artifacts for me: (1) a list of our current AI tools with the four security questions answered for each, (2) a draft of a fifteen-minute employee briefing in one page, and (3) a list of the highest-risk gaps in our current setup, ranked.”

2. Answer Claude’s questions honestly. The value of the exercise comes from the accuracy of your answers, not from looking good. If your team is using consumer tools, say so. If you do not know how a vendor handles data retention, say that too.

3. Review the three artifacts Claude produces. For the security questions you cannot answer for a given tool, take that as your action list — those are the vendors you need to contact for clarification this week.

4. For the fifteen-minute briefing draft, edit it for your firm’s voice and your team’s specific examples. The generic version will be eighty percent right; your edits make it land for your people.

5. Save the final document to a file named ai-security-posture.md. Schedule the briefing for the next team meeting. The artifact is the deliverable; the briefing is the activation.

Your Submission: Your submission is the same three artifacts Claude Code produced — approved-tools list, team briefing, and risk gaps — plus a personal action plan you write yourself: three specific changes you will make to your team’s AI usage within 30 days, each with a deadline. Copy everything into one document. Submit the three artifacts + personal action plan.

Track C — Antigravity 2.0 IDE¶

1. Open Antigravity 2.0 IDE. Press CMD+E (Mac) or CTRL+E (Windows) to switch to the Agent Manager surface — the no-code orchestration view that is the business-user entry point. Reference the IDE overview at https://antigravity.google/docs/ide-overview if you need orientation.

2. Before starting a new task, take a moment to review which Projects in the Agent Manager have which data access permissions. Antigravity organizes work at the project level, and each project can be scoped to specific data sources. This itself is a useful audit — note any project that has broader permissions than it actually needs for its current work.

3. Start a new task with the same structured prompt from Track A’s step 1, adapted for the Antigravity surface: “Audit my team’s current AI usage and produce a one-page security posture document. Ask me one question at a time. When you are done, produce three artifacts: an approved-tools list, a fifteen-minute briefing, and a ranked list of the highest-risk gaps.” Scope the task to a project with appropriate data permissions for this kind of sensitive review.

4. Watch the agent work asynchronously. The Agent Manager will produce artifacts as the work progresses — markdown drafts, comparison tables, and the final one-page document. Review each artifact as it appears and provide feedback.

5. Save the final artifacts to the project. Note for yourself: which surface did you find easier to think alongside? Which produced the briefing document you actually want to hand to your team?

Your Submission: Your submission is the three artifacts the Antigravity agent produced — approved-tools list, team briefing, and risk gaps list — plus one paragraph (100-150 words) you write describing your current security posture honestly, not aspirationally, and identifying your single highest-priority gap. Submit the three artifacts + one paragraph.

Reflection¶

Write two to three sentences capturing what you noticed about your own firm’s security posture during the audit. Where were you confident? Where were you uncertain? What is the single most important action — concrete, specific, doable in the next week — that this exercise made obvious to you?

The deeper lesson of this exercise is not the document itself. It is what happens when you sit down to write the document and discover, often for the first time, what you do and do not actually know about your own firm’s AI usage. That moment of clarity is the beginning of a real security posture. Everything after it is execution.