Skip to content
NTPU AI Learn

IL 202 · Module 2

Access and Integration

Test least-privilege access per role, design read-only integrations, and drill failure and revocation scenarios.

Start Section 1
  • Duration180 min
  • LevelAdvanced
  • PrerequisiteModule 1 data inventory and data-flow map completed
0 / 3 completed

Learning objectives

  • Define least-necessary permissions for every role, instead of reusing an existing admin account.
  • Design and test a read-only-first approach to system integration.
  • Drill account deactivation, offboarding, and revocation scenarios to confirm permissions take effect immediately.

Least-privilege access matrix

60 min

Write "just enough" permissions for every role

During the prototype phase, everyone often shares one high-privilege account for speed. Before a pilot, permissions must be broken down to the role level, so each role has only the minimum access it needs to do its job.

Access-matrix example (SYN-CS-001, synthetic roles)
RoleCan accessShould not have
Customer-service agentRead knowledge-base documents, the AI drafting tool, send repliesEdit knowledge-base documents, export the full customer database
Customer-service supervisorRead case statistics, review AI-draft quality reportsDirectly change permission settings, delete case records
Knowledge-base maintainerAdd/update/retire knowledge-base documentsAccess individual customer personal data, AI tool configuration
Technical administratorConfigure AI tool connections, monitor system statusRead individual customer case content

Warning

Common mistake: granting broad permissions because "this person needs everything anyway." The least-privilege matrix asks what this role, as defined, minimally needs, not what this particular person might someday want.
  1. Step 1
    List every role that will touch this solution (roles, not individual names).
  2. Step 2
    Write the minimum necessary data and function access for each role.
  3. Step 3
    Find where current accounts actually exceed the matrix, and log the gap for remediation.

Key takeaway: A least-privilege matrix describes what a role needs, not what existing accounts already have.

Read-only-first integration testing

60 min

Test integration feasibility with read-only connections first

When integrating with existing systems, start with a read-only connection to validate data format, refresh frequency, and latency before considering write access. Read-only-first substantially limits the damage an AI tool could accidentally do to production data.

Integration test log fields
FieldWhat it covers
Connection methodAPI / read-only database replica / exported file, in that order of preference
Test date and versionThe corresponding system version and test-script version
Data consistency checkA sample comparison of the source system against the integrated result
Latency and refresh frequencyThe actual sync delay, and whether it meets business needs
Failure casesActual behavior under disconnection, format changes, or timeouts

Info

If the business genuinely needs write access to an existing system (e.g. auto-updating case status), the write scope must be limited to specific fields and have its own audit log; it should never share the same credentials as read-only queries.
  1. Step 1
    Test a read-only connection for format and latency, recording at least one success and one failure scenario.
  2. Step 2
    If write access is genuinely needed, scope it to specific fields and design a separate audit log.
  3. Step 3
    Keep the integration test records (access matrix, test log) as evidence for the integration-readiness domain in Module 4's Readiness Review.

Key takeaway: Read-only-first is not laziness: it caps the blast radius if the AI tool ever misbehaves.

Failure and revocation drills

60 min

Drill account deactivation and revocation: how long until access is really gone?

A readiness review cannot just look at how well access is designed on paper; it must actually drill "how long after revocation does access really stop." The point of the drill is to find delays and gaps, not to assume the documentation's claim of "immediate" is true.

Not adequate revocation description

"The account is disabled after offboarding," with no statement of how long it takes, who does it, or how it is verified.

Adequate revocation description

Trigger
HR sends an offboarding notice, or the process owner requests revocation in writing.
Time limit
The technical administrator disables the account and removes any AI-tool access token within 24 hours.
Verification
After revocation, someone actually attempts access with that account, confirms it is denied, and logs the verification time.
Exception handling
If access is still possible 24 hours after revocation, treat it as a security incident and escalate per Module 3's incident process.

Warning

Common gap: an AI tool's own access token (an API key) is often managed independently of the general account system, so revoking a user account does not automatically invalidate its token. The drill must check this separately.
  1. Step 1
    Pick one role and actually run the revocation process, recording the real time each step takes.
  2. Step 2
    Separately confirm whether the AI tool's access token is invalidated along with the account.
  3. Step 3
    Write the drill results, including any delay or gap, into the test log; anything that fails is a gap in access readiness.
Check yourself

A team disabled a departing customer-service agent's account but did not check whether the AI tool's API key connected to it was also invalidated. What is the risk?

A team disabled a departing customer-service agent's account but did not check whether the AI tool's API key connected to it was also invalidated. What is the risk?

Key takeaway: The point of a revocation drill is to find the gap between "the documentation says immediate" and reality, not just to confirm the process exists on paper.

Save as PDF

What next?