9.7 Security and Governance Case Lab

Case: governed support assistant

Imagine a software company wants an internal support assistant. The first phase should answer employee questions from approved troubleshooting articles. The second phase may summarize recent support cases. The third phase may create draft support tickets or suggest routing. The business goal is reasonable, but the risk changes at each phase. A read-only FAQ assistant is not the same as an agent that touches customer records.

The proposed AWS pattern uses Amazon Bedrock for model access, Amazon S3 as a source for approved articles, a Knowledge Base for retrieval, Guardrails for Amazon Bedrock for content and sensitive data controls, IAM roles for runtime access, CloudTrail for API activity, CloudWatch for logs and metrics, AWS Config for configuration monitoring, Macie for S3 sensitive data discovery, and AWS Budgets for cost alerts. That is a service map, not yet a governance plan.

Start with use-case fit. The assistant can help if employees ask repetitive support questions and accepted answers can be grounded in approved articles. AI may not be appropriate for final legal, safety, or disciplinary decisions without human review. If the team cannot define success, such as reduced handle time, better search satisfaction, or fewer duplicate tickets, it is too early to approve production.

Next review the data. The S3 bucket should contain only approved troubleshooting articles for phase one. Macie findings should be reviewed before indexing to catch sensitive customer data, credentials, or personal information that does not belong in the knowledge base. The support content owner should define how articles are updated, retired, and removed from the index. Old or conflicting documents should not be treated as harmless because they are internal.

IAM and authorization decide the real blast radius. The application role should invoke only approved Bedrock models and read only the approved knowledge base or S3 paths. End users should retrieve only content they are allowed to see. Administrators who manage model access, guardrails, and logging should not share the same broad credentials with application runtime roles. If phase three adds ticket creation, that action should use a narrow role and a defined API.

Privacy decisions should be explicit. If support case summaries include customer names, account IDs, or incident details, the team should decide whether those fields are required. Redaction may be needed before prompts are sent. Logs should be configured so prompt and response content is not retained longer than policy allows. Encryption should cover source data, logs, generated summaries, and any stored outputs.

Threat modeling should include prompt injection. A troubleshooting article, support case, or user prompt might try to tell the assistant to ignore policy or reveal hidden instructions. The design should separate control instructions from untrusted content, use Guardrails where appropriate, test adversarial prompts, and avoid exposing secrets or broad tool permissions to the model. If an agent can create tickets, users should confirm submission before the action is taken.

Monitoring should be practical. CloudTrail can show AWS API activity, including changes to IAM, S3, Lambda, or Bedrock resources. CloudWatch can track application errors, latency, blocked events, and downstream failures. AWS Config can monitor configuration drift for important resources. A useful runbook explains who receives alarms, how to trace a bad answer, and when to disable the assistant or remove a source document.

Compliance evidence should match the risk. For phase one, evidence may include approved source list, IAM policy review, Macie results, guardrail configuration, CloudTrail status, log retention, and budget alerts. For phase three, evidence should also include action schema, confirmation behavior, ticket audit logs, user authorization, and exception handling. AWS Artifact can support provider assurance review, but it does not replace evidence about this specific workload.

Cost governance should be decided before launch. The team should estimate request volume, average prompt size, retrieved context length, output length, model choice, vector storage, logs, and Lambda calls. AWS Budgets should notify the owner when spend crosses thresholds. If adoption grows, the team may evaluate smaller models, shorter prompts, caching, batch summaries, or provisioned throughput. Cost surprises are usually a sign that usage assumptions were not monitored.

Case lab deliverables:

1. One-page use-case approval with success metric and human review boundary.
2. Data inventory listing approved sources, classification, owner, update cadence, and Macie review status.
3. IAM map showing human users, runtime role, service roles, model access, and action permissions.
4. Privacy decision record for prompt content, logs, retention, encryption, and Region use.
5. Threat model summary covering prompt injection, data exfiltration, tool misuse, and unsafe outputs.
6. Monitoring plan using CloudTrail, CloudWatch, AWS Config, and service-specific events.
7. Compliance and cost plan with evidence owners, AWS Budgets, tags, and review cadence.

This is the posture AIF-C01 rewards. You are not expected to implement every control in code. You are expected to notice when a proposed AI solution has no data owner, no least privilege story, no prompt-injection testing, no monitoring, no evidence plan, and no budget alert. The practitioner value is turning an AI demo into an accountable business system.