Identity, authorization, privacy, and data protection

What you will be able to do

1. Implement least-privilege authorization for users and services.
2. Protect data across retrieval, tools, logs, and exports.
3. Design retention, deletion, and access review.

Prerequisites: Builder-level interface validation, Python, testing, metadata logging and state-transition tracing. Hardware benchmarks and model accounts are not required.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

Authentication establishes an identity with stated assurance; authorization decides whether that principal may perform an action on a resource in context. Models do neither reliably. RBAC groups permissions by role; ABAC evaluates attributes such as tenant, ownership, purpose, and resource label. Enforcement must be consistent across retrieval, cache, tool, log, and export paths and fail closed when attributes are missing. Privacy engineering minimizes collection and retention, limits purpose, supports deletion, and makes exceptional full-content access auditable.

Mechanism and implementation

Bind access to identity, action, resource and current policy version. Prompt roles are not identity. Retrieval, tools, caches, logs and export are distinct paths that need common enforcement. Purpose or entitlement changes require deletion/invalidation of derived copies and queued work under the approved policy.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

def permitted(actor, resource, action):
    return (actor.get("tenant") is not None and actor.get("tenant") == resource.get("tenant")
            and action == "read" and resource.get("deleted") is False)
resource = {"tenant": "one", "deleted": False}
assert permitted({"tenant": "one"}, resource, "read")
assert not permitted({"tenant": "two"}, resource, "read")
assert not permitted({"role_in_prompt": "admin"}, resource, "read")
resource["deleted"] = True
assert not permitted({"tenant": "one"}, resource, "read")
print("access and deletion checks passed")

Engineering decisions

• Select central policy inputs and enforcement points.
• Partition caches and telemetry by authorization context.
• Define fail-closed behavior and break-glass governance.

Worked example

A two-tenant case system includes allowed and denied records. Tests attempt direct retrieval, cached retrieval, export, and log access across tenants. Missing tenant attributes deny access and generate a metadata-only audit event.

Diagnose the failure

Unknown identity and deleted resources deny. If one path leaks, repair shared enforcement and every caller; adding a prompt instruction is insufficient.

Part 2 Guided practice

Trace tenant two through read, retrieval, cache and export. Independently change policy after caching and revalidate every read. Explain why matching classification labels alone do not authorize a person.

Answer criteria and feedback: Unknown identity and deleted resources deny. If one path leaks, repair shared enforcement and every caller; adding a prompt instruction is insufficient.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

Trace a denied resource through every path. If one path leaks, freeze the exercise, preserve the trace, and repair the common enforcement layer rather than individual prompts. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

• https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• https://www.nist.gov/privacy-framework

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.