Stop 1 of 10 · Set once
Guardrails first
The four categories that never reach a chat, an account Project that holds no account data, and one write guardrail that governs every connector, script and CLI in this course.
Every other stop in this course sends something to Claude
Fadi covers state and local agencies for a major cloud vendor: county governments, school districts, a transit authority, a sheriff's office. One RFP response can carry a network topology, a records extract, a private price list and a directory sync key. None of those is a mistake you fix in the next draft.
This stop decides what travels. It governs the other nine.
The four categories
| Category | What it covers on Fadi's accounts |
|---|---|
| Customer data | Any record from a customer system: student rosters, case files, vital records, permit tables, a sample "just to check the schema" |
| Credentials | Access keys, connection strings, certificates, tokens, the directory sync account, anything at all from a password manager |
| Unreleased pricing | Private pricing, negotiated discounts, programme funds, deal desk positions, any service or rate that is not on the public page |
| Customer network detail | Address ranges, subnet plans, firewall rules, device hostnames, account and subscription identifiers, connectivity endpoints |
The fourth is the one architects argue about, because the design seems to need it. It does not. Schema travels; values do not. Eleven columns, one a national identifier, forty million rows, read-heavy: enough to design against. Forty rows of it is a breach.
The account Project holds no account data
One Project per account, filled from a template, holding only standing facts a public records request could already reach: the agency mission, the programme, the compliance frame, the stakeholders by role, the deal stage in one word. Never the tenancy, never the topology, never the price. Here is the set Fadi fills per account.
You are supporting me on a public-sector cloud account. I am an enterprise cloud architect, not a salesperson. Account: Calverton County, a mid-size county government. Programme: retiring an on-premises records platform onto managed database and object storage. Frame: CJIS Security Policy for the sheriff's office workloads, StateRAMP for the rest. Stakeholders by role: county CIO, records division director, a database team of three, an incumbent integrator. Data rules. I describe systems by role, volume and schema shape, never by hostname, address range, account identifier or record content. If I paste anything resembling customer data, a credential or non-public pricing, stop and say so before answering. How to answer. Every claim about a service capability, quota or control carries the document you read it in. With no source, write NOT VERIFIED on that line rather than a confident sentence. Separate what the platform provides from what the customer implements. Give alternatives with the trade named. Pricing. You never state a price, a discount or a rate. You state the metered dimension and the lever, and I fill the number from the public calculator.
One write guardrail, everywhere
This course connects Claude to a repository, a documentation store and a cloud account. The same three rules cover all of them, and they are not negotiable per tool.
- Read-only first. Every connector and script starts as reads, and earns writes by being right, checked against the console, for a month.
- Plan before apply. No infrastructure change without a printed plan Fadi reads line by line. The plan is the artefact; the apply is the formality.
- Sandbox only. What Claude generates runs in Fadi's own sandbox account, with a budget alarm and a policy boundary. Never a customer account, never a shared demo account.
I am the cloud architect on a public-sector team covering state and local agencies. Turn the three rules below into a one-page guardrail card my six colleagues can actually follow: read-only connectors first, plan before apply, sandbox account only. For each rule give me the rule in one sentence, the two most common ways a busy architect breaks it, and the check that catches the break before it costs anything. Finish with what to do in the ten minutes after customer data reaches a chat.