Amazon AWS AIF-C01: Security and Governance

Security, compliance, and governance make up a distinct domain of the Amazon AWS AIF-C01 exam because AI solutions introduce new data flows without replacing ordinary cloud-security responsibilities. Models still need identities, encrypted data, network boundaries, audit trails, and clear ownership.

Generative AI adds extra concerns such as prompt injection, sensitive context leakage, model access, and tool permissions. The exam expects candidates to recognize these risks at a practical level and choose controls that fit the stated requirement.

Apply shared-responsibility thinking to AI workloads

A managed AI service reduces infrastructure work, but the customer still controls how the service is used. AWS secures the underlying cloud platform, while the organization remains responsible for identities, application code, data classification, permissions, and many configuration decisions.

This distinction prevents a common misconception: using a managed foundation model does not automatically make the application compliant. The surrounding architecture and operating process determine whether sensitive data is handled safely.

Use least privilege for people, applications, and agents

Every identity should receive only the permissions required for its task. Human administrators, application roles, service accounts, and agent tools should be scoped separately. Broad wildcard access makes mistakes and prompt-driven misuse more damaging.

Least privilege is especially important for agentic systems because a model can invoke actions dynamically. A read-only support assistant does not need the same permissions as a workflow that updates customer records. Permission boundaries should reflect the actual consequence of each tool.

Protect keys and secrets for different reasons

Encryption keys protect data cryptographically, while secrets such as API tokens and database passwords authenticate access to other systems. Mixing these concepts leads to weak designs. AWS KMS is used to manage cryptographic keys; Secrets Manager manages sensitive credential material and rotation workflows.

AWS KMS and Secrets Manager cover distinct needs in an AI system: protecting encryption keys and managing external-service credentials that require access control and rotation. A model gateway may encrypt stored prompts with KMS while using a rotated secret to authenticate to an external service.

Encrypt data in transit and at rest

AI applications move data through storage, retrieval systems, APIs, model endpoints, logs, and downstream tools. Encryption at rest protects persisted data, while TLS and other transport protections reduce interception risk in transit. Key-management policies determine who can decrypt and under what conditions.

Encryption is necessary but not sufficient. An overprivileged application can legitimately decrypt data it should never have received. Security therefore combines cryptography with access control and data minimization.

Control network paths when workloads require isolation

Some organizations need private connectivity, restricted egress, or tightly segmented workloads. The architecture may use VPC controls, private endpoints, routing policy, and centralized inspection to limit how AI components communicate.

Network isolation is most valuable when combined with identity. A private path does not compensate for a role that can access every model or data source. Defense in depth means an attacker must defeat several independent controls rather than one perimeter.

Log actions so the system can be audited

Organizations need evidence of who accessed resources, which API calls occurred, what configuration changed, and how the application behaved. AWS logging and monitoring services support that visibility. AI-specific telemetry can add prompt identifiers, model versions, retrieved sources, tool calls, and policy decisions.

Logging must be designed carefully because prompts and outputs can themselves contain sensitive data. Auditability does not require indiscriminate content retention. The log schema should capture the evidence needed for investigation while minimizing unnecessary exposure.

Treat prompt injection as an application-security problem

Prompt injection happens when untrusted input attempts to override application instructions, manipulate tool behavior, or expose information. It can arrive directly from a user or indirectly through retrieved content. The model’s language flexibility makes this different from conventional input validation, but the security response is familiar: distrust external input and constrain privilege.

Defenses include separating instructions from data, narrowing tool permissions, validating tool parameters, filtering content, and placing human approval before high-impact actions. No single prompt can be relied on as the security boundary.

Govern data, models, and changes across the lifecycle

Governance defines which models are approved, what data classes can be used, who can change prompts or retrieval sources, how evaluation is performed, and when a model must be retired. Version records are important because behavior can change after a model or prompt update.

Compliance work then maps these controls to regulatory or contractual obligations. Requirements around data location, retention, audit evidence, and privacy vary by organization. The exam is more interested in matching the control to the requirement than in memorizing every regulation.

Choose the control that addresses the actual exposure

If a scenario describes leaked credentials, secret management is relevant. If the risk is unauthorized model access, focus on identity and least privilege. If a regulated workload cannot traverse the public internet, think about private connectivity. If the concern is proving who changed the system, audit logging becomes central.

This problem-to-control mapping is the core exam skill. Candidates who recognize the specific exposure can eliminate broad but irrelevant security answers and select the control that directly reduces the stated risk.

Security reviews should also distinguish model-provider trust from application trust. Even when the managed model service has strong platform controls, the application may retrieve sensitive documents, call external APIs, or send outputs to systems with different security properties. The complete data path needs to be reviewed end to end.

Model and prompt changes should pass change-management controls appropriate to their impact. A new model version can alter safety behavior, latency, or the way it follows instructions. Production promotion should therefore include evaluation evidence, approval, and rollback capability rather than treating the model as a passive dependency.

Governance can also use service-control policies, tagging standards, and account boundaries to constrain where AI services are used. Large organizations often need guardrails that work across many teams instead of relying on every project to configure the same rules correctly.

Finally, security scenarios often contain distracting technical detail. Identify the asset at risk, the threat, and the control boundary. If the asset is a secret, manage the secret. If the threat is unauthorized action, constrain the identity. If the problem is untrusted content manipulating an agent, isolate instructions, validate tools, and minimize privilege.

Data classification should precede AI integration. Public marketing content, internal operational data, confidential contracts, and regulated personal information should not automatically share the same model workflow. Classification lets architects decide which models, regions, logs, and retrieval stores are permitted for each information class.

Cross-account design can improve governance in larger AWS environments. Central security teams may manage logging, key policy, or network controls while application teams own individual workloads. Account boundaries reduce blast radius and support separation of duties, but they require deliberate cross-account roles and resource policies.

Threat modeling for GenAI should include both familiar and AI-specific paths. Traditional threats such as credential theft and misconfigured storage still apply. Newer paths include malicious prompts, poisoned retrieval documents, unsafe tool calls, and sensitive information appearing in model output. The architecture should map controls to each path instead of assuming one “AI firewall” will cover them all.

Compliance evidence should be generated by the operating system, not assembled only before an audit. Centralized CloudTrail records, configuration histories, access reviews, and policy evaluations make it easier to prove that controls operated continuously. Manual screenshots taken once a year are weak evidence for a dynamic cloud environment.

Security testing should include negative cases. Verify that unauthorized identities cannot call the model, restricted documents cannot be retrieved, disallowed tools cannot be invoked, and sensitive logs cannot be queried by ordinary users. Successful happy-path tests prove functionality; negative tests prove boundaries.

Incident containment may require disabling a model endpoint, revoking a role, blocking a tool, or removing a compromised document source. Teams should know which control can stop each failure mode quickly. Recovery planning is stronger when those levers are defined before an incident.

AI governance also needs an approved-use policy. A service may be technically available across the organization, but not every dataset or business process should use it. Clear permitted and prohibited uses reduce shadow AI and give teams a path to request exceptions when a legitimate need falls outside the standard.

Supplier and model-provider changes should trigger review. Terms, available regions, model behavior, or service features can change independently of the application. Periodic vendor review helps ensure that the original security and compliance assumptions remain true.

Data-loss prevention controls can complement identity and encryption when the risk is sensitive information leaving an approved boundary. The application can inspect inputs and outputs for restricted data classes, while policy determines whether the request is blocked, redacted, logged, or escalated.

Security architecture should also consider denial-of-wallet behavior. An attacker who can trigger expensive model calls may create a financial incident even without stealing data. Rate limits, quotas, authentication, anomaly detection, and budget alerts help constrain abusive or runaway usage.

Finally, governance should make model retirement safe. When a model version is deprecated, teams need a tested replacement path, regression results, and a rollback plan. Waiting until the service is unavailable turns routine lifecycle work into an emergency migration.