[Part 48] Delegating Only Necessary Work to External Maintenance Staff
November 13, 2026
When delegating database checks externally, I first consider access scope. Checking status needs no modification privileges, and completed work provides no reason to retain access.
A test user played the external operator, requested read access, obtained separate approval, checked one order, and lost access after revocation. I tested the whole sequence.
1. Stating the Database and Task First
The task was simply checking order 41001’s status and amount, using existing lab data and accounts rather than real customer records.
The operator’s DB Access Request selected only DB Privilege Account Lab, Read-Only, and a reason specifying status checks, no changes, and revocation afterward.
Access expiry was that day. The approver could inspect purpose, scope, and deadline as well as database name.

2. Approval Becomes Usable Read Access
Using the existing rule, Demo Approver reviewed the request and commented approval for order-status inspection.
Approved status retained separate requester/approver and processing times, providing a basis for later handovers or investigation.

The operator now saw Read-Only, Select, and expiry at 23:59:59. No duplicate administrator grant was needed.

3. Reads Work, Changes Do Not
Connect opened SQL Editor; order 41001 returned READY and KRW 25,000, satisfying the requested check.

An UPDATE on the same order was denied for missing UPDATE permission. A source-data check confirmed unchanged status and amount.
‘Please only inspect’ became an actual enforced scope without also granting write access.

4. Revoking Access as Soon as Work Ends
I revoked only this task’s granted access, leaving the user’s unrelated privileges intact.
The refreshed user list no longer showed the database. The already-open editor’s same SELECT also reported no query privilege for the connection.
I revoked immediately instead of waiting for scheduled expiry, useful when maintenance finishes early.

5. Evidence from Request to Revocation
Access Control Logs showed a grant at 13:41:48 and revocation at 13:44:24, distinguishing request-based grant from administrator revocation.

Query Audit showed successful reads and the blocked UPDATE, with database account, table, SQL, and reason. It traced actual activity, not just granted access.

External maintenance became one flow: request purpose/scope, approve, perform permitted reads, revoke, and retain approver and SQL evidence.
What appealed most was enabling work with clear boundaries: allow necessary checks, prevent unauthorized changes, and clean up finished access, verified in one inspection.
![[Part 47] Receiving Alerts for Blocked SQL](/assets/content/acp-lab-notes/blocked-sql-alerts/01.webp)
![[Part 49] What records remain after changing a single order?](/assets/content/acp-lab-notes/order-change-audit/01.webp)