Data and security for regulated customers

I'd start by drawing the CJI boundary: which services store, process or send criminal justice data, including GenAI prompts, outputs and logs. Inside that boundary I'd require MFA at AAL2 through the agency's identity provider, customer managed KMS keys per agency so unencrypted CJI is never visible to AWS staff, FIPS endpoints, and private networking with VPC endpoints for Bedrock. Beacon staff with production access need fingerprint background checks and the CJIS Security Addendum, so I'd keep that group small with break-glass access. CloudTrail, Config and Security Hub generate the audit evidence the state CSA will ask for. I'd put CJIS workloads in their own OU with stricter SCPs. Then I'd ask which states they sell to, because each CSA interprets the policy a little differently.

I treat it as an isolation problem. Prompt wording cannot solve it. Every chunk in the index carries a district ID as metadata. The API layer reads the district from the verified login token and applies it as a mandatory retrieval filter, so nothing the user types or the model generates can change it. I'd extend the same scoping to conversation memory, semantic caches, logs and any agent tools, which each run with tenant-scoped credentials. For districts with stricter DPAs, Beacon can offer a dedicated knowledge base. And I'd prove it with automated cross-tenant tests in CI: log in as District A, ask about District B's content, expect nothing.

No. Bedrock doesn't use customer prompts or outputs to train its models, and it doesn't share them with the model providers. Models run in AWS-operated deployment accounts that the model providers can't access. If Beacon fine-tunes a model, that copy is private to Beacon's account and encrypted with Beacon's key. Then I'd point to the evidence: the Bedrock data protection documentation and the compliance reports in Artifact. And I'd remind Beacon that their own promise to districts also covers what Beacon does, such as logging prompts or reusing data for evaluation, so their DPA language should match the architecture.

First, the AI shouldn't make the eligibility decision. It assists a caseworker who decides. For every AI interaction I'd log a record keyed by case ID: who asked, the prompt template version, the model ID and version, the retrieved document IDs and versions, guardrail results, the output, and what the caseworker did with it. The records go to an S3 bucket with Object Lock and a customer managed key, in a separate log account, with retention set to the state's records schedule. The content logs contain PII and possibly FTI, so access is tightly limited and itself logged. That lets an appeal reconstruct exactly what the assistant saw and said on that date.

I'd let requirements decide, per customer. If a contract, a state CJIS office, FedRAMP High, or ITAR requires GovCloud, those customers go there. Everyone else runs in US commercial Regions with SCPs that block non-US Regions, US-only inference profiles, customer managed keys, and private endpoints. GovCloud gets new models and features later, so I'd launch GenAI features in commercial first and release to GovCloud when the models they depend on are available there. The design choice that makes this work is tenant-level "home partition" routing and partition-aware infrastructure code, so moving a customer is a migration, not a rewrite.

The application runs in private subnets with no internet gateway or NAT. It reaches Bedrock through interface VPC endpoints for bedrock-runtime and bedrock-agent-runtime, and S3 through a gateway endpoint. Endpoint policies allow only approved model IDs and Beacon's own buckets. Bucket and key policies add aws:SourceVpce conditions so data can only be read from inside that network. On top of privacy, that removes the easiest exfiltration path for an agent, because there's no route to an attacker's server.

I assume injection will get through, because any text the agent reads, like a caller's note or an uploaded document, can carry instructions. So I put the controls where the model can't talk its way past them. Each tool runs with its own least-privilege role scoped to the current tenant and incident. Read tools and write tools are separate, and anything consequential, like updating a record or sending a message, needs human approval. There's no general internet egress, and outputs go through Guardrails and checks for sensitive data before they leave. Secrets never enter the context window. And I log every tool call with its arguments so we can detect odd patterns. The model is an untrusted user of the tools and sits outside the security boundary.

I'd agree, then narrow it. We pick one use case with clear value and manageable risk, say, a permit Q&A assistant. We inventory only the data it needs, run Macie to find sensitive content, clean and catalog it in Glue, and set access with Lake Formation. That becomes the first slice of the governed lake. The second use case reuses the catalog, the tagging and the pipelines. That way the foundation gets built through shipped features, and the CEO still sees something in production within the two quarters.

Pool, with strong controls, for most of them. Districts are small, the data is sensitive but not CJIS-level, and silo stacks for 150 tenants would slow every release. I'd enforce isolation with tenant context from the token, tenant-scoped credentials, row-level security, and a mandatory district filter on retrieval. I'd offer a premium tier with a dedicated database and knowledge base for large districts or states whose DPAs demand it. The trade-off is cost against blast radius, and I'd put numbers on both for the CEO.

Short term, I'd add per-tenant rate limits and token budgets in Beacon's API layer so no single tenant can take the shared quota. I'd move that county's bulk jobs to Bedrock batch inference or a queue. For the 911 real-time path, I'd separate capacity so public or bulk features can never starve dispatch. Then I'd look at quota increases, cross-Region inference within the US, and provisioned throughput if volume justifies it. And I'd use application inference profiles with cost allocation tags, so Beacon can see that county's cost and price it.

Lake Formation governs access to the lake itself: analysts, Athena, Redshift Spectrum, Glue jobs. It gives column, row and cell-level control with tags, so rules follow the data. But once data is copied into another system, like a vector index or a cache, Lake Formation no longer enforces anything there. So for the GenAI path, I carry the same rules forward as metadata on each chunk and enforce them in the retrieval call from verified tenant context. Both layers should come from the same tags, so policy is defined once.

With architecture plus evidence. Bedrock doesn't train on customer data, so the base model is covered. For Beacon's own actions, there are no fine-tuning jobs on student data, enforced by an SCP or IAM policy that denies model customization in the K12 accounts, which is visible in CloudTrail. RAG keeps student data in the district's partition of the index, where it can be deleted. Retention and deletion jobs cover source data, embeddings and logs. Beacon can hand the district that control list and the matching Config and CloudTrail evidence.

For S3, I'd turn on Macie automated discovery across the organization and send findings to Security Hub. For data in motion through the GenAI path, Bedrock Guardrails sensitive information filters or Comprehend can detect and mask PII in prompts and responses. For the lake, PII columns get Lake Formation tags so they're masked by default. And I'd check the places teams forget: invocation logs, debugging exports, vector stores and caches.

FTI brings IRS Publication 1075 with it, on top of the state's own rules. The cloud services must be FedRAMP authorized, FTI must stay in the US with no offshore access, and the state agency notifies the IRS before moving FTI to a cloud or contractor. Architecturally, I'd isolate FTI in its own data store with its own key and access role, and minimize it. The AI assistant should see a derived field like "income verified" rather than the raw tax data. That keeps the Pub 1075 boundary small and easy to defend. I'd have Beacon confirm details with the state's safeguards team, since they own that relationship with the IRS.

I scope it to the one workload that's about to ship, the GenAI assistant, and use the Generative AI and SaaS lenses. Two short sessions with the tech lead and security lead, not a questionnaire marathon. I frame it as finding what would block their customers' security reviews before the customers find it. The output is the top five high-risk issues, each with an owner and a date, and a re-review before GA. Fast teams accept that because it removes launch risk instead of adding process.

I'd be direct: AWS gives them infrastructure that supports CJIS, signed addendums with many states, and the controls they need, but compliance is determined by their state CSA and depends on how they build and operate. I'd walk through the shared responsibility split for CJIS: AWS covers the physical and infrastructure controls, and Beacon covers identity, encryption with its own keys, personnel screening for its staff, logging and incident response. Then I'd offer to review their architecture against the controls that fall on them. I wouldn't give a yes or no that sounds like legal advice.

It sits inside the same security boundary as the source data, with the same encryption and access rules, because embeddings and chunks are a copy of that data. For choice: if Beacon wants the least to manage, Bedrock Knowledge Bases with a managed store. If they already run Postgres, Aurora pgvector keeps it in a familiar database with row-level security. If they need hybrid keyword and semantic search at scale, like evidence search, OpenSearch. I'd also check what's available in GovCloud for customers there, and make sure deletion jobs reach the vector store.

I'd give each of those tenants its own customer managed KMS key and use it for their database, S3 data, knowledge base and logs. Key policies allow only Beacon's service roles for that tenant, and every decrypt is in CloudTrail, which the county can review. If they want to be able to cut Beacon off, the key can live in a key store they control, at some cost in latency and availability. On contract exit, deleting the key makes all their data, including embeddings, unreadable. I'd reserve this for silo or bridge tenants, because per-tenant keys add management work in a pooled design.

The audio is CJI, so it stays in the CJIS boundary. Recordings land in S3 with Object Lock and a per-agency key, and the original is never altered. Transcribe produces a transcript with custom vocabulary for local street names and unit codes, and PII redaction where the agency wants it. A Bedrock model drafts an incident summary from the transcript and CAD events, and the officer or dispatcher reviews and signs it. The summary links to the source audio and transcript by ID and hash, so the chain of custody is intact and the AI draft is never mistaken for the evidence.